This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Suggest cygrunsrv extension: --pidfile option (patch included)
On Nov 21 20:36, Christian Franke wrote:
> Corinna Vinschen wrote:
> > -int server_pid;
> > +int terminate_pid;
> >
> >I don't see a reason to change the name of this variable. server_pid is
> >still correct, so I'd rather keep it.
>
> No, the variable now contains the parameter for the kill() in terminate
> child:
> No pidfile: -pid (to kill pgrp as before)
> With pidfile: pid (to kill single process, see below)
It did that before. The pid is still the pgid or the pid of the server
process. The name change is somewhat arbitrary.
> > + /* Save time if old pid file exists */
> > + time_t forktime = 0;
> > + if (pidfile_path && !access(pidfile_path, 0))
> > + {
> > + syslog (LOG_INFO, "service `%s': old pid file %s exists",
> > + svcname, pidfile_path);
> > + forktime = time(0);
> > + sleep(1);
> > + }
> > +
> >
> >How do you save time here?!? This looks confusing.
>
> Time is saved if old pidfile exists, read_pid_file() will later accept
> only files newer than this timestamp.
> This should work to detect stale pid files.
Ouch. The comment lead me on an entirely wrong track. I understood
that you were saving *time*, not a *timestamp*. I didn't see how that
would be possible with this extra test and log entry.
Could you please change the comment to "Save timestamp if ...", maybe
with a reference to the later usage?
> >Bottom line, shouldn't the existence
> >of the pid file result in complaining with LOG_ERR and exiting?
>
> It depends, 33.3% of my initial test cases (syslogd, xinetd, smartd)
> would not work in this case ;-)
>
> Cygwin syslogd *always* leaves a /var/run/syslog.pid behind.
>
> As an alternative, /proc could be scanned for existing processes at
> least if pidfile exists.
Sounds interesting, but I think scanning /proc is dangerous, because of
Windows reusing of PIDs a lot. You would have to test if the process
really belongs to this pidfile, too.
If the service has been started by SCM, we wouldn't be here, since SCM
wouldn't let us start the service twice. So, when we arrive at this
point, the pid file either indicates a running service process which is
not under control of SCM anymore, or it's just a stale PID file.
If the process still exists, we're a bit in trouble. In this case the
above log message hopefully helps. Otherwise, maybe cygrunsrv should
remove the pid file when the service is stopped. That should help in
the cases were daemons refuse to run when the pid file exists, shouldn't
it?
> > + if (read_pid != -1)
> > + {
> > + /* Got the real pid, daemon now running */
> > + terminate_pid = read_pid; /* terminate this pid (pgrp
> > unknown) */
> >
> >Instead of using the process pid, why not retrieving the pgid of the
> >service process from /proc/$pid/pgid, same as you get the winpid?
> >This would also allow to keep the terminate_child function untouched.
>
> No, this was intentional, yes, the comment is misleading here.
> Daemons should be designed to receive signals only on the "exposed" pid,
> and act accordingly for their child processes.
>
> With no pidfile, sending signal to pgrp is OK.
Ok, maybe a more elaborate comment would be enough.
> Hmm... this is a C++ module with plain C++ comments ;-)
> Today, I consider "// ..." also as plain C comments, these are part of
> C99 (AFAIK).
>
> But I change this to good old K&R style if you want...
Yes, please. I have no problems with using C++ style for short comments
after an expression, but longer comments or comments on their own line
should rather use the K&R style, like this:
/* foo */
/* foo bla ...
... blub */
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/