gerardo juarez-mondragon wrote: > I have a script which scans the /var/log/messages > file for FTP movements to notify some users of > relevant movements in some accounts they are > interested in. It runs fine when I launch it from > the command line (as root) and send it to > background. Once tested I installed it in > /etc/rc.d/rc.local. When the machine reboots, > due to administrative purposes, power failures, > whatever, it reboots normally and the script can > be seen running ok. The only problem is that it > doesn't work. If I kill the process and rerun it > from the command line, it starts working. The > very same script. No changes. > > This is the script, called scanftp.sh: > > /usr/bin/tail -f /var/log/messages \ > | /root/scripts/scanftp.py > > It is in a single line. The command I run is > sh scanftp.sh & > > What do you think is wrong here? If a script runs from the command line, but doesn't run from cron, init etc, the problem is usually because something is relying upon environment variables which are set for your shell but not for cron, init, etc. When you start an interactive shell, various start-up scripts are read by the shell. For bash, this typically includes some subset of /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile and ~/.bashrc. In turn, these may read other scripts (/etc/bashrc and /etc/profile.d/* are both common). Any environment settings contained in such scripts will apply to interactive shells, and hence to any programs run from them, but not to programs run from cron, init etc. So, if a program relies upon any such settings, it will work when run from an interactive shell, but not from init, cron etc. A common setting which may be required is having non-standard "bin" directories (e.g. /usr/local/bin, /usr/X11R6/bin, /sbin, /usr/sbin, and/or /usr/local/sbin) in the value of $PATH (the hard-coded default for $PATH is usually just "/bin:/usr/bin"). Typing "env" within the shell will print a list of environment settings for that shell. The same information can be determined for other processes by running "ps axeww" (as root; normal users can't read the environment of processes which they don't own). Note that init itself typically has a near-empty environment (just HOME, TERM and BOOT_IMAGE on my box), but you can determine the environment which it passes to subprocesses (e.g. rc.local) by examining other processes which were started from init (e.g. atd, crond etc). BTW, you shouldn't normally start daemons from rc.local. That script is meant for "one-shot" commands which are run at startup. A daemon should have its own script, like those already in /etc/rc.d/init.d (just copy one and edit it for your purposes), so that it can be controlled using the standard management tools. However, the issues relating to environment variables still apply. -- Glynn Clements <glynn.clements@xxxxxxxxxx> - : send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
