5

I am having trouble with setting service with proper logging using running. Here is a brief overview of files and scripts I created according to runit's documentation and other resources I found in the internt:

I am using runit under debian, hence:

/etc/service/test -> link to /etc/sv/test.

Under `/etc/sv/test:

$ ls /etc/sv/test
finish  log  run
$ ls /etc/sv/test/log
config  run

The scripts run and finish are pretty simple:

root@data1:/etc/sv/test $ cat /etc/sv/test/run
#!/bin/sh

touch /tmp/pid
echo $$ > /tmp/pid

while true; do
    date
    sleep 3
done
root@data1:/etc/sv/test $ cat /etc/sv/test/finish
#!/bin/sh

kill `cat /tmp/pid`

And the logscript is also very easy:

cat /etc/sv/test/log/run

#!/bin/sh
exec svlogd -t /var/log/test

The directory /var/log/test exists, and the service runs.

$ sv s test
run: test: (pid 11547) 536s; down: log: 1s, normally up, want up

But the log directory is empty ... What am I missing? Where is all the logging information ?

update:

I also made sure all scripts are executable.

update 2:

It seems that the sv fails to start the logging script for some reason!

$ sv s test
run: test: (pid 14612) 5s; down: log: 0s, normally up, want up

update 3:

If you want to stop the logging script you have to issue:

$ sv d test/log
  • The logger is most often just a couple lines that invokes /usr/bin/logger with a service-specific tag or directly to some log aggregator's collection agent (to skip the parsing of syslog steps). (Logs are really streams of events but so are often awkwardly serialized from stderr/stdout to files.) – user31170 Feb 7 '15 at 9:27
4

There are a number of things to address in your question that aren't related to the question (cough pid files cough) but let's tackle the question proper.


First, logging is optional. There is no hard requirement that you have a logger for your service definition, although in most cases you will want one.

Second, because the logger is defacto slaved to your service, it makes sense that ./log holds the needed settings for the logging.

Third, when you bring the service down, the logger is left running for a reason - it is there to capture the remaining data until the service terminates. This was done to prevent loss of logging data, not only as the service comes down, but also if the service should crash. It is normal for the logger to still run even when the service is down. Starting the service will simply reconnect the new service instance to the existing logger.

Fourth, you are correct, you can stop the logger by explicitly naming it with the sv command. This is in keeping with the existing daemontools paradigm.

Fifth, unless you have unusual needs for registering the failure of the svlogd program (highly unlikely) you don't need to worry about killing it, etc. Simply signalling it to go down will cause the runsv supervision process to terminate it, no PIDs or kill commands required.

If you have further questions, I recommend contacting the supervision mailing list, which is low-noise and has lots of knowledgeable people to answer your questions. A read-only mirror can also be found on mail-archive.org.

3

So, after a some trial and error I found a solution.

The following things are important to notice:

  1. Configuration file: note that it's quite counter intuitive. If you have monitored service under /etc/sv/test, and a logging directory under /etc/sv/test/log you would expect that config would be in /etc/sv/test/log/config! But notice, the file is read from where you run svlogd. This means: If your log script runs in /var/log/test (the last argument to svlogd) this is where the config file is expected. So write your configuration in var/log/test/configList item
  2. Reloading configuration: If you change the configuration file, you can stop and start the script with:
$ sv down test/log
$ sv start test/log
ok: run: test/log: (pid 21190) 0s
  • You do not have to restart service/log, HUP signal is enough: On startup, and after receiving a HUP signal, svlogd checks for each log directory log if the configuration file log/config exists, and if so, reads the file line by line and adjusts configuration for log as follows: © smarden.org/runit/svlogd.8.html – hryamzik Mar 11 '16 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.