[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Jun 2012 23:51:25 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
On Sun, 10 Jun 2012 11:13:11 -0400
Rich Felker <dalias@...ifal.cx> wrote:
> On Sun, Jun 10, 2012 at 10:52:26PM +0800, orc wrote:
> > If we need no starting and stopping, than this can be already
> > implemented in init scripts. Only a simple program-wrapper that
> > forcibly daemonizes that daemons with "do not fork" option needed.
> > Optionally it can report a pid after fork() before execvp().
>
> I don't think you're getting the issue at hand. Suppose you want to be
> able to automatically bring down a particular daemon -- perhaps to
> restart it with completely new configuration or to switch to a new
> version of it. This could happen as part of an automated upgrade
> process or under manual admin control.
'Automated' often becomes the source of problems, if this automated
subsystem is not engineered properly. If we want daemon that will be
responsible for other's daemons status and it will start and stop them
automatically based on the admin's decision than it must be
well-engineered and tested in many types of situations first.
>
> Traditional init scripts DO NOT solve this problem. They are extremely
> buggy, ranging from doing things as stupid as killing any instance
> of the daemon
Are you talking about traditional SysV init scripts? Yes, they're
buggy, I fully agree.
> (even one run by a user as opposed to by root with a
> separate config file and running on a separate port)
Killing processes based on uid/gid and cmdline can be achieved with
pkill already,
> to killing
> unrelated processes (by scanning /proc or reading a pid file, then
> subsequently killing the pid which might not belong to a different
> process).
Again, pkill much better than "traditional"
"kill $(cat /var/run/daemon.pid)" that most of init script use today
(Am I right?)
> I agree that the problem of daemons crashing or otherwise exiting
> unexpectedly is one that should be fixed in the daemons. Unfortunately
> that's much harder than it sounds. A large portion of the daemons in
> modern use are using "xmalloc" type wrappers that abort
> unconditionally on malloc failure, either directly or by virtue of
> using atrociously-bad libraries like glib that abort without the
> caller's consent.
I fully agree that the in reality we have no ideal daemons in this
question, many of them are unreliable.
>
> If daemons really didn't exit unexpectedly, the only race condition in
> pid-based approaches to lifetime management would be races between
> multiple scripted administrative actions (e.g. 2 admins trying to down
> the daemon at the same time) which could be fixed by locking at the
> script level.
Hm, for me that situation sounds a bit strange: even script will exit
with 'daemon already stopped' or script will send an additional signal
to daemon that will not harm it such (I omit here talk about
sighandlers, most daemons did not crashed after a second signal if it
was not KILL signal).
I partially agree with approach that such daemon for monitoring status
of other daemons should be developed, but I think this daemon should
control only critical processes for admin, such as:
- syslog daemon (Such situation happened with me when rsyslog crashed
for no reason)
- possibly various daemons for remote network access, such as sshd (?)
- other daemons, if their task is not to write/read something important
from disk. For example, database daemons should NOT be restarted
automatically.
P.S. If you talk about traditional init scripts that to be appear in
most distros today - then I fully agree with you in all aspects you
talked about here. I was paranoid, and rewritten them from scratch back
some time ago.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
