Saturday, 14 December 2013

Adjusting the service shutdown sequence on Debian

I manage a few virtual Debian (Wheezy) machines that mount an iSCSI volume. These hold websites and mysql data.

The problem is that in the default shutdown sequence, umountiscsi.sh is called before shutting down cherokee (or apache2) and mysql. So the umount fails because the filesystem is busy and the machine doesn't shutdown properly from the CLI, requiring a reset at the VMWare console.

I searched around for the way to adjust the dependency based boot and shutdown sequence and after reading a lot of web and manual pages I finally understood the way to do it.

First edit /etc/init.d/cherokee (or /etc/init.d/apache2) and /etc/init.d/mysql so that the line:

# Required-Stop:

contains umountiscsi.sh

The logic of Required-Stop is that the services named on the line depend on the current service (webserver, database) being stopped first.

Now run:

insserv -d -v umountiscsi.sh

Despite the warnings on the man page that this is too low level, this is the right command to use. It will rebuild the symlinks in the runlevel directories as well as regenerate the files /etc/init.d/.depend.{boot,start,stop} Next time you shutdown, the webserver and database will be shutdown before unmounting the iSCSI volume.

This assumes that the default start and stop sequences expressed in the INIT lines are correct for you. If you have added services manually using update-rc.d at particular runlevels and sequence points then I cannot guarantee that you will get the desired result.

Saturday, 7 December 2013

Shrinking an ext4 filesystem from the CentOS 5.x CD/DVD in rescue mode

Unfortunately this cannot be done because the resize4fs program is missing from the rescue filesystem. You'll have to use a rescue distro, for example gparted-live, where the ext4 capabilities are already incorporated into the up to date resize2fs. CentOS/RHEL 5 ships with an old resize2fs and ext4 capabilities are in separate programs.

If it were a matter of expanding the filesystem this could be done on a live system.

If it were not the root filesystem you might be able to unmount the file system and do this on a live filesystem.

If it were not ext4 you could use resize2fs.

In any case a shrink involves downtime for that filesystem.

There is however a fsck.ext4 in the rescue filesystem so you can still do fscks in rescue mode.