So I converted to Runit a while ago and noticed lately that while removing OpenRC I've lost most of the logging ability. After rearming myself with knowledge from Artix wiki and Runit doc pages I got around to bringing up those logging facilities. However in Runit's FAQ in an example log run script I noticed this:
#!/bin/sh
exec chpst -ulog svlogd -tt ./main
which basically means, that log files will be put in the service's log/main subdirectory. Now for centuries the only place, I ever looked for log files, used always to be /var/log, but with Runit being daemontools compatible and all maybe this is different? So should I keep log files traditionally in /var/log or should they be where the services are? What's the right / proper / good practice way? Or maybe is there no right way and I'm just tripping over too much freedom?
/var/log
svlogd is what you make it. So you can change ./main to /var/log/software_name (make sure the directory exists though) and call it a day. (chpst is only needed if you want to)
Most of our runit service scripts don't have any logging, but for those do (e.g. OpenNTPD (https://github.com/void-linux/void-packages/blob/master/srcpkgs/openntpd/files/openntpd/log/run) (yes it's from Void, almost all of our runitscripts are based on Void's), etc.) they're handled using your favorite syslog (runit standard is socklog which uses svlogd (https://gitea.artixlinux.org/packages/socklog/src/branch/master/repos/community-x86_64/socklog.sv.logrun), in /var/log/socklog, but syslog-ng is okay although I never tested it myself) (runitscript does it through logger).
syslog-ng is what I have been using on 2 installations with runit. Everything is ok.
So I created a log directory for
barrierc service with run executable inside, which looks like this:
#!/bin/sh
exec svlogd -tt /var/log
The service's directory tree looks like this:
.
├── log
│ └── run
├── run
└── supervise
├── control
├── lock
├── ok
├── pid
├── stat
└── status
The supervise directory with its contents was created automatically. However when I run the service and check its status with
sv status barrierc, I get this warning message:
run: barrierc: (pid 11291) 5s; warning: barrierc/log: unable to open supervise/ok: file does not exist
run: log: (pid 11291) 5sCreating
/etc/runit/sv/barrierc/log/supervise directory does not help. Also, I don't see any svlogd process running, and no log files for barrierc are generated in
/var/log. I don't know whether I'm doing something wrong or if it's a problem somewhere.
Have you disabled and re-enabled the service?
# rm /run/runit/service/barrierc
# ln -s /etc/runit/sv/barrierc /run/runit/service/barriercI can reproduce this but once I disabled and re-enabled the service the log service started normally.
Also, I wouldn't recommend to place the log in
/var/log for a simple reason: The log will be named
current (see
man 8 svlogd for more details), so the log file will be
/var/log/current not
/var/log/barrierc/current. It
will clutter your directory since the log will be rotated accordingly and the naming scheme will be
@timestamp.s (e.g.
/var/log/@400000005b5eaf9612db81cc.s). So I recommend it to be
/var/log/barrierc instead.
Make sure you ensure the
/var/log/barrierc directory exist! Just a simple
[ ! -d /var/log/barrierc ] && mkdir -p /var/log/barrierc check will do.
Yep, reenabling the service did the trick. But now I'm noticing something else. htop is showing this process:
runsvdir -P /run/runit/service log: [2018-10-13T20:23:27] WARNING: secondary screen unavailable: unable to open screen .No protocol specified
The message in white actually comes from barrierc (it always spits out a lot, when it cannot find the server), which means that its log messages are going somewhere, but all I can find in /var/log/barrierc/current is some info from closing the service when I was testing:
2018-10-13_18:05:22.67314 [2018-10-13T20:05:22] NOTE: stopped client
2018-10-13_18:07:48.32554 [2018-10-13T20:07:48] NOTE: stopped client
2018-10-13_18:15:20.59035 [2018-10-13T20:15:20] NOTE: stopped client
I don't get it. What am I missing?
While I'm not sure that the message actually comes from barrierc (and I'm not sure if it's from stderr), try this:
In the
main ./run file (not the log), add
exec 2>&1 before the actual daemon execution (haven't tested
exec daemon 2>&1 but you can try it)
#!/bin/sh
exec 2>&1
exec daemon-program
Thats it. Now all is working fine, thanks!