Visit Jeremy's Blog.
Go Back > Forums > Linux Forums > Linux - Newbie
User Name
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!


  Search this Thread
Old 11-04-2015, 05:49 AM   #61
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,131
Blog Entries: 2

Rep: Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833Reputation: 4833

Originally Posted by Drakeo View Post
But this article here is from the people that really deal systems and large server farms.
Yeah, looked at that article and stopped reading at
Install a new package that has a .service file and "poof", your entire boot behavior and order can change. Got a cyclic dependency? [BLEEP], you won't even discover this until that unplanned reboot.
Apparently, this person has never heard of testing changes on developer systems before rolling them into production, which lets me question their credibility.
Old 11-04-2015, 07:34 AM   #62
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,655

Rep: Reputation: 1256Reputation: 1256Reputation: 1256Reputation: 1256Reputation: 1256Reputation: 1256Reputation: 1256Reputation: 1256Reputation: 1256
Originally Posted by TobiSGD View Post
Yeah, looked at that article and stopped reading at Apparently, this person has never heard of testing changes on developer systems before rolling them into production, which lets me question their credibility.
It doesn't just happen in testing.

Due to the random scheduling, it can happen at any time - and not happen during testing.

ANYTHING can be a change - extra interrupts can slow a process down ... and expose another dependency failure.

Sometimes it works... Sometimes it doesn't.

That is why people keep sticking restarts of some services into rc.local. It tends to get more reliable. If a service did start, attempting to start it again gets canceled. If it didn't start, then it is more likely to get started.

Of course, when that fails too, people start sticking sleeps into rc.local to try and make it work too.

The very BASIC problem is due to the nature of network analysis.

The more complex the dependency network, the more likely adding a single node to it will cause the network to collapse.

This fact was learned back in the mid 1970s and early 1980s with PERT charting for project management - it doesn't scale well:

The next problem is that the network IS NOT a simple network (just the "before" and "after" would be the base network). There are conditional sub-networks that make it more complex ("wants","requires"...) for yet another network layer... And generates the need for multiple "targets" that do nothing but create sub-nets (it reduces the size of the list of dependencies, but can also makes the network more confusing.

So adding ONE new service could cause a number of previously untested services to also get started...

The next problem is that for "reliability" all services need to be modified to tell systemd when it is "ready". The problem here is that services that are started by other services introduce additional problems: NetworkManager is my favorite bad example. NetworkManager has to tell systemd when the network is ready... but NetworkManager isn't always in control - that is up to DHCP client.... So now the DHCP client has to tell NetworkManager when it is done... so that NetworkManager can tell systemd that the network is ready...

Which works - sort of (it is why there is a "NetworkManager-wait-online" target). Most places have a two or three level network "ready" states. One for administrative access (needed by admins to fix things), another for service networks (must be ready for service access such as remote databases), and a third for public access (needed to be up). The first one MUST be up. The second one CAN be up - but if not, then admins can connect to find/fix things - If both are up, then all services SHOULD be up and admins can do things to verify proper operation... or find out why the public access network isn't working. The third one must be up for general use... Can NetworkManager handle this? nope. All networks are either up or down. The only workaround is to take some of the networks OUT of NetworkManagers control... or dump NetworkManager entirely.

And this doesn't address the problems of a cluster when dependencies are external to the system... (though DHCP is a small example of this, but what about remote database access?).

BTW, There is no race condition for socket connections. If it exists, it is a bug in the service in the first place. Service startup is supposed to:

1) process configuration files, report any errors,
2) initialize the network (up through the listen system call) and report any errors, THEN
3) become a daemon.

At the point the "listen" system call is completed, the service is ready to accept connections. After the fork, the child starts accepting incoming connections (which are in the queue), the parent can then close the socket (the child has it) and exit normally (the event that signals it is ready). Systemd breaks this as there is no point where the service can be inherently identified as "ready".... unless it is modified to TELL systemd it is ready... Thus, the need to tell systemd there are "forking" services... which again defeats the purpose of systemd, as these services can't be monitored by systemd.

In this way, systemd takes over more and more of the formerly independent projects.

As you can see, systemd is not my favorite init.
4 members found this post helpful.
Old 11-04-2015, 10:35 AM   #63
Senior Member
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 3,090
Blog Entries: 3

Rep: Reputation: 324Reputation: 324Reputation: 324Reputation: 324
Originally Posted by TobiSGD View Post
Yeah, looked at that article and stopped reading at Apparently, this person has never heard of testing changes on developer systems before rolling them into production, which lets me question their credibility.
Keep it simple. I wish everyone thought the way you do. But today many hands in one pot. Like I said it is about trust and stability.
Old 11-04-2015, 10:52 AM   #64
Senior Member
Registered: Feb 2003
Distribution: debian
Posts: 2,520
Blog Entries: 1

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
Originally Posted by TobiSGD View Post
May I ask which distro you are using?
Debian jessie/stable mostly.

Mostly installed like this:

Before systemd I could exit the chroot and umount the mount point and shared points /chroot/proc /chroot/dev. Now I have to stop udev and dbus on the host system to umount /proc and /dev in the /chroot. Although I don't even think I could get that much done now, I just have to reboot to cleanup. I would often do the debootstrap install method to setup a USB boot medium for another machine with a minimal install and never have to reboot the machine I did that linux install in linux on.

It's probably because the package manager installs stuff and tries to restart services (in the chroot). And I guess to some degree succeeds in restarting them in the chroot, forever binding the host system to the chroot (until reboot). Or less graceful endeavors to force things.

(after the debootstrap setup of /mnt/debinst/ in this case.)
# mount -t proc proc /mnt/debinst/proc
# mount --rbind /dev /mnt/debinst/dev
# export LANG=C; chroot /mnt/debinst /bin/bash
(chroot)# apt-get install linux-image-amd64
(chroot)# passwd
(chroot)# exit
# umount /mnt/debinst/dev
# umount /mnt/debinst/proc
# umount /mnt/debinst

Last edited by Shadow_7; 11-04-2015 at 10:54 AM.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Why pro-systemd and anti-systemd people will never get along LXer Syndicated Linux News 0 05-16-2015 12:44 AM
LXer: Is systemd as bad as boycott systemd is trying to make it? LXer Syndicated Linux News 0 09-03-2014 06:50 PM
What is so bad with systemd? McZ Linux From Scratch 43 05-10-2014 09:38 AM
systemd responsible for climate change, bad coffee, and athlete's foot mrclisdue Slackware 23 11-15-2013 07:57 PM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 10:02 AM

All times are GMT -5. The time now is 11:04 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration