This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: crontab 1.12 issuing error about

----- Original Message ----- 
From: "Larry W. Virden 
To: Cygwin
| --- On Mon, 10/26/09, Pierre A. Humblet <> writes:
| > Up to now you have only described Windows problems:
| > CAS\Olentangy probably cannot login as a service or has the
| > wrong password
| > and there is some permission issue using cygrunsrv for
| > querying.
| >
| > You didn't explain what you did that caused cron to run
| > under CAS\Olentangy
| > and you never got to the point where cron was running and
| > producing any output.
| Is there a web page somewhere that my administrator can read about 
| the setup? We've been googling and trying things described at sites like
| . Following that 
| cygwin-cron information, he installed the cron parts, changed the 
| permissions, ran the cron-config, ran the crontab -e. The cygrunsrvc 
| says that the cron service has been defined. From reading those 
| instructions, we expected that the cron would be running.

There are instructions in /usr/share/doc/Cygwin/cron-XXX.README
In principle running cron-config and reading the crontan and cron man
pages suffice.
In your case the main problem is the way you have setup the CAS\Olentangy
user. You have never explained that. So the suggestion is to reinstall with
cron-config and run cron under the SYSTEM account.

| >
| > As you have Windows XP you could run the cron daemon under
| > the system account.
| >
| > To debug the TapiSrv error, could you run
| > cygcheck -srv
| > and
| > cygrunsrv --list --verbose
| > and see if they produce that error?
| > You may have to redirect stdout to /dev/null to isolate
| > stderr.
| Thanks for the guidance. When the admin runs
| $ cygrunsrv -srv > /dev/null
| cygrunsrv: --termsig is only allowed with --install

Thanks but my request was to run "cygcheck -srv"

| Try 'cygrunsrv --help' for more information
| $  cygrunsrv -Q cron
| Service             : cron
| Display name        : Cron daemon
| Current State       : Stopped
| Command             : /usr/sbin/cron -n
| $ cygrunsrv --list --verbose
| Service             : cron
| Display name        : Cron daemon
| Current State       : Stopped
| Command             : /usr/sbin/cron -n
| stdin path          : /dev/null
| stdout path         : /var/log/cron.log
| stderr path         : /var/log/cron.log
| Environment         : CYGWIN="ntsec"
| Process Type        : Own Process
| Startup             : Automatic
| Account             : CAS\Olentangy

Thanks, everything is OK.

| We tried to run cron directly from the command line, to see if we 
| could get some kind of error message, and it started, but in the 
| event log we found:
| 2009/10/26 15:07:01 [ntsa13] /usr/sbin/cron: PID 18644: (lwv27) CMD 
| (/home/lwv27/bin/tstbash.txt > /tmp/bash.txt 2>&1)
| 2009/10/26 15:07:02 [ntsa13] /usr/sbin/cron: PID 18644: (CRON) error 
| (can't switch user context)
| 2009/10/26 15:10:01 [ntsa13] /usr/sbin/cron: PID 16116: (lwv27) CMD 
| (/home/lwv27/bin/cron.sPATH)
| 2009/10/26 15:10:01 [ntsa13] /usr/sbin/cron: PID 16116: (CRON) error 
| (can't switch user context)

That makes perfect sense. cron started under the ntsa13 account (the admin)
and could not run your (lwv27) crontab.
Did you see anything in the log about ntsa13's crontab commands?

| During searching on the internet, etc. about this error, I ran across 
| a reference to needing a passwd -R with Cygwin 1.7 so that the cron 
| could change users.

Yes, that's an alternative that avoids issues with network drives etc..
I have never tried it. You may want to start a separate thread 
to report that problem, I am not sure if the passwd maintainer will read this.
| When I try to register my passwd, I get this in return:
| $ passwd -R
| This functionality stores a password in the registry for usage by services
| which need to change the user context and require network access.  Typical
| applications are interactive remote logons using sshd, cron task, etc.
| This password will always tried first when any privileged application is
| about to switch the user context.
| Note that storing even obfuscated passwords in the registry is not overly
| secure.  Use this feature only if the machine is adequately locked down.
| Don't use this feature if you don't need network access within a remote
| session.
| You can delete your stored password by specifying an empty password.
| Enter your current password:
| Re-enter your current password:
| Storing password failed: Function not implemented
| When the administrator tries to run
| $ passwd -R lwv27
| all that we see is the USAGE statement for passwd.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]