This is the mail archive of the
mailing list for the Cygwin project.
Re: cron on Win9x works
"Igor Pechtchanski" <pechtcha at cs dot nyu dot edu> wrote in message
news:Pine dot GSO dot 4 dot 44 dot 0304111656100 dot 26381-100000 at slinky dot cs dot nyu dot edu dot dot dot
> On Fri, 11 Apr 2003, BB wrote:
> > Igor,
> > ----------------------
> > cron/crontab on win9x:
> > I don't think there is any way to change a directory's creation time on
> > Win9x, so cron cannot be signalled to read the new tabs. The CreatFile
> > FILE_FLAG_BACKUP_SEMANTICS is what does it on NT/2K/XP.
> > According to the MSDN, the flag is not supported on Win9x.
> According to MSDN, you cannot open a directory using CreateFile at all on
> Win9x. You should use CreateDirectory.
CreateDirectory creates a directory, it doesn't open it. It doesn't return
to the directory. Using CreateFile on WinNT/2K/XP, the directory handle is
passed to SetFileTime.
> > Based on the cron code, if cron detects a more recent timestamp on the
> > file "/etc/crontab", the directories "etc/cron.d" or /var/cron/tabs", or
> > any previously processed tab file in "/etc/cron.d", it totally rebuilds
> > it's database. crontab only touchs the "/var/cron/tabs" directory. On
> > Win9x, cron will not detect new or deleted file in either "etc/cron.d"
> > or modified files in "/var/cron/tabs". This is because Win9x does not
> > updated the directory timestamp when the contents change and utimes does
> > not work when crontab tries to update tabs.
> > Maybe on Win9x, a simple solution would be to define a new file that
> > crontab creates if not there and touches if there. cron would use that
> > file's timestamp also, rebuilding the entire list if it has a more
> > recent timestamp. This would solve the crontab problem but not the
> > problem if a new file is added to /etc/cron.d".
> I'm just browsing MSDN, and it seems like using
> FindFirstChangeNotification in cron might be a possibility. See
This looks promising. If it worked for Win9x, it would probably be ok
for NT also. I'll definitely look into this.
> Another possibility, as I mentioned, would be to use CreateDirectory in
> > Or, possibly a better solution to solve the problem totally on win9x,
> > cron could always get the latest timestamp of all files in "/etc/cron.d"
> > and "/var/cron/tabs" and use that timestamp as the new timestamp for its
> > database. It's a little more processing every 60 seconds, but wouldn't
> > the directories be cached in memory so there would be no disk access?
> > It already does this for files in "/etc/cron.d". I plan to try this out
> > because I need a solution for this.
> This would be a last resort, I'd guess, if it really does turn out to be
> impossible to change the timestamp on a directory in Win9x (although I
> have a gut feeling that it should be quite possible, we just don't know
> > --------------------
> > cygrunsrv on Win9x:
> > When running cron as a 9x 'service', hiding the window is not the only
> > problem. Getting the app to terminate when the system shuts down is the
> > problem I've been dealing with. By using an win gui app, I can monitor
> > the messages to a hidden window to get the ENDSESSION message. But, any
> > code you have might help, especially if it eliminates the need to make
> > it a GUI app with a hidden window.
> Umm, not really... But it does eliminate the windows created when the
> service is run...
> > After a quick analysis, I think cygrunsrv could be modified. If I
> > cygrunsrv, I think I would need to change it to use WinMain() so it's a
> > GUI app. On Win9x, it would create a window so it could get the
> > ENDSESSION message at system shutdown.
> Hmm, I suggest another approach: write a rudimentary service manager for
> Win9x. This is not as bad as it sounds: you'll have only one process that
> will watch for the ENDSESSION message, and it'll have a similar interface
> to the NT service manager, so cygrunsrv wouldn't need to be changed
This sounds like more work than I have time for now. I need a quick
get cron and init running as Win9x services with no window and a clean
Rebooting the machine is not a problem to get it going for my 'short term'
I'll think about it over the weekend. I would imagine on Win9x the cygwin
manager could be a GUI app that is started based on a RunServices entry.
What method of communication between cygrunsrv and the services manager
would you suggest for registering, unregistering, starting and stopping
> > Option -I would write an entry to the regitry key
> > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
> > such as init with the string value value C:\cygwin\cygrunsrv.exe -S init
> > It would need to store the parameters for init somewhere. Maybe they
> > could be stored in an init key under RunServices.
> Or we could create a completely new key... ;-)
> > The -S option on Win9x would only be modified to run the service rather
> > than call the service manager to start it. This is how Win9x would call
> > cygrunsrv at startup. The options stored in the registry would be used
> > to run the service. cygrunsrv wouldnt return in this case until the
> > service exited. register_9x_service(); would be called so the service
> > would not be shut down when the user logs out. On Win9x, a hidden
> > window would be created so the app would be terminated at system
> > shutdown. On termination, the term signal would be sent to the
> > 'service'. If you have a better way to hide the window, maybe WinMain
> > would not be needed.
> The "service manager" could be a GUI app with a hidden window. It'll only
> need to respond to the messages from cygrunsrv and the ENDSESSION message.
> > By the way, is there and existing function that will convert the WinMain
> > lpCmdLine or GetCommandLine() arguments to argc, argv format?
> Yes. It's called WinMain in MSVCRT*.dll (or other C runtimes).
> > The -R option would simply remove the registry entries
> Makes sense.
> > The -E stop option would not be supported.
> Why not? If we have our own "service manager", it could simply issue a
> signal to the service app, same way it happens on NT...
> > To actually run a service based on the RunServices registry entry, the
> > system would need to be shut down and restarted.
> Ugh... Ugly. I'd much rather the "service manager" always ran as service
> (so restart is unavoidable if you want to start it), but later any
> services you wish to run could be run through the already running service
> (thus no restart required).
> > BB
> > "Igor Pechtchanski" <pechtcha at cs dot nyu dot edu> wrote in message
> > news:Pine dot GSO dot 4 dot 44 dot 0304101446040 dot 8014-100000 at slinky dot cs dot nyu dot edu dot dot dot
> > > BB,
> > >
> > > I applaud the effort. I think it would be terrific to have a
> > > equivalent on Win9x systems. I don't know how far you've gotten in
> > > of design, but here are a few suggestions:
> > >
> > > - instead of creating yet another program, we should probably change
> > > cygrunsrv to do something different on Win9x. That way, the READMEs
> > > (and some scripts) will apply
> > >
> > > - if you need help hiding that command window, I have code
> > > that's been tested on Win9x (I think the command interpreter on
> > > is actually "command.com", not "cmd.exe", though)
> > >
> > > - utime() is unimplemented for directories at all... I don't know
> > > even works on WinNT/2k/XP... Corinna?
> > > Igor
> > >
> > > On Thu, 10 Apr 2003, BB wrote:
> > >
> > > > I've notice some discussion about problems running cron on Win9x.
> > > > I'm currently running cron and init on Win95. Win98 works too.
> > > > I'm not running anything complex with cron yet though.
> > > > Unfortunately, I'm stuck in Win9x mode, but at least I'm being paid
> > > > for it.
> > > >
> > > > One thing that is required is the addition of
> > > > "SYSTEM:*:18:544:,S-1-5-18::"
> > > > to the /etc/passwd file.
> > > > The ",S-1-5-18" part probably isn't required, but I just simply
> > > > the
> > > > entry from an XP machine. I also added "SYSTEM:S-1-5-18:18:" to
> > > > /etc/group
> > > > but I don't think it matters.
> > > >
> > > > -----------from cron.h----------------
> > > > #ifdef __CYGWIN__
> > > > #define ROOT_UID 18
> > > > #define ROOT_USER "SYSTEM"
> > > > #else
> > > > -------------------------------------
> > > >
> > > > Try adding the SYSTEM user as mentioned above and then run
> > > > /usr/sbin/cron -D. In this case, the window it is running in will
> > > > remain open. If you run it without the -D and then try to exit from
> > > > the cmd window, the window will not close until you kill cron.
> > > >
> > > > I am in the process of writing a cygwin /windows gui app (cygruncmd)
> > > > modeled around the service_main() of cygrunsrv. It will fork and
> > > > exec a cmd (i.e. cron or init) redirecting stdout output the to a
> > > > log such as /var/log/cron.log as cygrunsrvdoes. I also plan to use
> > > > it to run init on Win9x for agetty. It needs to be a windows gui
> > > > app so I can monitor system shutdown and kill the cmd when the
> > > > system shuts down. An option to the app will be to run with the
> > > > window hidden. Another option might be to respawn when the cmd
> > > > exits. Which gets me to another option I might try, running cron
> > > > from init. Not sure about this one.
> > > >
> > > > A few additional notes:
> > > > 1. cron doesn't seem monitor system clock changes as far as I can
> > > > tell. So if the time is adjusted backwards say from 11:00am -
> > > > 10:00am, when cron wakes up and adds 60 seconds to its previous time
> > > > of 11:00 to 11:01, it will wait an hour before it wakes again. I
> > > > guess this could be a problem in the fall if the change in time is
> > > > automatic. If manually changing the time, restarting cron is the
> > > > solution as long as the use knows about the problem.
> > > >
> > > > 2. On Win9x, crontab cannot touch the time on "/var/cron/tabs", so
> > > > cron doesn't notice a change. You can get around this my runnning
> > > > the following commands, but you MUST not remove the tabs directory
> > > > close to the 0 second or cron might exit when it wakes up and cannot
> > > > find tabs. Maybe crontab could be enhanced to make sure the
> > > > directory time is modified on Win9x systems. This workaround is
> > > > fine for me right now. I plan to insert a call to a program that
> > > > waits until 30 seconds after the minute so cron doesnt fail between
> > > > the cp and mv.
> > > > ------------------------------------------
> > > > rm -R -f /var/cron/tabs.sav
> > > > cp -R /var/cron/tabs /var/cron/tabs.sav
> > > > rm -R -f /var/cron/tabs
> > > > mv /var/cron/tabs.sav /var/cron/tabs
> > > > ----------------------------------------
> > > >
> > > > Hope this helps.
> > > > [snip]
> > > > BB
> |\ _,,,---,,_ pechtcha at cs dot nyu dot edu
> ZZZzz /,`.-'`' -. ;-;;,_ igor at watson dot ibm dot com
> |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
> '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
> Knowledge is an unending adventure at the edge of uncertainty.
> -- Leto II
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html