Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at
all"):
> On 01/19/2014 08:15 PM, Ian Jackson wrote:
> > * The daemon does not double-fork; it runs in the foreground of
> > of its initial process.
>
> Something like start-stop-daemon then? :)
Err, no, becase...
> See also the command_background directive (in the man openrc-run).
(http://manpages.debian.net/cgi-bin/man.cgi?query=openrc-run&apropos=0&sektion=0&manpath=Debian+experimental&format=html&locale=en
=> Sorry, no data found for `openrc-run'.
I dgit cloned the package from experimental and used `man -l'.
Perhaps manpages.debian.net isn't working or hasn't updated yet.)
> On 01/19/2014 08:15 PM, Ian Jackson wrote:
> > * The daemon's parent process (part of the init system) keeps
> > track of it, so the init system knows whether the process
> > is still running.
>
> First, OpenRC isn't stateless like sysv-rc to begin with (try
> "rc-status" to see what daemon is running). Status are kept in
> /run/openrc/started using symlinks to /etc/init.d, and OpenRC uses
> (optionally) cgroups to shutdown daemons, if that's what you ask.
Having looked at the FM for openrc-run, no, this is not what I meant
by a non-forking daemon startup.
I meant that the long-running process's parent is some kind of
supervisor process which will respond to information about its child's
process lifecycle (using SIGCHLD, waitpid). (And that the
long-running process inherits, and does not close, a sensible stderr.)
And I don't think cgroups is the right answer.
> Then, the answer to this question is even more definitively "yes", if
> you use this patch:
> https://github.com/qnikst/openrc/compare/s-vision
You're suggesting then to use monit. Are you saying that all of the
daemons in Debian ought to be converted to run under monit and that
this should be the default mode of operation ?
I just read the monit(1) manpage and saw this:
| Monit detaches from the console, puts itself in the background and
| runs continuously, monitoring each specified service and then goes
| to sleep for the given poll interval, wakes up and start monitoring
| again in an endless cycle.
This is probably great for a server system monitoring setup. But it's
not really how an init system has to work. Also, monit has a lot of
functionality which has nothing to do with init system.
Also I saw this in the section on service entry keywords:
| pidfile Specify the process pidfile. Every
| process must create a pidfile with its
| current process id. This statement should only
| be used in a process service entry.
Are you _sure_ monit doesn't expect daemons to fork ? Why does it
need a pidfile ?
> On 01/19/2014 08:15 PM, Ian Jackson wrote:
> > * The daemon's stderr goes somewhere reasonable.
>
> Hum... By default, I honestly don't know what would be the behavior of a
> daemon doing some output to stderr. However, I believe it'd be really
> trivial to do in the command= statement of a runscript. Something like:
>
> command="foo >/var/log/foo.log 2>&1"
>
> or using the command_arg directive should be enough (I haven't tested,
> but this seems reasonable).
Oh god, please no more of this kind of thing. My inittabs are already
full of it and this is what I'm trying to get rid of.
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21213.3822.956408.221...@chiark.greenend.org.uk
