Solved systemd alternative on FreeBSD

[jbo@]

Adding some information to an old question as apparently people find their ways to this thread at present times:

And have the web applications automatically restart on crashes.

SirDice already covered this. I'd just like to add a bit more detail/perspective: You can easily daemonize an executable via daemon(8). I left some notes regarding this on my blog a while ago: https://blog.insane.engineer/post/freebsd_daemonize/
The rc.d script shown there is what I wrote to daemonize a Golang application. It was a 3rd-party tool which was prone to crashing randomly but I was forced to use it. When it crashed, the OS automatically re-launched it.

 

[Alain De Vos]

gentoo uses openrc. But isn't it in essence more or like freebsd rc system ?
There is also a file /etc/rc.subr coming from netbsd but i do not understand it's contents...

 

[Phishfry]

doesn't ps give answers?

Yes. But what if service <service name> status actually gave service status like ps does.
That would be quite useful.
I do like some of the simple suggestions I am seeing here on the topic.

My point was 'status' really seems stark with only the PID shown.
As mentioned above it only works on some services. That seems incomplete for our base services.

 

[ct85711]

The interesting/funny thing is more of the assumption that a PID reported for some service actually means anything at all (this is also the case on openrc and systemd on linux). Just because there is a PID reported for a service, has little meaning that does not tell you what the status is. I have encountered numerous programs that do not clean up the PID file, others that service reports it as crashed but is working perfectly fine, even some that say it isn't running but yet it is running (based off of ps/top and logs generated).

There are also the cases, of what the actual situation of the service which would never be reported by service/systemd. A prime example would be a deadlocked/hung service or even one stuck in a busy state. Neither of them would never be reported as crashed or anything; as by the nature, they look to have crashed but are working properly to the computer.

 

[sko]

There are also the cases, of what the actual situation of the service which would never be reported by service/systemd. A prime example would be a deadlocked/hung service or even one stuck in a busy state. Neither of them would never be reported as crashed or anything; as by the nature, they look to have crashed but are working properly to the computer.

that's why you should always monitor important services from another system.
But that is far more high-level than actually needed for basic troubleshooting. Usually you just want to know if all enabled services are running or if some have failed e.g. due to botched config files. The output of svcs on Illumos/Solaris gives you exactly this information and can give you far more information - but SMF is a completely different beast than our trusty, simple rc.
I get along with SMF, but I wouldn't want a behemoth like that on BSD.

I haven't looked at what rcctl ls failed does on OpenBSD - but even if it just checks for a PID for any enabled service this would be completely sufficient for basic troubleshooting.
Anything else is the job of a proper monitoring system and/or the sysadmin. No need to overengineer everything - keep it simple and avoid having to deal with the never ending hunt for edge cases for everything that could run as a service...