How to remove unused kernel images from CentOS Linux system

Every time you update your CentOS Linux and the update includes a new kernel image update the system will not remove your old kernel but it will cumulatively add new kernel to the top of your Linux kernel installed list. Normally, this does not present any issue to your running system and you are not required to take any action to remove any old and unused kernel images.

The reason why you may wish to remove/uninstall unused kernel images is that you need to reduce disk usage space of your system, especially if your /boot mount point is mounted separately and has a limited disk space


df -h /boot/
rpm -q kernel
uname -r
yum install yum-utils
package-cleanup --oldkernels --count=1
rpm -q kernel

Reference:

http://linuxconfig.org/how-to-remove-unused-kernel-images-from-centos-linux-system

 

Mysterious cab files fill-up temp folder

A Windows server disk space is filling up fast due to cab files.

Upon closer inspection I found that every hour an unknown process would attempt to write a .cab file of approx 60MB to the Windows temp folder. Checking with Process Explorer I found that it was makecab.exe writing these files. Makecab was invoked by services.exe, so that was a bit of a dead end. I looked through the list of Windows scheduled tasks, but did not find anything that was supposedly run every hour.

The SFC.exe program writes the details of each verification operation and of each repair operation to the CBS.log file. The CBS.persist.log is generated when the CBS gets to be around 50Mb in size. CBS.log is copied to cbs.persist.log and a new cbs.log file is started. A bit of Google foo and we determine that the cbs logs would only be useful for serious troubleshooting issues. If the system is running fine, we can delete this file. SFC.exe will create a new one, next time it is run. I now speculate that the file size is larger than what is supported and the process fails, hence resulting in a partial .cab file that sits in the temp folder, rather than a complete .cab file in the CBS log folder.
I have deleted the offending .cab file and most of the other ones too, just keeping a few recent ones in case we need them. No more mysteries!

http://felixyon.blogspot.com.au/2013/03/mysterious-cab-files-fill-up-temp-folder.html

 

ddrescue and ddrescue-GUI

ddrescue and ddrecue-GUI for data recovery or to retrieve corrupted data.

ddrescue:

GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying to rescue the good parts first in case of read errors. Ddrescuelog is a tool that manipulates ddrescue mapfiles, shows mapfile contents, converts mapfiles to/from other formats, compares mapfiles, tests rescue status, and can delete a mapfile if the rescue is done. Ddrescuelog operations can be restricted to one or several parts of the mapfile if the domain setting options are used. The basic operation of ddrescue is fully automatic. That is, you don’t have to wait for an error, stop the program, restart it from a new position, etc.

Install into Ubuntu / Debian:

 sudo apt-get install gddrescue 

More info and Download:
https://www.gnu.org/software/ddrescue/

ddrescue-GUI:

DDRescue-GUI is a program designed to make it easier to use GNU ddrescue (A Command-Line data recovery tool). It provides a simple graphical method for using ddrescue. This is designed to be as user-friendly as possible so users new to Linux can use ddrescue easily.

DDRescue-GUI is a simple GUI written in Python 2 designed to make the data recovery tool, ddrescue, easier for beginners to use. It’s designed for Linux, and more recently Apple OS X, as KDiskRescue appears to be abandoned, with the last update in 2006. DDRescue-GUI is desgined to look native on almost all Desktop Environments, so whichever one you use, it should look familiar.

More info, download and install:
https://launchpad.net/ddrescue-gui

 

Last logon time of user in Windows

Using ‘Net user’ command we can find the last login time of a user. The exact command is given below.

 net user username | findstr /B /C:"Last logon" 

Example:
To find the last login time of the computer administrator

 C:\> net user administrator | findstr /B /C:"Last logon"
Last logon 6/30/2010 10:02 AM
C:> 

For a domain user, the command would be as below.

 C:\>net user john /domain | findstr /C:"Last logon"
Last logon 9/18/2013 10:18:41 AM 

Reference:
[[http://www.windows-commandline.com/last-logon-time-of-user/]]

Test the spammyness of your email

As the name suggests this free service will test the spammyness of your email – https://www.mail-tester.com/

From their FAQ:

We’re the guys from MailPoet and AcyMailing.

We needed a cheap, simple and efficient way to quickly test the quality of our own newsletters.

We simply built on our own tool. Now we’re sharing it for free via our web-interface and enable you to include our tests in your own app and whitelist our service by creating an account.

We’re geeky email software engineers. We can let you imagine how such people look like.

https://www.mail-tester.com/

Disk slowly filling up but no visible file size changes

If there’s an invisible growth in disk space, a likely culprit would be deleted files. In Windows, if you try to delete a file opened by something, you get an error. In Linux, the file will be marked as deleted, but the data will be retained until the application lets go. In some cases, this can be used as a neat way to clean up after yourself – application crashes won’t prevent temporary files from being cleaned.

To look at deleted, still-used files:

 lsof -b 2>/dev/null | grep deleted 

You may have a large number of deleted files – that in itself is not a problem. A single deleted file getting large is a problem.

A reboot should fix this, but if you don’t want to reboot, check the applications involved (first column in lsof output) and restart or close reasonable looking ones.

If you ever see something like:

 zsh 1724 muru txt REG 8,17 771448 1591515 /usr/bin/zsh (deleted) 

Where the application and the deleted files are the same, that probably means the application was upgraded. You can ignore those as a source of large disk usage (but you should still restart the program so that bug-fixes apply).

Files in /dev/shm are shared memory objects and don’t occupy much space on disk (an inode number at most, I think). They can also be safely ignored. Files named vteXXXXXX are log files from a VTE-based terminal emulator (like GNOME Terminal, Terminator, etc.). These could be large, if you have a terminal window open with lots (and I mean lots) of stuff being output.

References:
http://askubuntu.com/questions/677778/disk-slowly-filling-up-but-no-visible-file-size-changes

http://www.cyberciti.biz/datacenter/linux-unix-bsd-osx-cannot-write-to-hard-disk/