Poettering: systemd for Administrators, Part VIII

Posted Apr 22, 2011 4:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Poettering: systemd for Administrators, Part VIII by wahern
Parent article: Poettering: systemd for Administrators, Part VIII

Why do we still need to experiment with the way daemons are started? It should be just solved once and for all.

Poettering: systemd for Administrators, Part VIII

Posted Apr 23, 2011 22:27 UTC (Sat) by wahern (subscriber, #37304) [Link] (5 responses)

Well, for one thing, as Lennart discussed in his previous article in this series, the daemon manager cannot do all of the privilege separation and environment boxing for the application. So any sufficiently sophisticated daemon will have to do a substantial amount of the work it's already doing, or should be doing.

The work that systemd actually does for daemonizing is about ~30-50 lines of C code. Code which I already have to write because I need my applications to be portable.

Anyhow, I don't understand why people are arguing about changing the methodology of how systemd is daemonizing applications. My idea is merely to make the capabilities that systemd uses to manage services available from a shell-compatible environment, so all of that logic isn't hard coded in C. Inevitably the declarative configuration format systemd uses will rub some people the wrong way, and we'll be back to square zero in terms of dealing with ugly workarounds. Better to let people write workarounds so that they're less ugly, rather than forcing them into a rigid framework which presumes that we've reached the end of the road in terms of how services are managed, locking in current practice.

But this is all partly tongue in cheek. I have every intention of writing a shell like this, but I don't kid myself that it will ever find adoption.

Poettering: systemd for Administrators, Part VIII

Posted Apr 24, 2011 2:00 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (4 responses)

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?

Poettering: systemd for Administrators, Part VIII

Posted Apr 24, 2011 2:44 UTC (Sun) by wahern (subscriber, #37304) [Link] (3 responses)

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] (1 responses)

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 (guest, #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.