headers
Rafal Bisingier | 6 Sep 2010 10:52
Picon

Svlogd feature request

Hi,

First of all: thank you Gerrit for a great software. I've been using it
for years now, and am really happy with it. Currently I have some
systems using runit for supervising couple hundreds services, and it
"just works"! But because of this (quite big) amount of services, each
of which is quite "verbose", the volume of produced logs is simply
huge. Moreover I had to transfer all this logs to a remote machine(s)
for archiving/inspection purposes _in_ _real-time_, without mixing them
(so logs from different services must be sorted out to different
directories on the remote machine). Currently I use svlogd
prefixing/sorting functionality with UDP transport layer, but UDP simply
sucks ;-) I'd like to use TCP for sending the logs, but then i'd loss
"real-time transfer" because most of the services produce quite many
log entries, but also evenly "sleeps" for tens of seconds (so I've got
many line of logs, then tens of seconds sleep, and again many lines of
logs, and so on). With TCP transport on log files rotation, even with
very often rotation I'd have some delays in sending logs. So I thought
about aggregating logs from different services in one "sending
service", so the probability of pause in logs growth would be much
lower. The idea is simple: use svlogd to prefix log lines and forward
it to a dedickated socklog instance, which will send them to remote
machine via TCP, and there logs will be sorted (just like I have it
now) based on the prefix added by the first svlogd in the whole process.
The only problem I've got now is how to connect first svlogd
(the one adding prefix) with local socklog. Of course I could use local
UDP transport (to a localhost), but that is not a pretty solution. And
so I thought about adding a "unix socket writing" functionality to
svlogd, just like its UDP capabilities. I've even thought about
creating a patch for this, but my programming skills are way to weak,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ciprian Dorin, Craciun | 14 Sep 2010 13:14
Picon
Gravatar

Improper setting / resetting of the signals mask

    Hello all!

    Sorry for cross-posting, but this "bug" is relevant to both
projects (`runit` and `sudo`), so please forgive me in advance. :)

    In short `sudo` doesn't seem to reset (zero out) its inherited
signal mask, and `runit` seems to leave some signals blocked when
exec-ing children. (And the side-effect is breaking some service
management scripts.)

    Now the long story:
    * (`runit` specific) it seems that when `runit` starts the
`./contro/t` script it leaves some signals blocked (at least the mask
0x14000) (see below in the transcript from `ps s $PID`); (it seems
that this happens only for `./contro/X` and not for the `./run`
scripts;)
    * (`sudo` specific) it seems that when `sudo` starts it doesn't
reset the inherited blocked signals, on which it seems to rely for
detecting when the child process finished; (and this only happens with
the latest versions of `sudo` (`1.7.4p3`), because until now sudo
didn't forked and waited for the child but instead it `execve`-d it;
now because it uses the `pam-session` feature it waits for the child
to terminate...)

    The following snippet is part of the `./control/t` script which
only sends `TERM` followed by `KILL` signals to the service. It uses
`sudo` to elevate the rights from my normal user to that of root.
~~~~
#!/bin/bash
(Continue reading)

Permalink | Reply | 2 comments |
headers
Laurent Bercot | 14 Sep 2010 22:22
Favicon

Re: Improper setting / resetting of the signals mask

>     Hello all!
> 
>     Sorry for cross-posting, but this "bug" is relevant to both
> projects (`runit` and `sudo`), so please forgive me in advance. :)
> 
>     In short `sudo` doesn't seem to reset (zero out) its inherited
> signal mask, and `runit` seems to leave some signals blocked when
> exec-ing children. (And the side-effect is breaking some service
> management scripts.)

 Hello Ciprian,
 If you're going to blame sudo for not resetting the signal mask,
why not also blame bash, which is executed between runsv and sudo ? :)
It seems natural to think that a shell should reset the sigprocmask.
I just checked SUSv3, which says nothing about that; so, by default,
ignoring the sigprocmask is probably the right thing to do, and
bash (for once) gets it right.

 It is debatable whether sudo should be paranoid and also unblock
signals. On the one hand, the *point* of sudo is to be paranoid. On
the other hand, applications can and generally should expect to be
executed in a sane environment, and be liberal in what they accept
(i.e. they should not arbitrarily close fds or remove environment
variables, for instance - and I don't think they should arbitrarily
unblock signals either).

 What is certain is that runsv does the wrong thing here: blocked
signals should definitely be unblocked before exec'ing an external
command. I'm sure Gerrit will agree and fix that in a next release.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane