LWN: Comments on "Poettering: The Biggest Myths"

Trolling?

cas — Sat, 09 Feb 2013 22:50:17 +0000

it's the new and greatly improved way of spelling Lennart and if he doesn't like it, he's free to fork and go his own way.

Poettering: The Biggest Myths

paulj — Thu, 07 Feb 2013 17:02:46 +0000

Interesting, thanks. :)

Bit of a dance, to have the IPC nexus hand-off this activation. It feels like really these should be part of one thing...

Poettering: The Biggest Myths

Cyberax — Thu, 07 Feb 2013 16:03:22 +0000

> Then why is it that when people talk about doing exactly this, they get jumped by systemd people saying things like "why didn't you submit a bug report to get that capibility added to systemd" or "that's a stupid way to do things, you need to re-write your software to use systemd to do it"
These advices are not mutually exclusive, you know.

If you have a compelling use-case of some exotic activation system for which it makes sense to add core support then doing a bugreport might be a good idea.

And in other cases it might be a good idea to simply rewrite the offending code.

Poettering: The Biggest Myths

dlang — Thu, 07 Feb 2013 15:59:17 +0000

> Don't use socket-based activation and do your dependencies manually, just as in the SysV world. Simple.

Then why is it that when people talk about doing exactly this, they get jumped by systemd people saying things like "why didn't you submit a bug report to get that capibility added to systemd" or "that's a stupid way to do things, you need to re-write your software to use systemd to do it"

This subthread started by the simple statement that socket-based activation was not always appropriate, with the acknowledgement that systemd could support this.

Poettering: The Biggest Myths

khim — Thu, 07 Feb 2013 12:41:57 +0000

So, go on, how do you expose that dependency in a way systemd can handle it. Tell me.

Well, as you've suggested: DBus activation looks like a natural fit for such a use case - and since systemd handles it just fine... I don't see what's your problem.

I'm just a tad sceptical of the wonder claims being made for socket activation based dependency resolution.

Socket activation covers 90% of usecases, but there are other ways to activate service. And the important thing of systemd is that they all can be used simultaneously. You can start some daemon at specific time (using time-based activation) and when your a leaving specific area (D-Bus based activation) and when some other service needs this particular daemon (socket-based activation). They don't conflict and handled correctly in all cases.

Socket activation is there to track dependencies between services on your own system: it's the simplest one to use and most robust one. But there are other to handle "smoke signals", too.

Poettering: The Biggest Myths

khim — Thu, 07 Feb 2013 12:33:05 +0000

There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC.

If it used DBus IPC then it can be easily be used with systemd thus error report will be entirely unnecessary. I've said "convert it to signals systemd understands" and not "convert it to socket activation" exactly for this reason: because systemd handles many different activation requests and makes sure they don't conflict. Socket activation is just one of them (even if one of the most important ones).

Poettering: The Biggest Myths

Cyberax — Thu, 07 Feb 2013 12:19:39 +0000

Don't use socket-based activation and do your dependencies manually, just as in the SysV world. Simple.

Additionally, designer of such a crazy interface should be shot immediately to stop propagating bogosity.

Poettering: The Biggest Myths

cortana — Thu, 07 Feb 2013 08:59:48 +0000

Perhaps you could create target units for each location of interest; other units could then be wanted by/conflict with each target in order to be started/stopped when the location is changed. You would need a glue daemon to look at the GPS data and decide when to start/stop the location targets.

Poettering: The Biggest Myths

paulj — Thu, 07 Feb 2013 08:39:00 +0000

There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC. DBus-daemon also can do "socket activation", and did before systemd existed I think.

Poettering: The Biggest Myths

paulj — Thu, 07 Feb 2013 08:35:22 +0000

So, go on, how do you expose that dependency in a way systemd can handle it. Tell me.

(FWIW, I have no opinion generally on systemd - I don't know enough about it. I'm just a tad sceptical of the wonder claims being made for socket activation based dependency resolution).

Poettering: The Biggest Myths

anselm — Thu, 07 Feb 2013 08:25:35 +0000

The GPS daemon provides the current location on a socket. It is probably unreasonable to expect systemd to be able to deal with that sort of information directly (systemd detractors would immediately jump on features such as these and call them out as »bloat«, with some justification).

Hence, a reasonable way of handling this would be to write a (not very complicated) subsidiary daemon that listened to the GPS daemon's output and triggered various systemd actions based on them. This might be a good idea in any case in order to provide »smoothing« of the location data or additional rules (»tell me about bars in the vicinity but only during happy hour«). This daemon itself would of course be managed by systemd.

This approach should also please the Unix traditionalists who insist that programs should »do one job and do it well«.

Poettering: The Biggest Myths

rahulsundaram — Thu, 07 Feb 2013 08:00:17 +0000

If systemd cannot handle something, is there a bug report? If not, why not?

Poettering: The Biggest Myths

dlang — Thu, 07 Feb 2013 05:50:06 +0000

the GPS daemon does have a socket that systemd understands, what are you suggesting? making a different socket for every possible location so that systemd can set dependencies on if that socket responds???

Just because systemd doesn't handle something doesn't mean that the something is worthless or stupid.

Poettering: The Biggest Myths

khim — Thu, 07 Feb 2013 05:38:33 +0000

Hardly smoke signals.

It is a smoke signal - from GPS stateliness. It can easily be converted to something systemd understands if you'll create a specialized daemon (in a "true UNIX fashion" people like to preach here so much) which will convert it to signals systemd understands.

And you need such daemon anyway because you need to decide how often you poll, if you use just GPS or if you want to use WiFi, too, etc. It's not as if GPS satellites can pull some trigger on your PC or smartphone which means you'll need some complex logic anyway.

Poettering: The Biggest Myths

paulj — Thu, 07 Feb 2013 04:34:43 +0000

How would you add a dependency on, say, a location? Assume there is some daemon running on the system that can make the current location available over a socket (e.g. GPS co-ordinates, or a more abstract specification). The dependency is not just on the socket, but also on the /content/ of the information sent over that socket.

Hardly smoke signals.

Poettering: The Biggest Myths

mathstuf — Wed, 06 Feb 2013 19:00:38 +0000

> …with PulseAudio (which, I'll note, still doesn't work properly with Wine on 64-bit systems, at least not on Debian, and still provides no benefits I actually care about).

It Works For Me™ on Fedora. Rawhide no less (in December; not sure about this month yet). As for features, I keep an instance of MPlayer streaming some internet radio at work. It's nice to be able to mute it and still play some video with sound and then go back and unmute the stream seamlessly.

Poettering: The Biggest Myths

Cyberax — Wed, 06 Feb 2013 16:52:37 +0000

If you have some very exotic services that use smoke signals to communicate - go on and add explicit dependencies.

Poettering: The Biggest Myths

nye — Wed, 06 Feb 2013 12:29:43 +0000

To begin with, personally I'm actually not one of those people who doesn't have those problems. I do on occasion want to be able to do things that systemd makes easier, and am in principle very much in favour of systemd, though in practice I'm not actually willing to try it for myself yet until it's had at least another couple of years to mature - let's say jessie (Debian 8.0).

However, I have a great sympathy for those who are in that position, because that's where I was (and actually still am) with PulseAudio (which, I'll note, still doesn't work properly with Wine on 64-bit systems, at least not on Debian, and still provides no benefits I actually care about).

This is roughly how the exchange sounds from that perspective:

Person A: Try this new snibulator; it's great!
Person B: I'm happy with my old snibulator, thanks.
A: But this one allows you to snibulate even when you're under water!
B: Huh, that sounds cool, but I've never needed to do that.
A: Well you're just too stupid to realise that you need this after all.
B: Please stop telling me what to do.
A: Stop being so hostile! You're clearly too lazy to spend the time to work out that you really need waterproof snibulation. If I had any employees like you, I'd fire them on the spot! I'm so important!

The last line is the one that really grates on me, because it's so arrogant and so aggressively obnoxious. And I haven't hardly even had to exaggerate in my paraphrasing; many of the responses really are that hyperbolic.

Poettering: The Biggest Myths

HelloWorld — Wed, 06 Feb 2013 12:21:52 +0000

> The one downfall to this is that not all dependencies are socket-based.
Systemd offers a lot more than socket-based activation (which btw even supports inetd compatibility). There's also dbus-, device-, timer- and path-based activation and autofs support (which is arguably a service activation scheme as it can be used with FUSE file systems).

Poettering: The Biggest Myths

smurf — Wed, 06 Feb 2013 12:15:26 +0000

You misunderstand.

What I mean is that if Apache needs Mysql, you no longer need to entomb that dependency in your startup scripts.

Poettering: The Biggest Myths

nye — Wed, 06 Feb 2013 12:08:10 +0000

>Don't create straw men out of my arguments.

I didn't. That's why I said "I'm sure you're not" before paraphrasing the argument that the other guy made, specifically to point out that what you're arguing for is *not* what I'm arguing against.

I'm trying to say that you can support the idea that people might want to educate themselves without jumping right to "and anyone who doesn't always want to do that is incompetent".

Poettering: The Biggest Myths

HelloWorld — Wed, 06 Feb 2013 12:05:15 +0000

> Not leaning in on the pro/contra discussion, but this is an exaggeration by far.
No, it's not. udev does the interface naming stuff and systemd has nothing at all to do with it.

Poettering: The Biggest Myths

anselm — Wed, 06 Feb 2013 09:18:09 +0000

So? Systemd can deal with that, too – at least as well as System V init does. For example, systemd lets you express explicit forward and backward dependencies between services and will automatically construct a starting order based on that. With System V init, you either get to work out any dependencies yourself to set the magic numbers correctly by hand, or you use something like SUSE's insserv based on LSB metadata in the init scripts, where reverse dependencies are not an official feature.

Poettering: The Biggest Myths

paulj — Wed, 06 Feb 2013 08:14:15 +0000

The one downfall to this is that not all dependencies are socket-based. Some dependencies are more complex, and need a more abstract protocol than "open a socket" to express.

Poettering: The Biggest Myths

dlang — Wed, 06 Feb 2013 05:53:19 +0000

nobody is trying to force you to stop using the tools you like.

Poettering: The Biggest Myths

vonbrand — Wed, 06 Feb 2013 05:45:14 +0000

But as the knots SysVinit would tie the system into (by willy-nilly starting stuff "in order" when some precondition was delayed for whatever reason, something didn't start because of a mistake and the whole line of dominoes came down leaving no clue) are next to impossible with systemd, this point is moot...

Poettering: The Biggest Myths

spaetz — Wed, 06 Feb 2013 05:35:46 +0000

> This is not a systemd issue in any way, shape, or form. It is a udev issue. Systemd and udev share maintainers but this is as far as it goes.

Not leaning in on the pro/contra discussion, but this is an exaggeration by far. The announcement (http://lwn.net/Articles/490413/) makes it clear that they "merge the udev sources into the systemd source tree."

To me that indicates strongly that systemd and udev are more than two independent tarballs that can be version mix-and-matched and just happen to have the same maintainers.

Poettering: The Biggest Myths

vonbrand — Wed, 06 Feb 2013 03:35:40 +0000

My "server" machine running Fedora (18 now) is working fine with systemd and NetworkManager, thank you very much. I'd hate to need to go back fighting stupid, unreadable shell scripts.

evolution

vonbrand — Wed, 06 Feb 2013 03:17:31 +0000

Sorry, but my extensive experience with assorted shell scripts handling system-y stuff is that they are about as easy to debug as your running kernel, irrespective of tools available (and when things really go south, the requisites for any tools higher up than a well-placed echo just aren't available at all).

Poettering: The Biggest Myths

HelloWorld — Wed, 06 Feb 2013 01:51:23 +0000

So you're saying that having multiple NICs is a rare thing when you're managing large numbers of systems in data centers?

And if that weren't enough, you readily admit that you're too incompetent to figure out that the mapping from MAC addresses to interface names is stored in /etc/udev/rules.d/70-persistent-net.rules and can be modified there?

You're a crazy person. Get help. Or don't, I don't care.

Poettering: The Biggest Myths

HelloWorld — Wed, 06 Feb 2013 01:37:53 +0000

> I fear that this will lead to distros enabling each and every service under the sun
You mean like Debian has been doing for ages?

Poettering: The Biggest Myths

raven667 — Tue, 05 Feb 2013 22:43:08 +0000

That's not a problem that can happen with systemd though, since it keeps the services on a tight leash and knows what state (running or not) the service is in. Since that part must be self-contained in PID 1 it would seem there is little room for race conditions or errors to exist.

If we had the time we could skim through http://cgit.freedesktop.org/systemd/systemd/tree/src/core/ and see if we can identify where it keeps that state and how it is updated to see if there are any bugs.

Poettering: The Biggest Myths

Cyberax — Tue, 05 Feb 2013 22:24:57 +0000

I thought it's obvious - socket-based activation enforces the ordering of services and explicit startup might be required because service might need to do some background stuff.

Also, it might decrease the response time time for the first client.

SystemD nicely allows to do both.

Poettering: The Biggest Myths

dlang — Tue, 05 Feb 2013 22:16:32 +0000

If nothing can go wrong, then why would you want to have a service that you configure to start one way also configured for socket based startup?

One of the things you learn after several years of running large numbers of production systems is to not trust claims that a process will always work, whatever that process is.

Failures are generally not that common, but they do happen.

Poettering: The Biggest Myths

Cyberax — Tue, 05 Feb 2013 22:12:29 +0000

Uhm, systemd gurantees that a service will be started only once.

On the other hands, I did have problems when ejabberd started in parallel with the PostgreSQL database - there was no dependency in LSB headers because I was using an optional psql auth module.

This worked just fine until the day it suddenly stopped working because the ordering of services has changed and Postgres moved a little bit later into the boot process.

Poettering: The Biggest Myths

dlang — Tue, 05 Feb 2013 21:55:10 +0000

having a service started multiple times is not always a safe thing to do. In theory the service properly checks and makes sure there's only one copy of it running, in practice you just don't do that, or it _will_ bite you down the road.

Poettering: The Biggest Myths

khim — Tue, 05 Feb 2013 19:58:29 +0000

I was just saying that there are times when socket activation is not the best thing to be doing.

It's never a good idea to disable a socket activation. Socket activation is your safety net. It guarantees that services will be started when they are needed. Everything else is optional.

This is yet another thing which systemd is doing correctly and which was traditionally managed in an an-hoc-kinda-works-in-you-quint-just-right way.

Poettering: The Biggest Myths

dlang — Tue, 05 Feb 2013 19:24:00 +0000

sigh, that 's why I added the bit about how I wasn't saying that systemd couldn't do this.

I wasn't missing the point, I wasn't saying that systemd can't do this.

I was just saying that there are times when socket activation is not the best thing to be doing.

systemd/upstart adoption

khim — Tue, 05 Feb 2013 19:00:59 +0000

Fast boot is one of the important goals of ChromeOS. Systemd was not investigated because it will needs fine-tuning to work faster then the existing optimized boot and nobody have done the required work.

Poettering: The Biggest Myths

khim — Tue, 05 Feb 2013 18:58:38 +0000

True. On a server, you probably don't want to use socket activation.

Yes, you absolutely do want to use socket activation on server. It guarantees that service will be brought up if needed. You may want to use other forms of activation, too - but these are optional, if your forgot to explicitly start some service which is needed by other service - socket activation is there to bail you out.

Even if you bring up all the services on server startup you still want socket activation. Without socket activation you need to order them somehow and need to think about dependencies between them, etc but with socket activation you just start them all - and that's it: socket activation will guarantee that nothing will be lost.