4 ms·
It looks like the FreeBSD folks have been doing some work[0][1] in that area. Sadly, it doesn't seem like it's actively being worked on at the moment. FreeBSD
by Mister_Snuggles 9y ago
It looks like the FreeBSD folks have been doing some work[0][1] in that area. Sadly, it doesn't seem like it's actively being worked on at the moment.
FreeBSD's init system works well enough, but there's no question that it could be better.
[0] https://wiki.freebsd.org/launchd https://wiki.freebsd.org/launchd
[1] https://github.com/freebsd/openlaunchd https://github.com/freebsd/openlaunchd
- VLM 9y ago"FreeBSD's init system works well enough, but there's no question that it could be better." Problems or features? I haven't run in to any problems. From a feature perspective I've run into the system policy bug where the name of a package has a minimal relationship with the name of the file read in /etc/rc.conf.d... For example, say you're installing the package named "isc-dhcp43-server", you need to add a file named /etc/rc.conf.d/dhcpd. Why not a file named something "obvious" like /etc/rc.conf.d/isc-dhcp43-server ? Sometimes the names are close enough to be Extremely annoying, like package name "logstash-forwarder" and /etc/rc.conf.d/logstash_forwarder. Obviously thats not a bug in the init system, thats a bug mis-using the init system. Or is that mis_using? Or misusingd-4.2? Its the kind of issue thats super annoying one time when you write the ansible script and then you forget about it until next time you're writing an ansible script to do something else. I have not run into any lack of features problems with freebsd init. Although I admit to having run some end user applications (not system stuff) using supervisord because the end users wanted a pretty web interface for restarting and logs and stuff.
- Mister_Snuggles 9y agoThe only 'problem' I've had with FreeBSD's init was when an NFS mount was unavailable that the machine hung during boot. The mount didn't have anything required for boot on it, but there were services that depended on those mounts being there. In retrospect, I probably should have added "failok,-t=10" to those fstab entries. This one was definitely my fault. An ideal init system would have known (or been taught) that services x, y, and z depend on NFS mounts /a, /b, and /c, so the system could have started mounting those in the background and let other services (like sshd!) start up as required. As to your point about the service names, that bugs me as well.
- JdeBP 9y agoThe TrueOS people have switched from Mewburn rc, as used in FreeBSD, to OpenRC. They could do well to add s6 to that, and I did suggest that to them. They never responded. * http://www.mail-archive.com/supervision@list.skarnet.org/msg01570.html http://www.mail-archive.com/supervision@list.skarnet.org/msg...