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. <script> start, <script> stop, <script> restart etc

So does that mean there's a gap here in functionality? If I want to handle forking services such as above I can only do so (currently) using a sysv wrapper script? I do have about 4-5 such services that don't create a pid and background themselves only.

[troglobit]

(late follow-up here as well) as it is now, yes. Either a service or a sysv with a start/stop script.

However, well back before 4.x we had support for forking services. It was not working perfectly however, so it was never documented (I hope). There are still traces of it in the code base and I think it would be possible to resurrect it. I'll get back to you on that, but I had one customer remark on it in an open discussion, so it's not unlikely I'll get on it soon.

[troglobit]

Spent the weekend investigating and writing tests for the various combinations supported. Seems it supports a lot more than I initially thought, but it's a mess so I'll continue looking into improving things.

Below is an excerpt from the just updated doc/services.md:

---

Finit can start and monitor the following types of daemons:

• Forks to background, creates a PID file
• Runs in foreground:
  • creates a PID file
  • does not create a PID file -- Finit can create it for you (optional)

Finit can not start and monitor a daemon that:

• Forks to background and does not create a PID file

	Forking	Creates PID File	Finit creates PID File
✔	Yes	Yes	No
✔	No	Yes	No
✔	No	No	Yes, optionally
✘	Yes	No	No

[troglobit]

OK, just to make this crystal clear: Finit cannot support starting and monitoring a daemon that always forks to the background and also does not create a PID file -- there is simply no way to monitor the process. Which PID does it run as? How should Finit know it still runs fine in the background somewhere, thus don't start a new one?

I'm pushing a set of changes to Finit in a few minutes time that adds a type:forking service flag to supplement the pid:!/run/foo.pid syntax otherwise used to monitor forking daemons that do manage their own PID file. The documentation has also been extensively updated. I hope with that, we can close this issue once and for all.