Issue with PID autocreate?

[hongkongkiwi]

Just wanted to create a new issue, I brought this up before, but it might have got lost due to the other issues I was having (since solved), so let me create this as an individual issue.

I'm having trouble to get syslogd & klogd pid autocreate using finit to work.

Have I got the syntax correct? I'm using busybox klogd & busybox syslogd

# Early OOM
service [S12345789] <!> pid:earlyoom /usr/bin/earlyoom -- EarlyOOM daemon
# System log
service [S12345789] <!> pid:syslogd /sbin/syslogd -D -S -n -O /log/messages -- System log daemon
# Kernel Log
service [S12345789] <!pid/syslogd> pid:klogd /sbin/klogd -n -c 1 -- Kernel log daemon

The service runs, but no pid file appears in /run

Finit thinks that the PID file actually exists though: initctl status syslogd

     Status : running
   Identity : syslogd
Description : System log daemon
     Origin : /etc/finit.d/system.conf
Environment :
Condition(s):
    Command : /sbin/syslogd -D -S -n -O /log/messages
   PID file : /run/syslogd.pid
        PID : 1374
       User : root
      Group : root
     Uptime : 10 min 44 sec
   Restarts : 0 (0/10)
  Runlevels : [S12345-789]

[hongkongkiwi]

I'm really not sure why, but now it works ok... if I see this behaviour again, I'll try to figure out what causes it not to write a pid sometimes.

[hongkongkiwi]

So I think I've tracked atleast one issue down.

From what I understand, if the process forks into background (and it's not creating it's own pid) then I should use something like pid:myapp in the service config.

If the process doesn't fork and instead is run in foreground, then I don't need to add anything extra as finit will handle the pid file.

So, in the case of busybox syslogd I should expect that I don't need pid:syslogd because I'm using the syslogd -n flag which keeps it in the foreground. However, finit doesn't agree and for some reason doesn't create the pid.

If instead I explicitly set pid:syslogd and use syslogd -n then it works.

Perhaps syslogd forks even when I tell it to stay in foreground? I think this may also be the case with some other apps. Normally this isn't an issue, but it becomes one because the pid condition is not triggered (although everything else runs normally and finit even knows the correct pid in the status screen).

[troglobit]

OK, let me try to explain this -- it's a bit of a mess so bare with me.

Finit prefers services that run in the foreground and don't fork, usually this means appending -n or -F or similar to the command line. By default a declared service foo's PID file is expected to be created by foo itself in /run/foo.pid, if that's not the case we can create (and touch it) it for them using the pid:/run/foo.pid syntax. However, if foo indeed does create a PID file, but not in the expected location, we can tell finit about this by prepending a ! to the path (i.e., "Hey Finit, do not create the pid file, it's over here ...), like this pid:!/run/bar.pid.

Some services, in particular many BusyBox services, in the past (and some still) do not create a PID file when running in the foreground. I have upstreamed fixes for some of this. It's a combination of bad default behavior really, when running in the foreground many also expect you are "debugging" and want logs on stdout/stderr ...

Now, there are also services that cannot be told to run in the foreground, they always background themselves and detach. Similar to SysV init scripts. For those you can try using sysv pid:!/run/foo.pid foo, which means Finit won't treat a dying PID as something that has to be restated, but instead waits a bit for /run/foo.pid to be created and then uses that to monitor foo.

Hope this clears things up a bit. Maybe this should be put in the docs somewhere ...

[hongkongkiwi]

This is a good explanation, let me test more on this. Will feedback on this thread.

Point of clarification though.... from what you say above, I would need to use the sysv definition instead of service right?

But according to the docs this would change the start/stop/restart/reload behaviour to be that of sysv scripts .... e.g. Githubissues.

Githubissues is a development platform for aggregating issues.