| |||||||||||||
Poettering: systemd for Administrators, Part VIIIPoettering: systemd for Administrators, Part VIIIPosted Apr 24, 2011 2:00 UTC (Sun) by mpr22 (subscriber, #60784)In reply to: Poettering: systemd for Administrators, Part VIII by wahern Parent article: Poettering: systemd for Administrators, Part VIII When I look at systemd's man pages, I don't see all that much rigidity. Could you cite (with reasoning) some specific aspect of its rigidity that you think is going to cause problems, or are you just doomsaying?
(Log in to post comments)
Poettering: systemd for Administrators, Part VIII Posted Apr 24, 2011 2:44 UTC (Sun) by wahern (subscriber, #37304) [Link]
It's rigid by it's nature because it's not programmable. But off the top of my head I'll give you an example that browsing through the man pages I can't find a solution for:
Say you have an error in your configuration file. The daemon bails with an error message. Where does this error message go? I'm sure everyone in this thread has experienced some frustration when a service which supposedly started--because the service manager returned successfully from the start command--was nowhere to be found. If the error message went to the terminal that started the service you would immediately see the error. But if stderr is being redirected to a service manager, this isn't going to happen. And there's no easy solution to this; maybe the configuration error doesn't happen for a few seconds because some other initialization is occurring (e.g. long'ish DNS lookup or disk access), so how can the service manager reliably know when to redirect errors?
In my daemons all error messages go to stderr, but stderr isn't redirected to a log file--if it's redirected at all--until after initialization of all the sub-components. So, for example, sockets are bound *before* forking (yes, please no comments that systemd can bind sockets early too, this is just a familiar example) and all other initializations are ordered to make sure "fail early" happens and detaching from the terminal occurs as late as possible to minimize annoying surprises.
Does systemd address this scenario? In my fantasy world this would be addressed somehow, but I don't have the perfect answer to how. Sure there are solutions you can dream up, but will it be the right one? With systemd there can be no experimentation with messaging the service manager to see where the best solution lies. Whoever gets their patch upstream first wins the day. This is the sort of rigidity I'm speaking of. The very fact that you have a non-programmable framework is the barrier, not how well or comprehensive it's implemented.
If you've ever worked at a company that builds embedded appliances then you would agree that there is no one-size-fits-all approach to service management. But for any service to be portable across such Linux environments--disregarding other Unix systems--then systemd doesn't really solve much of anything for developers, because there will have to be the usual boilerplate code and/or shims in place, regardless.
Poettering: systemd for Administrators, Part VIII Posted Apr 24, 2011 23:43 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
Services should log there error causes to syslog. They can do that either via the syslog() libc call or by simply writing to STDOUT/STDERR, and using StandardOuput=syslog in the service file.
In F16 we plan to set StandardOutput=syslog by default. We are currently holding this back in order to support generic syslogs with SysV init scripts where such a default would result in a logging loop.
Poettering: systemd for Administrators, Part VIII Posted Apr 29, 2011 4:08 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
and what do yo do before syslog is running?
or more to the point, where to the logs go if it's the syslog daemon that's having the problem?
Poettering: systemd for Administrators, Part VIII Posted Apr 25, 2011 9:44 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, I _am_ working (actually, owning) a small company that does embedded development.
And I'm looking at systemd to replace our current SysV-based infrastructure. Systemd is faster, smaller and more robust.
We've tried upstart earlier but while it has some nice features, it just isn't worth the cost.
|
|||||||||||||