CRON executes CRONTABS only when run from terminal as "/usr/sbin/cron &"

Brian Inglis
Thu Nov 26 04:29:39 GMT 2020

On 2020-11-25 16:13, Stephen Carrier wrote:
>>From an e-mail reply that was not posted to the list:
> On Wed, Nov 18, 2020 at 04:04:40PM -0700, Keith Christian wrote:
>> On Mon, Nov 16, 2020 at 1:49 PM Stephen Carrier <> wrote:
>>> On Mon, Nov 16, 2020 at 12:44:33PM -0800, Stephen Carrier wrote:
>>>> On Sun, Nov 15, 2020 at 02:03:28PM -0700, Keith Christian via Cygwin wrote:
>>>>> Cygwin people,
>>>>> Running with this version of Cygwin.
>>>>> CYGWIN_NT-10.0 DESKTOP-ASERVER 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>>>>> Windows info:
>>>>> $ /lib/csih/winProductName.exeMicrosoft Windows 10 Professional,
>>>>> 64-bit (build 18363)
>>>>> I installed using cron-config, and created the cyg_server user.cron
>>>>> starts OK, but does not appear to execute the crontabs.
>>>>> No messages or errors  in /var/log/cron.log.
>>>>> $ cygrunsrv -Q cron
>>>>> Service             : cron
>>>>> Display name        : Cron daemon
>>>>> Current State       : Running
>>>>> Controls Accepted   : Stop
>>>>> Command             : /usr/sbin/cron -n
>>>> What's the output of "cygrunsrv -V -Q cron"?
>>>> What are the file permissions on /var/log/cron.log? ("ls -l
>>>> /var/log/cron.log").  The uid running cron needs write permission there.
>>>> I run cron from the Local System account, which can setuid to other users.
>>>> I don't know the circumstances where one should still use a non-SYSTEM
>>>> account with Windows 10, but they aren't mine and I recommend running
>>>> as SYSTEM if possible.
>>>> Stephen
>>> I have also found the output of "cronevents" helpful.
>> Stephen,
>> Thanks very much for the reply.
>> The README file may be accurate, but mentions adding users to
>> /etc/passwd, which we left behind a long time ago.
>>              $ ls -l /usr/share/doc/Cygwin/cron-4.1-65.README
>>              -rwxr-xr-x 1 keith keith 5304 Feb 15  2010
>> /usr/share/doc/Cygwin/cron-4.1-65.README
>> Here is the diagnostic output;
>>          $ cygrunsrv -V -Q cron
>>          Service             : cron
>>          Display name        : Cron daemon
>>          Current State       : Running
>>          Controls Accepted   : Stop
>>          Command             : /usr/sbin/cron -n
>>          stdin path          : /dev/null
>>          stdout path         : /var/log/cron.log
>>          stderr path         : /var/log/cron.log
>>          Environment         : CYGWIN=" " TMP="/tmp" TEMP="/tmp"
>>          Process Type        : Own Process
>>          Startup             : Automatic
>>          Account             : .\cyg_server
> This looks OK and verfies that the service is running under 'cyg_server'
> which is not the Local System account.  As I would have expected from
> your description.
>>          $ ls -l /var/log/cron.log
>>          -rw-r--r-- 1 cyg_server None 0 Nov 15 11:11 /var/log/cron.log
> Nothing has been logged, but the service should be able to log here if
> it has anything to say, since cyg_server has write-permission.
>>          $ cronevents | grep error | tail
>>          2020/11/18 15:50:01 [cyg_server] /usr/sbin/cron: PID 10382:
>> (CRON) error (can't switch user context)
>>          2020/11/18 15:50:01 [cyg_server] /usr/sbin/cron: PID 10384:
>> (CRON) error (can't switch user context)
>>          2020/11/18 15:51:02 [cyg_server] /usr/sbin/cron: PID 10387:
>> (CRON) error (can't switch user context)
>>          2020/11/18 15:51:02 [cyg_server] /usr/sbin/cron: PID 10388:
>> (CRON) error (can't switch user context)
> "Can't switch user context" means cyg_server can't change its user id.
> This is exactly what I suspected.  The service would try to change
> user id to the user that submitted the cron job so it can run with the
> privileges of that user.
> (simplifying a bit) In UNIX the user that can change to another uid
> is root.  For windows the SYSTEM user has that ability so running
> services as the SYSTEM user is the easiest thing to do for a service
> (like cron or sshd) that needs to change uid.
> For ancient versions of Windows this was not the case and it was necessary
> to create a special user to own the service, then grant that special
> user special privileges.  The setup script supports that and takes care
> of the details.
> My best recollection is that the setup script will ask if you want to
> create the special user, and if you decline, the script will run the
> service as SYSTEM user.  So what I suggest you try is to uninstall cron,
> and install it again without creating a special account.  See if that
> works better.
> I ask the community at large if the cron configuration script should
> detect whether the SYSTEM user will work and then just set it up that way.
> I think trouble is caused by asking users to decide questions if they
> don't understand the implications of the answer.
> Alternatively, the script could explain that SYSTEM is preferable if
> it will work, along with a brief description of when choosing a special
> user is desirable.
>> I'll wait for your reply before reconfiguring CRON.
> Please don't put me in that position.  I have benefitted from the help of
> others on this list many times, so I try to helpful when I'm in position
> to do so.  I was not and am not the only person who can help you here,
> You might have had a reply sooner if you had replied to the list instead
> of just to me.
> Further, if I say something incorrect, it would be valuable to you and
> me both to have it corrected by someone who knows better.

It seems that as Cygwin lsass appears to no longer be supported, it is no longer 
needed, as long as you run services under the local SYSTEM account, or otherwise 
as explained in the User Guide:

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

More information about the Cygwin mailing list