Is this proof that systemd is completely broken?

Sam Varshavchik mrsam at courier-mta.com
Sat Jul 12 17:05:59 UTC 2014


Kevin Fenzi writes:

> So, I would encourage you to ask the systemd list:
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> for a probably more detailed answer than you might get here.

There's a very specific reason why I don't wish to do that.

> Or... file a bug if you think you have found one.
> https://bugzilla.redhat.com/enter_bug.cgi? 
> product=Fedora&version=20&component=systemd
>
> My theory of what you are seeing revolves around the fact that
> the /etc/init.d/network script is NOT a systemd unit file, it's a old
> sysvinit script which systemd runs under compatibility.

Given the criticality of /etc/rc.d/init.d/network, and the fact that a  
bucketload of servers are NOT going to run properly unless that script does  
its job, I would think that a little bit more consideration should've been  
given to make certain that it gets properly integrated into systemd; rather  
than waving it off as some legacy script.

> From http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget
>
> "network-online.target is a target that actively waits until the nework
> is "up", where the definition of "up" is defined by the network
> management software"
>
> and I think /etc/init.d/network defines "up" in a way that doesn't mean
> that the interfaces have ip's and are passing packets. Just a guess.

I get that. I read that ten times already.

But it's a moot point. Whatever "network up" means or does not mean is  
irrelevant. One service is declared to run "Before" a target. A second  
service is declared to run "After" a target. According to my timestamps,  
systemd is starting the second service before the first one is finished.

What the target does, if anything, I don't think it really matters.

> Alternately you found a nice bug. ;)

Again, out of abundance of caution, I'll postpone claiming another scalp  
until a few more eyes look at what I have, and agree. But, presuming that I  
am right, this isn't exactly a bug. It's a major fail.

At this point, it doesn't look like systemd is really doing much of a  
dependency tracking and resolution. It just compiles a list of stuff to kick  
off, to reach a certain target. Then forks off and runs them all at once. Or  
almost, all at once; I do see a few seconds' of pauses, in the boot output,  
when systemd stops reporting that something has stopped or started, for a  
second or two. But, as a practical matter, everything just gets starte

Well, that's one way to speed up system boot.

P.S. On another server of mine, systemd figures out exactly the right moment  
to fork off innd so that innd starts listening on 127.0.0.1, but not on ::1  
because it hasn't come up yet.

On every boot.

That's awesome.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140712/dcdf6376/attachment.sig>


More information about the users mailing list