How many times did you start a long-running task like gcc compilation on a remote server and then suddenly needed to disconnect from your shell? Maybe you just needed to move to some other place with your laptop, but if you disconnected from your LAN, your ssh connection would go down. How many times you thought “Damn, if I had launched screen before this…”?

The trick to save your compile time and not break your schedule is simple: just have your shell .profile script run screen at startup on your remote server. For bash, the syntax is simple, just add the following line at the end of your ˜/.profile script:

if [ ${SHLVL} -eq 1 ]; then
    ((SHLVL+=1)); export SHLVL
    exec screen -R -e "^Ee" ${SHELL} -l
fi

Quick implementation notes:

1. Parameter -R reattaches to an existing detached session, if it exists, otherwise creates a new one.
2. Parameter -e sets a non-standard escape character. This is useful since you don’t want login screen to interfere with other screens you may spawn during your activity. I chose Ctrl-E as it’s not used by other well-known keyboard shortcuts and works on most OSes.

To detach from your server type Ctrl-E d or just close your terminal window. Running processes will remain active in background, without detaching from your shell. When you connect to your remote shell again, you’ll get back to your session.

Do you like Unix tips like this? Follow me on Twitter or subscribe to my RSS feed for more.

This post deals with two system-wide alternatives, sysinitv and Mac OS X’s launchd: the first represents the tradition, while the latter represent innovation. Feel free to use comments to share your tips.

System V init

Also known as sysinitv, it’s the historical choice for most unices. Every OS has customized its own version so there’s no common standard. First process, typically /sbin/init reads config in /etc/inittab and executes a series of commands, depending on which runlevel is currently set.

In typical configurations, init launches a main rc script on runlevel change (boot sequence runlevel, default multiuser runlevel, etc), which in turn runs all the initialization scripts in a runlevel-specific folder. For example, in Redhat Linux each system service has an init script in /etc/init.d/. These init scripts respond to a number of actions that can be passed as parameter, for example /etc/init.d/sendmail start runs a function that starts sendmail daemon. Typical actions include: start, stop, restart, status. Some scripts implement specific actions: for instance apache service implements reload action, which does a graceful signal-based reload. Furthermore, most OSes include additional dependency information in those scripts and import script configuration directives from external files (/etc/sysconfig/ on Debian, SuSE, etc, /etc/conf.d/ in Gentoo).

When rc scripts is ready to process init scripts, it looks in appropriate runlevel folder (in RedHat Linux and derivatives its /etc/rc.d/rc<runlevel>.d/,  Gentoo has /etc/runlevels/<runlevel>/, etc) and executes entries which are symlinks to the actual /etc/init.d scripts.

Most of these systems use a specific naming convention for these symlinks, to define order of execution (scripts are run in alphabetic order) and action to be passed as parameter. For example, on RedHat-style systems, scripts are named as S<NN><service> or K<NN><service>, where NN is a number from 00 to 99. S means start action (ie. /etc/rc.d/rc3.d/S60sendmail start), while K means stop action. In other systems such as Gentoo, order of execution is determined dynamically by dependency information (requires additional computing and dependency caching).

Operating systems typically implement command-line, ncurses-based or X11-based tools to manage adding and removing items from runlevels: chkconfig under RedHat/CentOS, update-rc.d under Debian, rc-update under Gentoo, boot up manager (bum) under Ubuntu.

Pros: well known, easy for unix admins, easy to add new custom scripts.
Cons: no common standard, no parallel execution (except for Gentoo), no support process monitoring (ie. restarting daemons on crash).

launchd

It’s installed by default on Mac OS X 10.4 (Tiger) and later. Once launchd is run by the kernel, it runs /etc/rc (a BSD-style system wide initialization script) and scans/System/Library/LaunchAgents and /Library/LaunchDaemons for plist files. Each plist contains a series of properties that define behaviour of launchd and customize run setup (command parameters, working directory, process owner, resource limits, etc). Launchd monitors processes and dynamically acts to adapt process status to requirements defined by configuration. This includes: running process automatically at boot, respawning process on unexpected quit, starting and stopping process upon several conditions (cpu load, network status, filesystem mounts, file presence, time schedule, shutdown, sleep, etc).

Finally, launchd companion is user tool launchctl, which interacts with launchd through a socket and allows administrator to send in requests like start, stop, list, limit, shutdown, etc.

Pro: amazing configuration directives, powerful extension mechanism, post-spawn process monitoring and usage management, scheduled actions (as in cron), stdio-to-inet support as inetd, can add processes without configuration files.
Cons: configuration plists are an Apple-world standard, many great features are Mac OS X specific, strict process launching requisites (see launchd.plist manpage), no support for configurable dependencies, no support for custom process signaling, complex logic may lead to unexpected results.

(continues)