On Wed, Oct 24, 2018 at 11:51:07AM +0200, Evilham wrote:

[cut]

>
> I'll just add that when I use runit, I use svlogd. The main reason for
> this being that it is guaranteed to just do the right thing with the
> signals sent by sv and it is flexible enough.
>
> That being said, logger probably does work well; I just haven't given it
> a shot :-).
>
> Basically: if I were to do this, I'd probably go with svlogd because it
> feels more future-safe (packaged together, signal interactions
> documented, thought to work with runit).
> But also it is unlikely that logger changes too much to make it
> incompatible with runit.

If I could add my 2 cents, I would avoid to use a custom logger daemon
like svlogd, for the simple reason that there is a standard to manage
syslog events already, and a pretty flexible one, which works in any
POSIX environment. And this standard is the syslogd protocol (whatever
is the actual system log daemon you are using, i.e., rsyslogd,
busybox-syslogd, syslog-ng, etc.).

If runit needs to have stuff that does not/cannot call use the
standard syslog() interface, then it's much better to stick with
`logger(1)`, which can read from standard input and use the syslog()
interface on behalf of its users. This way, you don't need to have
both a system log daemon (that you will have around anyway) and svlogd
just to manage those cases. Unless there is something specific that
runit needs about svlogd and of which I am unaware (ignorance is
bliss, sometimes ;))

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]