You never stop learning!

[hazel]

One of the things I most like about Linux is that when something goes wrong, you learn something new from it. When something goes wrong on Windows, you learn nothing; it's just a pain in your four letters.

I have an indexing job that is run every day by cron, but for some reason it wasn't working. Which was odd because there didn't seem to be anything wrong with the script; when I ran it by hand using sudo, it worked well enough.

I checked to see how cron was doing it. In Crux, cron uses runjobs, equivalent to runparts on some other systems. But that's a simple script too; it just loops through a directory running everything that's executable. Nothing could have gone wrong there surely.

Then I looked at the other jobs in /etc/cron/daily. One of them was a makewhatis script and that seemed to be working; the timestamp on /usr/man/makewhatis was bang up to date. So I listed the two scripts side by side to see what the difference was, and I found that the makewhatis script (which came with the system) used full pathnames for its commands and my script didn't. I put the pathnames in and now it works.

I had just assumed that daemons like cron, because they run as root, have access to root environmental variables like $PATH, but seemingly they don't, perhaps because they don't actually log in. You never stop learning.

[PrinceSharma]

Like I've just learned a new thing from this post.

[MASONTX]

Good job of sleuthing Hazel. Thanks for the report.

[MikeTbob]

One of the things I most like about Linux is that when something goes wrong, you learn something new from it. When something goes wrong on Windows, you learn nothing; it's just a pain in your four letters.

I have an indexing job that is run every day by cron, but for some reason it wasn't working. Which was odd because there didn't seem to be anything wrong with the script; when I ran it by hand using sudo, it worked well enough.

I checked to see how cron was doing it. In Crux, cron uses runjobs, equivalent to runparts on some other systems. But that's a simple script too; it just loops through a directory running everything that's executable. Nothing could have gone wrong there surely.

Then I looked at the other jobs in /etc/cron/daily. One of them was a makewhatis script and that seemed to be working; the timestamp on /usr/man/makewhatis was bang up to date. So I listed the two scripts side by side to see what the difference was, and I found that the makewhatis script (which came with the system) used full pathnames for its commands and my script didn't. I put the pathnames in and now it works.

I had just assumed that daemons like cron, because they run as root, have access to root environmental variables like $PATH, but seemingly they don't, perhaps because they don't actually log in. You never stop learning.

Good job detective Hazel! And just for what it's worth,,,,us Crazy Americans only have 3 letters in our "you know what" so it took me a minute to realize what you meant!

[Cabhan]

Good job detective Hazel! And just for what it's worth,,,,us Crazy Americans only have 3 letters in our "you know what" so it took me a minute to realize what you meant!

Good, so I'm not the only one who was stumped by that .

[MASONTX]

As Churchill said "We are two nations divided by a common language."

[the dsc]

I've read once something along the lines that cron does not run on a "bash environment", but something somewhat "poorer". Possibly .bashrc on root's home folder does not even count, as well as other costumary variables like $PATH.

Once I wanted to have a somewhat more complex program or maybe just even a command to be run by cron, but it wouldn't do it, and then I went looking out for an explanation/solution, that's how I've came to know that, and that's all I remember by now. Perhaps the problem was actually the very same that was described here, just not using explicit paths.

[the dsc]

Good, so I'm not the only one who was stumped by that .

I've just read the whole thing, grasping the overall sense from "pain", kept reading, just later as I was reading the other messages I got stumped with these messages relating to the different "you know whats". And I was like "what? What what are they talking about?" Then I've read the first message, maybe two or three times, untill I finally got it.

[hazel]

FYI I've just looked at the cron daemon's environment in /proc/PID/environ. This is what I found:

CONSOLE=/dev/console
TERM=linux
INIT_VERSION=sysvinit-2.86
PATH=/bin:/usr/bin:/sbin:/usr/sbin
_=/usr/sbin/crond
RUNLEVEL=2
PWD=/
PREVLEVEL=N
HOME=/
SHLVL=2

So it does have a path but not the same one as root. The indexing program that caused the problem (it's called glimpse) is in /opt/bin, which is the normal location in Crux for user-installed programs, and that's on root's path and mine but not on cron's.

[the dsc]

You really never stop learning, I didn't know about the whole "environ" thing. Mine, for debian squeeze/sid is substantially different, I guess:

LANGUAGE=en_US:en
CONSOLE=/dev/console
HOME=/init=/sbin/initrunlevel=2
INIT_VERSION=sysvinit-2.88
COLUMNS=160
TERM=linux
BOOT_IMAGE=/boot/vmlinuz-2.6.35-0.dmz.1-liquorix-686
PATH=/sbin:/usr/sbin:/bin:/usr/bin
RUNLEVEL=2
PREVLEVEL=N
LANG=en_US.UTF-8
SHELL=/bin/sh
PWD=/previous=NLINES=64TZ=America/Sao_Paulorootmnt=/root
VERBOSE=noroo


I don't even now where to split the lines... but I've made bold a line that I think will also make some difference, sometimes, sh instead of bash.