This URL does a reasonably decent job of describing the problem that systemd (and other such tools) solve:
Problem is, right there in the article, they note that Patric Volkerding views systemd as the attitude of the key developer for the tool towards users and bug reports doesn't seem to be good. That kinda suggests the tool might struggle not because of its technical merits, but because of it handlers.
For my part, I struggled a little to find simple documentation for how I would modify my setup to embrace systemd, and had to learn much of what I know through trial and error... and I'm still not sure I quite grasp the way they handle dependencies (which might be a matter of poor documentation on the part of the OS distributor, or how systemd is a tad too loosy-goosy about defining things such that you can reliably spell out your dependencies).
Gads.. but that's not the best use of English there.
The article notes Volkerding doesn't view the maintainer of systemd as being good towards users and bug reports. And I guess some of these guys feel its philosophy is 'weird,' not quite matching the unix ideal for controlling system processes.
What 'good' means, I don't know. I guess maybe the maintainer isn't responsive, or is overly dismissive, or ... something?
"I'll be here again with another Interesting article you people will love to read."
If I thought the author had good English skills, I'd find that offensive.
Instead, I think he doesn't quite intend what he wrote.
Why put systemd in every distribution? If all distros were alike, we wouldn't need so many of them.
imho, this old system where you manually enumerate initscripts to determine boot order was bad. I hated it in SuSE.
Gentoo for example uses openrc, where you define the the dependencies of an initscript and then it all gets resolved automatically. I like that. I like Gentoo. IIRC, arch used it for a while, too.
I have yet to get used to systemd, since it will be in every major distro in the future. Wether that is a good thing or not. Until now, I maintain mostly Centos6 based systems.
Subject: Look what I just found...
The following command, when run as any user, will crash systemd:
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
After running this command, PID 1 is hung in the
pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system). All of this can be caused by a command that's short enough to fit in a Tweet.
Neato! That worked rather well on Ubuntu 16 server.
Hm, this didn't work on Kali 2.0, though, which also uses systemd. I wonder why that didn't bother it.
Wait a moment... nope... it looks like it did impact it. I can't restart the box properly. It doesn't seem to mind letting me start/stop services, though.
Subject: Re: Systemd uber.
I don't think it can be done. :)
Slackware isn't really a Linux operating system. It's FreeBSD with a Linux kernel.
That having been said, here are the technical reasons I like systemd. I don't really care to get into the religious war on this one -- in fact, people who dislike systemd are *not* necessarily Hitler. I happen to personally like it because:
* It is a single subsystem that replaces dozens of scripts that can interact in weird ways.
* Installing a new service is simple, and done one way: "systemd enable <svcname>" (assuming you dropped the systemd config in the one proper directory where it is expected to be found).
* systemd does not require specially-formatted comments to be placed in init scripts to give the OS a hint as to ordering and dependencies. Instead, its configuration syntax has proper dependency management.
* Services started by systemd do not require extra code to place themselves into the background (daemonize). Therefore, they don't have to drop pidfiles onto the system so that some other script knows how to shut them down later.
* If a service started by systemd crashes, systemd can respawn it automatically.
Back when sysvinit was ubiquitous, I used to start services directly from /etc/inittab for exactly that reason. systemd offers this ability in a more formal declaration syntax: here's the program; run it in the foreground; if it exits, fire it up again.
sysvinit was designed to be configured by greybeards; systemd was designed to be configured by installation scripts. For that reason alone, it makes more sense for mainstream Linux distributions to be using systemd. Slackware isn't really a mainstream Linux distribution though.
Does it even have the normal init scripts? It's been a long time since I looked at Slackware, but the last time I used it, it had /etc/rc.d style scripts.
Like I said ... FreeBSD with a Linux kernel.
Subject: Re: Systemd uber.
So, automation and daemon management. Slackware has rc init scripts (BSD). Never had issues with them, but I mostly use Slackware in cases of set up once and run till it dies cases (one off routers, single board computers with one task, etc...).
I did not mean to invoke a vi vs emacs type holy war. Just wondering what sysadmin type tasks you found to be helped by using systemd, and what I could do differently with my Slackware installs if they ran it, but for what I do with them, it probably won't help much.
Thanks, I think I see the benefits. I run systemd at work on a couple of machines so far, and the learning curve has been a fair amount of digging up documentation with each new line in syslog to see what might need tweaking next. I know it does logging (journalctl), and have started using it as well, but I find it hard not to fall back to reading syslog :-)
Most of the automation I do uses fabric helper scripts to keep my ever growing farm of pets (i.e. not cattle) alive.
Hoping to work in to more automation and cattle servers in the near future though.
The more I look at Docker, the more I'm convinced that it could potentially become *the* universal package distribution format for third-party software.
I think I was looking at it the wrong way, assuming that it served the same purpose as Virtuozzo/OpenVZ or LXC by itself -- basically just a more lightweight version of a virtual machine that uses a shared kernel and cannot easily be live migrated. And maybe that's marginally useful, but probably not enough to justify using it instead of actual virtual machines, except maybe if you needed exceptionally high density on a single host.
But now that I'm playing around with it I see that the real value is that a Docker image carries around all of the dependencies for an application, so there is literally nothing that can go wrong. And the image format being git-like so that it can not only be expressed as deltas from a parent image, but also pool those deltas on a central repository, is sheer genius.
I installed Docker because I was trying to build an application that had a lot of steps to put all of the pieces together. In the past, application providers might have solved this problem by distributing the application as a virtual appliance. But they chose to go with Docker instead. I downloaded the container and ran it. Everything came up on the first try.
I'm definitely going to start distributing my software this way.
Try OnlyOffice... it seems to have dependencies on other docker apps, which seems somehow kind of fucked up.
You might expect binaries to have dependencies, but there's something ... wrong ... about docker dependencies.
Now you've got a ship-shipping ship shipping shipping ships, which can't ship ships without... a tugboat.
Apparently, Mark Shuttleworth finally got around to reading the emails I sent him in 2011.
[ http://tinyurl.com/kkdsapr ]
The awful "Unity" desktop is going away. Starting with Ubuntu 18.04LTS, the Ubuntu desktop will be returning to GNOME. The long international nightmare is finally over. Shuttleworth has finally understood what the rest of us already knew: phones are not tablets are not computers. A single environment that spans them all is a bad idea. (Hey Satya, are you listening? Doze 10 is more capable of acting like a computer than Doze 8, but it doesn't go far enough. Kill your phone project like Ubuntu did.)
This is one thing that Apple got right. Different devices call for different operating environments. I'm not a fan of Mac OS or iOS, but at least each one is designed specifically for the type of device it runs on.
Ubuntu will be refocusing on the things it does well, with (omg!) a focus on the things that are actually bringing in revenue: cloud and IoT, and some desktop as well.
Unity was the reason I abandoned Ubuntu in 2011 and went to stock Debian, even though Ubuntu made the installation and maintenance experience easy.
I'm looking forward to returning to it.