On Fri, Apr 20, 2018 at 3:23 PM, Denys Vlasenko
wrote:
>> What's missing or needs improvement?
>>
>> ifplugd_handler needs a better way to code for the "if service FOO exists,
>> start it, if it does not, it's fine" idiom.
>
> Surprisingly, there is no way to do this elegantly in a script.
>
> "test -d /var/service/DIR" depends on the fact
> that service dirs are in /var/service - which may be not true
> for some other daemontools-like installations. I don't like it.
>
> daemontools "svok SERVICE" (which now exists in current git,
> but not in 1.28.3) is better, but it emits an error message
> if SERVICE does not exist: it's defined to be silent only
> if supervisor is not running, not if service does not exist
> at all.
>
> I can just blindly run "svc -u/-d SERVICE" and ignore error
> messages. But how admin is to know that error is ok here?
A bit more brainstorming.
Another thing which needs some sort of agreement
among the distros:
How logging is specified?
As I see it, services fall into these categories
(with examples):
(a) Service wants to save a log, with reasonable size
(let's call it "default size as decided by the distro").
Say, ntpd: you want to have some history how it behaved
over time. Not something sadistically long, neither too short.
(b) Service wants to save a log, but it's not very important.
Say, gpm (mouse-handling thingy for VTs). I'm getting
about this much output each boot:
2018-04-24_07:05:00.75628 *** debug [daemon/add_mouse.c(50)]:
adding mouse device: /dev/input/mice
2018-04-24_07:05:00.75629 *** debug [daemon/add_mouse.c(98)]:
adding mouse type: ps2
2018-04-24_07:05:00.75629 *** debug [daemon/init_mice.c(39)]:
initialize /dev/input/mice with proto ps2
2018-04-24_07:05:00.75630 *** debug [daemon/init_mice.c(46)]:
finished initialization
2018-04-24_07:05:00.76843 *** debug
[daemon/get_console_size.c(45)]: Screen size: 80 - 25
2018-04-24_07:05:00.76844 *** debug
[daemon/get_console_size.c(62)]: x 10, y 20
2018-04-24_07:05:00.76845 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:05:00.76846 *** debug [daemon/getmousedata.c(60)]:
Error in protocol
2018-04-24_07:05:46.44039 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:05:52.49343 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:05:52.49348 *** debug [daemon/getmousedata.c(60)]:
Error in protocol
2018-04-24_07:06:12.05476 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:06:58.13655 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:06:58.13661 *** debug [daemon/getmousedata.c(60)]:
Error in protocol
2018-04-24_07:07:17.21047 *** debug [daemon/old_main.c(158)]:
selected 1 times
It is useful when/if I need to debug it, otherwise, saving e.g. 10
megabytes of such
"precious data" would be a waste of space.
(c) Service does not want to save any log. It will present errors elsewhere.
E.g. getty shows error messages on the tty it serves.
(d) Service usually does not want to save any log. If something goes wrong,
it'll exit with short (typically one-line) error message. Otherwise,
it'll present errors elsewhere. Example is the same: getty. In my current setup,
if getty service fails "catastrophically" (no tty), no messages
are emitted anywhere: stderr is redirected to >/dev/null.
It would be better to capture them.
IOW: we have two broad subclasses: services which want logging, and
services which
do not want it (but may benefit if their errors are channeled to a
single common log
of "not very talkative, not very important services").
As it stands now, for runit tools, services' stdout goes to wherever runsvdir's
stdout is directed (/dev/null in my case), stderr goes to runsvdir,
which in turn "rotates" it on its command line (which is visible in ps output).
This is a fairly limited in usefulness feature (one line of error visible, max),
and it can be disabled by deselecting FEATURE_RUNSVDIR_LOG.
Anyway, I digress a bit. My question is: how service should specify the desired
behavior, _in a distro-agnostic way_? Specifically:
(1) If you fall into the class of "not wanting to save the log",
currently I just don't have a log/ directory there. But I also use
exec >/dev/null 2>&1
at the beginning... because current way how runsvdir handles "non-logged"
services is stupid. Oh well, it's not that bad. Basically, it goes to /dev/null
(in my setup, with FEATURE_RUNSVDIR_LOG=n).
Probably should stop doing that redirect thing. But ideally, it should
be saved...
and distros should agree on this: "services are allowed to just use their
stdout/stderr for messages, if they don't have log/ service".
(2) Do not invoke "its author's favorite logging tool". Currently I use a
script which runs "svlogd -tt" under "logger" user. But what if distro
wants to use a different logging tool? Different user name? Etc?
Thus, I'm going with the following. All my services which want to be logged
will