I started using UNIX years ago at school, so when Linux came along I eagerly installed it on my home computer so that I could have the same wonderful operating system in both places. Linux has worked amazingly well for me, but after a while I noticed that it wasn’t completely adapted for home use. « locate »‘s database wasn’t getting updated, the log files kept growing and growing, and the startups and shutdowns were taking a fair chunk out of my day. This was because UNIX computers traditionally stay on all the time, while home computers tend to be frequently turned off.
None of my cron jobs, like updating locate’s database and trimming the log files, were being done since the computer was hardly ever on in the wee hours of the morning, the time chosen by the distributions (Slackware, then Red Hat 3.0.3, then 5.1) for housecleaning. Very early in the morning is perfect for computers that stay on all the time, since that’s when there are the fewest users to be upset by the somewhat disruptive janitorial jobs, but I was unwilling to leave my computer on all them time just to make cron happy. I ruled out changing the job running time to something during the day, since I tend to run my home computer at unpredictable times for a few hours. The only way I could be sure the jobs would be done would be to run them hourly instead of daily or weekly. That would soon get annoying. My solution, the following script, was to combine an hourly cron with batch, and to check whether the job had already been done satisfactorily recently. The hourly cron is frequent enough that it will probably get a chance while I have the computer on, but batch minimizes my annoyance by only running the jobs when the computer isn’t too busy, like when I’ve gone for a snack. The timestamp check cancels the job if it’s already been done in the last week/month/etc.
groundskeeper (Bash script)
As you probably know, speeding up the startups and shutdowns is a matter of not starting daemons you’ll never need. I’ve taken it a bit further by often not starting services that I often *do* need. Craziness? No. We all use SysV runlevels, now, right? (When I started using Linux, with Slackware, this wasn’t the case, but I hope that even the most ardent BSDers have seen the desirability of runlevels.) I was using runlevel 3 as my normal operating mode, had a never used runlevel 4, and noticed that about half the time in booting 3 was spent on network things. About half the time when I turn on my computer, I’m not going to use my modem at all, so I set up runlevel 4 as « 3 without network stuff ». Now when I want to use my modem I boot normally, but if I know I won’t be using it I type « linux 4 » at the LILO prompt and save a lot of time. No reconfiguration of LILO was necessary. I haven’t needed to yet, but I could use my modem in 4 by becoming root and running the network starter scripts by hand, and stopping them when I’m done. One of these days I should write a script to automate that, but I’m lazy. Red Hat provides a runlevel editor in their control-panel, but it is also easy to do from the command line by playing around in the /etc/rc.d/* directories.
If you’re not sure which services you can safely eliminate, here’s a listing of my /etc/rc.d/rc.d directories as a sample. Your requirements will probably be different, however.
rc3.d: rc4.d: K08autofs K08autofs K09keytable K09keytable K10named K15gpm K15gpm K15sound K15sound K30sendmail K45sshd K50inet K55routed K59crond K59crond K60atd K60atd K60lpd K60lpd K65portmap K65portmap K80random K80random K97network K99syslog K99syslog S01kerneld S01kerneld S10network S20random S20random S30syslog S30syslog S40atd S40atd S40crond S40crond S40portmap S40portmap S50inet S55named S55sshd S60lpd S60lpd S72autofs S72autofs S75keytable S75keytable S80sendmail S85gpm S85gpm S85sound S85sound S99local S99local
Another, very optional, thing you can do is run ‘tune2fs’ on your ext2 filesystems to increase the number of mounts before they get fscked. Read the man page first, and I have no idea what the ideal number is.
Copyright © 1999, Rob Reid
Published in Issue 47 of Linux Gazette, November 1999