| |||||||||||||
Crowding out OpenBSDCrowding out OpenBSDPosted Nov 15, 2012 1:13 UTC (Thu) by wahern (subscriber, #37304)In reply to: Crowding out OpenBSD by bronson Parent article: Crowding out OpenBSD
We've already had respawning with inetd. The fact that few used this almost universal facility should make one wonder whether it's really a feature developers don't enjoy reimplementing themselves.
That might seem illogical at first, until you consider how a developer's environment is setup. When developing a daemon you absolutely _hate_ centralized process management, because it tends to get in the way of debugging, among other things. Instead, you basically have to implement some sort of simple process management yourself, regardless of how your production environment will look. (If you're a web developer for a large website, imagine having to develop, debug, test using your process to upload and install in production... it'd be a nightmare.)
I usually start my development on OS X, and then port to Linux and the BSDs. Not once have I considered using launchd.
(Log in to post comments)
Crowding out OpenBSD Posted Nov 15, 2012 1:45 UTC (Thu) by josh (subscriber, #17465) [Link]
inetd tied process spawning to sockets. systemd doesn't; you can independently choose whether to use socket activation and whether to use respawning.
Crowding out OpenBSD Posted Nov 15, 2012 1:56 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
inetd tied process spawning to sockets, but there was also inittab for daemons that you wanted to have restarted if they exited or crashed.
Crowding out OpenBSD Posted Nov 15, 2012 3:33 UTC (Thu) by josh (subscriber, #17465) [Link]
True, and it seems quite unfortunate to me that distributions stopped using inittab for its intended purpose and started using it to launch scripts instead.
Crowding out OpenBSD Posted Nov 15, 2012 14:47 UTC (Thu) by khim (subscriber, #9252) [Link] inittab worked as intended couple of decades ago. But when daemons started spawning processes left-and-right and started depend on other processes it become useless. You can view systemd group-using core as "inittab done right".
Crowding out OpenBSD Posted Nov 15, 2012 15:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Exactly, I see systemd as a return to unix roots, features that init would have had it continued innovating instead of stagnating and standardizing, not some weird departure against the overall style of the system.
Crowding out OpenBSD Posted Nov 15, 2012 22:04 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
parts of systemd could be called implementing init properly, but other parts are far more questionable.
why does device enumeration belong as part of init (udev)?
why does logging belong as part of init (the journal)?
Crowding out OpenBSD Posted Nov 15, 2012 22:44 UTC (Thu) by raven667 (subscriber, #5198) [Link]
>why does device enumeration belong as part of init (udev)?
It isn't part of PID 1 but hardware initialization is a dependency for services being started. The service manager ends up needing to know about hardware state for dependency purposes and therefore shares a lot of infrastructure with udev which is why they are distributed together now.
> why does logging belong as part of init (the journal)?
This is also not part of PID 1 . Whether system logging should be tackled as part of the systemd project is debatable. It is still an optional component though and might solve some real problems.
Crowding out OpenBSD Posted Nov 15, 2012 22:50 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I thought of one more thing as well, the init system is in a prime position for logging both because it is connected to the stdout/stderr of processes that it spawn, where they might dump data, and it has its own needs for logging but by definition is started before any userspace logging service could be running. So there are at least a couple of cases that a PID 1 and related tools should identify and solve.
|
|||||||||||||