9

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

I am using runit under debian, hence:

/etc/service/test is a symbolic link to /etc/sv/test.

Under /etc/sv/test:

$ ls /etc/sv/test
finish  log  run

And /etc/sv/test/log:

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

The run script:

$ cat /etc/sv/test/run
#!/bin/sh

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

while true; do
    date
    sleep 3
done

The finish script:

$ cat /etc/sv/test/finish
#!/bin/sh

kill `cat /tmp/pid`

And the log script:

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
Abdelhakim AKODADI
  • 105
  • 3
oz123
  • 1,198
  • 5
  • 16
  • 32
  • 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.) –  Feb 07 '15 at 09:27

3 Answers3

6

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.

Avery Payne
  • 14,326
  • 1
  • 48
  • 87
4

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
oz123
  • 1,198
  • 5
  • 16
  • 32
  • 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: © http://smarden.org/runit/svlogd.8.html – hryamzik Mar 11 '16 at 13:49
0

There are some things that you didn't ask about in your question, and they probably won't affect the behavior of your setup. But they are just not right and worth pointing out.

  1. The finish script is not intended to kill the service. It is used to clean up after the service when it's finished. I don't think you need it in your use case. runsv already knows how to terminate the service. For that, I'll let you read more in the runsv man page.

  2. If you ever need the PID of the service, you can get it from /etc/sv/test/supervise/pid. But chances are, you will never need it.

Now to diagnosis of the problem you asked about. The logs aren't working probably because you added log/run after enabling the service. Therefore, the log/supervise directory didn't get created.

To check if what I'm saying is true. Check if the directory is there by issuing the command ls /etc/sv/test/log/supervise. You should get something like this.

$ sudo ls /etc/sv/test/log/supervise
control  lock  ok  pid  stat  status

If instead you get the error ls: cannot access '/etc/sv/test/log/supervise': No such file or directory. Then disable and re-enable the service. ie. Remove the symlink to runsvdir/default/ and create it again.

Abdelhakim AKODADI
  • 105
  • 3