Politically correct logging 11 October 2018, 22:58:21 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 ./mainwhich 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?
Re: Politically correct logging Reply #2 – 12 October 2018, 06:52:54 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 (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, in /var/log/socklog, but syslog-ng is okay although I never tested it myself) (runitscript does it through logger). Last Edit: 12 October 2018, 07:16:42 by konimex
Re: Politically correct logging Reply #3 – 12 October 2018, 10:42:50 syslog-ng is what I have been using on 2 installations with runit. Everything is ok.
Re: Politically correct logging Reply #4 – 13 October 2018, 12:37:13 So I created a log directory for barrierc service with run executable inside, which looks like this:Code: [Select]#!/bin/shexec svlogd -tt /var/logThe service's directory tree looks like this:.├── log│ └── run├── run└── supervise ├── control ├── lock ├── ok ├── pid ├── stat └── statusThe 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 existrun: 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.
Re: Politically correct logging Reply #5 – 13 October 2018, 13:24:39 Quote from: Everyone – on 13 October 2018, 12:37:13So I created a log directory for barrierc service with run executable inside, which looks like this:Code: [Select]#!/bin/shexec svlogd -tt /var/logThe service's directory tree looks like this:.├── log│ └── run├── run└── supervise ├── control ├── lock ├── ok ├── pid ├── stat └── statusThe 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 existrun: 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. Last Edit: 13 October 2018, 16:59:38 by konimex 1 Likes
Re: Politically correct logging Reply #6 – 13 October 2018, 20:36:50 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 specifiedThe 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 client2018-10-13_18:07:48.32554 [2018-10-13T20:07:48] NOTE: stopped client2018-10-13_18:15:20.59035 [2018-10-13T20:15:20] NOTE: stopped clientI don't get it. What am I missing?
Re: Politically correct logging Reply #7 – 14 October 2018, 02:13:40 Quote from: Everyone – on 13 October 2018, 20:36:50Yep, 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 specifiedThe 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 client2018-10-13_18:07:48.32554 [2018-10-13T20:07:48] NOTE: stopped client2018-10-13_18:15:20.59035 [2018-10-13T20:15:20] NOTE: stopped clientI 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/shexec 2>&1exec daemon-program Last Edit: 14 October 2018, 02:15:39 by konimex
Re: Politically correct logging Reply #8 – 14 October 2018, 21:28:33 Thats it. Now all is working fine, thanks!