What kind of service is runit’s svlogd expecting

loggingrunit

The runit manual states that in the configuration one can use an option to submit logs to:

ua.b.c.d[:port]
tells svlogd to transmit the first len characters of selected log messages to the IP address a.b.c.d, port number port. If port isn’t
set, the default port for syslog is used (514). len can be set through
the -l option, see below. If svlogd has trouble sending udp packets,
it writes error messages to the log directory. Attention: logging
through udp is unreliable, and should be used in private networks
only.

I know that rsyslogd is running list on this port.
So this could be one possible option…
But are there any other?

Best Answer

The question is slightly vague, but from the sound of it, I think you are asking if you can use svlogd to send syslog messages to another program besides rsyslogd. The answer is, any program that provided a syslog service would suffice. There is more than just rsyslogd that provides a syslog network service.

However, the way runit was intended to "natively" handle logging is probably backwards from what you are thinking.

The idea is that you have a service of some kind, and that service writes output through stdout or stderr. The runsv program will bring up svlogd and erect a pipe between your service and svlogd; all your service has to do is send data to stdout/stderr, svlogd will write directly to disk, and life is good. Because the pipe is maintained by runsv, should there be issues with the service going down, output is still captured and delivered to svlogd - so in theory, you don't loose logging data due to a service crash.

There is another program by the same author, socklog, that acts as a syslog front-end that funnels to a svlogd. Because there are a lot of programs that just assume that /dev/log is available, socklog provides this interface so that syslog data can be captured - it acts as a substitute syslog service. This is the opposite of what you are suggesting.

I'm not saying you shouldn't use syslog, I'm just saying that there's more than one way to do this. If you really want to shunt your output from svlogd back to syslog, then yes, any old syslog service will do just fine, but it may be worth considering going "all native" and ditching rsyslogd altogether, if your installation permits this.

Related Solutions

Linux – Filter out a facility in syslog-ng

I got the answer.

We can create filters using the filter keyword:

filter <filtername> { expression; };

Where expression is a simple boolean expression. You can use "and", "or" and "not" to connect builtin functions. Functions can be one of:

facility(list of comma seperated facility names)
level(list of comma seperated priority nammes OR a range separated by "..")
program(regexp to match program name)
host(regexp to match program name)
match(regexp to match program name)

So, if we want to add our own program, for example "pm", to the filter use it like this:

filter f_filter2 { level(info..emerg) and not facility(mail,authpriv,cron) and program(pm); };

And if we want to filter out the log messages of "pm", use the filter like this :

filter f_filter2 { level(info..emerg) and not facility(mail,authpriv,cron) and not program(pm); };

RUNIT – created first service directory, “sv start testrun” does not work

Your service isn't set up correctly. The reason it worked is that you invoked it directly from the service definition and not from the actual service control.

When runit's service management starts, it expects a /service directory to exist, although some installs (like Debian Jessie) currently have it at /etc/service for reasons unknown. The error message comes from this missing directory, which it is trying to change to, hence the unable to change service directory message. Do the following as root:

mkdir -p /etc/service
cd /
ln -s /etc/service
cd /service
ln -s /etc/sv/testrun

This will:

create the service directory if it doesn't exist
place a symlink in the root so that runsvdir will be able to change to /service as its working directory
creates a link to your testrun service, assuming you have it defined at /etc/sv/testrun

runsvdir will then be able to change its directory into /service, find your symlink for testrun, and then launch it. You can verify this by using ps fax or pstree -A to see the process tree; there should be a runsv with your command attached to it. Note: sometimes it may take a second or two for the runsvdir process to get its head oriented, so if you look right away and don't see it in the process tree, wait 2-3 seconds and try again, and it should show up. This appears to only happen when it starts up.

Best Answer

Related Solutions

Linux – Filter out a facility in syslog-ng

RUNIT – created first service directory, “sv start testrun” does not work

Related Topic