This is the mail archive of the
mailing list for the Cygwin project.
Re: cron cannot change user
Pierre A. Humblet wrote:
----- Original Message -----
From: "Mike Schmidt" <email@example.com>I will run the debug tonight, unfortunately I have to leave fro the rest
of the day. However, here are some pieces of information:
To: "Pierre A. Humblet" <Pierre.Humblet@ieee.org>
Sent: Friday, August 14, 2009 2:18 AM
| Pierre A. Humblet wrote:
| > ----- Original Message -----
| > From: "Mike Schmidt"
| > To: cygwin
| > Sent: Thursday, August 13, 2009 2:09 PM
| > | On all the systems where cron works I did NOT run cron-config. I used
| > | the following line to install cron:
| > | cygrunsrv --install cron --path=/usr/sbin/cron --desc='Cygwin cron
| > | service' --type=auto --neverexits -a '-n'
| > |
| > | It has always worked for me.
| > |
| > | Nothing cron-related in /tmp
| > |
| > | When it stopped working on 1 system, I ran cron-config on that system.
| > | Here is the result:
| > | <snip>
| > | Running cron_diagnose ...
| > | It appears that you do not have an entry for:
| > | NT AUTHORITY\SYSTEM
| > | in /etc/passwd.
| > OK, that happens because your environment has
| > USERDOMAIN=NT AUTHORITY
| > USERNAME=SYSTEM
| > and that confuses cron-config (it's trying to check you have a passwd entry)
| > I suspect that you are logged in under ssh or some such.
| > It's a Cygwin issue with a long history, but it's not something to worry about for cron.
| > I will fix that test.
| True enough. I am running remotely under ssh at this point. My company
| has a number of digital signage systems in the field running windows (
| Usually it's under linux, but sometimes we have no choice) and I need to
| install cygwin along with ssh and cron snd other stuff to fit my support
| needs. So I try to do this invisibly, since otherwise I am operating in
| full view of whatever audience there may be.
| > | ================================================================
| > | attached is the cronbug.txt
| > |
| > | Note that if I run cron-config on any of the systems that work perfectly
| > | fine, I get the same warnings about the account and the environment, but
| > | when I restore the service with the cygrunserv command above, it works
| > | fine. Only this 1 system refuses. They use the same userids and
| > | configuration as far as I can tell.
| > What do you mean by "refuses"?
| I mean that all the cron jobs on the system that refuses are not
| executed (or their results are not kept)
| > As far as I can see from the log, cron does change to the "impact" user and the command
| > What led you to the "Subject:" of your e-mail?
| > What's happening to all the echo `date` > /tmp/date you have been running recently ?
| > It's kind of weird they don't run every minute.
| The commands don't run as far as I can tell. All of these commands log
| into logfiles in /home/impact, and this works fine if I run cron
| manually (not as a service) or if I run the commands manually under the
| impact account. /tmp/date is properly when cron is not a service. It was
| a debug tool I put in there just to make sure that I had something that
| didn't depend on the account at all. As for the subject of my email, I
| suppose that is more a guess than anything else.
| > I also see some MAIL (mailed 56 bytes of output but got status 0x0001)
| > That would happen if /tmp is not writable. Any reason that would be the case ?
| > Just to be sure, please edit /bin/cronlog and change all "exit 1" to "exit 123".
| .ls -l /:
| drwxrwx---+ 2 SYSTEM root 0 Aug 8 03:59 bin/
| dr-xr-xr-x 1 0 root 0 Dec 31 1969 cygdrive/
| drwxrwx---+ 2 SYSTEM root 0 Jun 16 20:20 dev/
| drwxr-xr-x+ 10 SYSTEM root 0 Aug 2 22:03 etc/
| drwxrwxrwx+ 5 impact None 0 Aug 8 01:20 home/
| drwxrwx---+ 11 SYSTEM root 0 Aug 8 01:10 lib/
| dr-xr-xr-x 1 impact None 0 Nov 30 2006 proc/
| drwxrwx---+ 3 SYSTEM root 0 Jun 16 20:20 srv/
| drwxrwxrwt+ 2 SYSTEM root 0 Aug 13 21:19 tmp/
| drwxrwx---+ 12 SYSTEM root 0 Jun 16 20:19 usr/
| drwxr-xr-x+ 9 SYSTEM root 0 Jun 16 20:31 var/
| ls -l /tmp
| total 1.0K
| -rw-r--r-- 1 impact None 29 Aug 13 04:00 date
| The date file come from the last time I ran cron manually. When the
| system rebooted at 4am (daily reboot) cron came back as a service, and
| /tmp/date stopped.
| None of the log files written by the other commands are modified, and
| one of the commands (./agent.exe register) does a heartbeat via a wget
| to another system, which is definitely not happening.
| After changing the exit 1 to exit 123 in /bin/cronlog, I see no changes.
| What is that supposed to do? I also then commented out the rm commands
| that delete the temp files. Even after the cronevents showed mail
| messages there are none of the expected files in /tmp.
| I noticed on the neighbor system (that works perfectly) that even there
| the events listed in cronevents do not quite correspond to what cron
| actually does. For example, the 'check_jezam' script actually runs
| every minute, based on its own log. But cronevents only records every
| second or third call.
| Back to the broken system: here is the log after I changed cronlog with
| exit 123 and commented out the rm commands:
| 2009/08/13 21:55:02 [SYSTEM] /usr/sbin/cron: PID 2068: (impact) MAIL
| (mailed 56 bytes of output but got status 0x0001
| Note that according to the event log, neither of the scripts that run
| every 5 or 6 minutes are run. The check_jezam script which is supposed
| to run every minute runs less often than the date echo script, even
| though both are sceduled the same.
| In any case, /tmp/date is not written, nor is any of the tmp mail files.
| Nothing is written into any of the logs for agent.exe or check_jezam.
| And no heartbeat is signalled. I'm convinced these jobs are not run,
| even though the cron event log seems to say they are.
| So what can I do to debug this problem? This is driving me nuts!
| Thanks a lot for looking at this with me.
I am completely baffled as well. There are a number of issues.
1) Not all runs are listed by cronevents.
No idea if cron doesn't run (why) or if it's a logging failure.
cronevents is just a utility that dumps selected Windows event log entries.
Could be a bug in cronevents (I doubt it).
Can you access the windows log by using the Windows event viewer (system32/eventvwr.exe) ?
2) Cron starts the command but nothing happens.
3) Some MAIL output fails. Changing the exit status in cronlog was to ascertain if it was due
to an access problem. Now we know it isn't.
What do you mean by "run cron manually". Do you just type /usr/sbin/cron ? As what user ?
Apparently cron used to work. Can you think of what has changed when it stopped working?
Here are two things you could try
1) Run the cron daemon as user "impact" (use cron-config, some log and pid files owned
by SYSTEM have to be deleted)
2) Run the daemon in debug mode
cygrunsrv -I cron -p /usr/sbin/cron -a "-x sch,proc,pars,load,misc"
A lot of debug output will be written to /var/log/cron.log , so stop cron after a few
and send me the file. This will show us if cron works OK every minute, but won't help
commands do nothing.
Unfortunately cron doesn't log exec failures, it just mails them (which requires another
1) I started a manual run as user impact: just /usr/sbin/cron. I deleted
the 0-size /var/log/cron belonging to system , but the pid file was
written without needing to delete it.
2) I checked the event log with sysinternals psloglist, it show the same
as cronevents. No surprise there.
3) I changed the crontab that writes the date to accumulate instead of
overwriting, so we can check how it runs.
4) both the date and the 'check_jezam' script log properly every minute
without fail. (despite what the eventlog says). I will mail these logs +
the eventlog with the debug output tonight.
In the meantime, gotta go. Thanks very very much for your help!
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple