Should mill offer a feature to write PID files in runBackground tasks?

[swaldman]

Would it be a good idea to add to mill JavaModule something like def runBackgroundPidFile: Option[os.Path] = None, and if overridden, let the various runBackground tasks write the subprocess PID before completion?

I'd be glad to implement this, but I thought I'd see what people thought first.

The motivation would be streamlining use of mill as a launcher for daemon processes. I do this, because I have mill turn templates into generated code and recompile, so I can edit templates and restart without further build or ceremony. It works great! But if I just use ordinary runMain style tasks, the launching mill process stays alive consuming whatever resources it consumes, waiting for the long running daemon to complete. Instead I can use runMainBackground, and treat it as an old-school forking daemon. But apparently (according to systemd) old-school forking daemons are supposed to write the PID file of the forked subprocess before they terminate.

A workaround is to have the subprocess itself generate the PID file, and systemd seems able to deal with that, but there's an awkward log message when the parent process dies, Can't open PID file /myapp/myapp.pid (yet?) after start: No such file or directory Another workaround under systemd is just to omit PIDFile=/myapp/myapp.pid item entirely, in which case systemd tries an algorithm to "guess" subprocess PIDs, which works just fine for mill's runBackground tasks.

So it's not necessary. The workarounds work. Still, I know my setup is not conforming to the protocol systemd considers correct, I'm relying upon it being tolerant in what it accepts while I fail to be strict in what I produce. Letting mill itself drop subprocess PID files would fix this.

[lihaoyi]

I think it sounds reasonable

[swaldman]

Working with this some more, using runBackground commands for forking daemons led to spooky-action-at-a-distance fragilities, since these commands run under BackgroundWrapper, which terminates processes when upstream source is touched.

For a while it was a bit of a mystery, daemon processes expected to run indefinitely would not, systemd would note that they "deactivated successfully", terminating with exit code 0.

It was easy and clean to just extend JavaModule with a new DaemonModule, which implements runDaemon and runMainDaemon commands that omit the sneaky wrapper, and includes the desired method as def runDaemonPidFile: Option[os.Path] = None. When overridden to provide a path, the parent process (cautiously) writes the PID file before terminating, satisfying systemd expectations of a forking daemon.

It's working beautifully now. (I am using it e.g. here.)

If it might be of use to others, it is now mill-daemon.

Thank you always for this wonderful tool!

[lefou]

You might want to GitHub-tag it with mill-plugin and also add it to our third-party plugin list.

[swaldman]

@lefou Done! Thanks!