svlogd in funny states; reason for not integrating into runsv?

svlogd in funny states; reason for not integrating into runsv?

[Adam Megacz]

I've found runsv to be exceptionally reliable in terms of noticing
changes in /var/service/ and adapting its behavior accordingly.
Really solid.

Unfortunately, I have not found svlogd to be as robust.  It often gets
into funny states or fails to pick up changes -- or just never starts
altogether.  This might actually be runsv's fault rather than svlogd's
fault; I guess I'm just saying that the management of the "logging
process" is not as amazingly solid as the management of the "service
process".

Is there a reason why the svlogd functionality is not integrated into
runsv?  It seems that as the parent of the service process, runsv is
in the ideal position to gather and log the process' output.  This
would also keep the process table/tree a lot cleaner; only one
runit-related process per service rather than two.

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Re: svlogd in funny states; reason for not integrating into runsv?

[Charlie Brady]

On Tue, 5 Jun 2007, Adam Megacz wrote:

> Unfortunately, I have not found svlogd to be as robust.  It often gets
> into funny states or fails to pick up changes -- or just never starts
> altogether.

It might help if you detailed exactly what "funny states" you have seen 
svlogd in. And what changes it "fails to pick up". If it doesn't start at 
all then perhaps what is at fault is what is supposed to start it - a run 
script, for instance, might not be executable, or have bad syntax, etc.

> Is there a reason why the svlogd functionality is not integrated into
> runsv?

One reason would be historical - runit in large part is a drop-in 
replacement for daemontools, and daemontools does not implement the 
logging daemon in supervise. There are certainly more reasons, of course.