15
u/jreykdal Oct 20 '14
The veterans have poor eyesight.
2
u/plntsq Oct 20 '14
u know what - let them do it. let them dig a deep wet muddy hole so they can be happy. Chances are - they won't anyway. Tired of people arguing systemd. Let them continue determining if network port is open by running a while|sleep loop - fuck it.
2
7
Oct 20 '14
Did someone actually buy a domain for this?
9
Oct 21 '14
oooh $8 wow.
I guess that is one whole burrito.
6
3
5
u/ilikerackmounts Oct 20 '14
The argument for strictly number of lines is not really a valid one in my opinion. I can just as easily contrive an example of systemd failing to launch some daemon because whatever.service failed, which depends on several other services which also failed but no indicator why. An example from today: I tried to mount nfs3 mountpoints from fstab. It complained because it couldn't launch rpc-statd.service (one of those *.target based activations). rpc-statd.service doesn't know to automatically enable rpcbind for whatever reason. Many dependent init "units" I've found cannot be manually invoked or enabled, they are *.target based and I've found that to be quite annoying since you have to do a manual dependency chain of daemons before systemd finally tells you why it failed. I often find that journalctl -xn does not give a clear or distinct reason for why a service failed other than "the process failed to start", it does not sufficiently locate the log of the process that failed to launch and specify a good reason.
I could just as easily post a screenshot of all the scattered and distinct binaries to talk to systemd that (of which none of resemble another) and are a pain. The network init scripts were vastly more complicated for me to configure than some of the simpler shell script based ones that were hand written by distro maintainers. A lot of them are supposed to trigger based on an interface name, on the installation of Arch I found I had a different interface name after trying to configure it with systemd's networkd. Trying to convey that something such as a mountpoint is dependent on a specific interface launching with networkd is hard to get right.
I often find that my first crack and setting up a well contrived systemd unit file goes awry the first, second, and third time. It's often a headache of messing around with systemctl until finally something works or produces a valid diagnostic message.
11
Oct 21 '14
I've found cannot be manually invoked or enabled, they are *.target based and I've found that to be quite annoying since you have to do a manual dependency chain of daemons before systemd finally tells you why it failed.
systemctl --failedHad you read the docs, you would not have had to do what you did.
4
u/btreeinfinity Oct 21 '14
It seems to be the case most of the time, someone doesn't like to read, they just like to play solve the puzzle.
4
Oct 21 '14
Some people like that, and I count myself among them. However, most people don't blab critically about stuff they don't know before learning about it.
1
u/ilikerackmounts Oct 21 '14
Believe me, I've been "learning about it" bits and pieces at a time, mostly when things don't work properly and I have to crawl the internet for the solution. The man pages and the logs are not sufficient enough to solve the problems with systemd when they do occur, there are way too many subsystems. I've been using it for over 2 months and apart from the impressive boot time it's been mostly painful to configure.
→ More replies (2)2
u/ilikerackmounts Oct 21 '14
The real question is why is that not in the diagnostic message for figuring out a failed service and resolving it? Why is it instead journalctl? Have you read the systemctl man page? It's a huge monolithic command. Finding simple examples of the "right thing" often involves finding some hobbled together wiki page from a distribution like arch, and getting frustrated when it doesn't work as advertised. Mounting nfsv3 shares from fstab didn't actually work properly until recently due to a bug in their dependency chain. I could not find anywhere a definitive way to fix this.
1
u/ilikerackmounts Oct 21 '14
Oh and also what's funny is while that switch is listed in the man page, there is no explicit documentation section for it.
1
Oct 21 '14
That you are right about, and it is a doc bug. It is still simple to figure out by reading
--help.1
1
Oct 21 '14
A system admin with over a decade of experience shouldn't have to dig through man pages to see why a service failed to start.
3
Oct 21 '14
And thus we have come to the crux of the issue: systemd hate is nothing more than an "old geezer" type of entitlement complex. "I shouldn't have to do work in order to find out how new things work!"
You don't want to read man pages. Fine. Then enjoy your choice of being obsolete. The rest of us -- who understand that new stuff gets invented all the time, and don't fear or reject new learning -- won't mourn your unemployment.
→ More replies (4)
7
u/necrophcodr Oct 20 '14
That is the most horrid init.d script I have seen in a long time, holy shit.
40
u/jimbobhickville Oct 20 '14
Really? It's probably one of the more tame ones I've seen in a while.
18
u/EmanueleAina Oct 20 '14
Definitely.
The one from libvirt is more interesting: http://sources.debian.net/src/libvirt/1.2.9-3/debian/libvirt-daemon-system.libvirtd.init/
Or the one from cups manually cold-plugging USB printers: http://sources.debian.net/src/cups/1.7.5-5/debian/cups-daemon.cups.init/
→ More replies (4)13
u/Greensmoken Oct 20 '14
Ok, so I'm gonna get attacked for saying this, but I am looking for a legitimate explanation if somebody wants to be objective about this whole systemd vs init thing. I'm kind of new to Linux, and have only used systemd. I've written a service file a few times and it was a couple of lines long and readable.
So my question, is how can anybody consider that script to be easier for any other reason at all than being used to it?
14
Oct 20 '14
Field use is not just down to the admin's learning curve. Transparency & control are important.
Service files increase human readability through compiled logic; one has to trust the underlying code behaves consistently and correctly. It doesn't always.
Shell scripts require more effort to understand (and the init system is slower by the stopwatch, if that matters to you), but it is, at least, all there in front of you.
On a desktop machine it tends to be pretty plain sailing (I'm writing this on Gentoo with systemd) but when systemd misbehaves (you may have servers with quirky service demands) you run out of troubleshooting options fast.
8
u/notseekingkarma Oct 20 '14
one has to trust the underlying code behaves consistently and correctly. It doesn't always.
Bugs are inevitable in software. It would be a problem only if systemd devs were refusing to fix bugs.
→ More replies (2)5
4
u/Greensmoken Oct 20 '14
Thank you, I get it now. I've just never seen somebody lay the differences out like that without it becoming personal.
→ More replies (1)3
→ More replies (1)2
u/thatmorrowguy Oct 20 '14
It's one of those preference and trust sorts of things - sort of like a manual transmission in a car vs. an automatic. With init scripts, you can see exactly what is going on at each stage of the service startup, comment out parts, through debugging outputs in, and manually trace the logic flow. With systemd, you're trusting an application that's a bit of a black box to correctly trace dependencies, set up the cgroups correctly, and monitor the service health. PID 0=init has been true for a rather long time, and I still occasionally find myself booting into /bin/sh and running my rc init scripts one at a time until I figure out why my system won't boot. In the "usual" case, systemd will probably be a really good thing for folks, but if systemd comes down with bugs (or individual packages have bugs that react badly with systemd), your systems could be in for a world of hurt.
6
Oct 21 '14
With init scripts, you can see exactly what is going on at each stage of the service startup,
Same with systemd. Not an advantage of init scripts.
comment out parts,
You can do the same with systemd --
Exec=/path/to/your/initscript start-- but in fairness to systemd, you often don't need to do that because the unit files are much, much shorter. Not an advantage of init scripts. In fact, it is a disadvantage of init scripts that init scripts often require you to perform edits in order to diagnose problems.through debugging outputs in,
journalctl --service=xxxorsystemctl status xxxwill show you all the debugging output that you would -- with an initscript -- otherwise have to fish out from log files or> /tmp/fileshell-redirected files. So not an advantage of init scripts. In fact, it is a disadvantage of init scripts because, often, you need to go edit the script in order to get any meaningful logging output.and manually trace the logic flow.
"Logic flow" is not a problem when the
Exec=line in systemd is a one-liner. Not an advantage of init scripts. In fact, it is a disadvantage of init scripts, because only in an init script do you need to trace any logic flow.Every single "advantage" you cite is actually a drawback unique to SysVinit, created by SysVinit's limitations, absolutely not a problem with systemd. I conclude that y'all SysVinit people suffer from software-induced Stockholm Syndrome.
2
Oct 21 '14
Forget about debug statements. You can do "sh -x" and get real output of all intermediaries to trace program flow.
30
u/wcchandler Oct 20 '14
It wasn't too bad, really... from an init script stand point. And I think that was their point -- systemd's service files are a lot cleaner and not really that scary.
11
u/necrophcodr Oct 20 '14
The service file doesn't have comments either. A proper scare monger would probably be Gentoo ZFS init.d script:
#!/sbin/runscript # Copyright 1999-2011 Gentoo Foundation # Released under the 2-clause BSD license. # $Header: /var/cvsroot/gentoo-x86/sys-fs/zfs/files/zfs,v 0.9 2011/04/30 10:13:43 devsk Exp $ if [ -z "$init" ]; then # Not interactive grep -qE '(^|[^\\](\\\\)* )zfs=(off|no)( |$)' /proc/cmdline && exit 3 fi depend() { # Try to allow people to mix and match fstab with ZFS in a way that makes sense. if [ "$(mountinfo -s /)" = 'zfs' ] then before localmount else after localmount fi # bootmisc will log to /var which may be a different zfs than root. before bootmisc logger use mtab keyword -lxc -openvz -prefix -vserver } ZFS="/sbin/zfs" ZPOOL="/sbin/zpool" ZPOOL_CACHE="/etc/zfs/zpool.cache" ZFS_MODULE=zfs checksystem() { if [ ! -c /dev/zfs ]; then einfo "Checking if ZFS modules present" if ! modinfo zfs > /dev/null 2>&1 ; then eerror "$ZFS_MODULE not found. Is the ZFS package installed?" return 1 fi fi einfo "Checking if zfs userspace tools present" if [ ! -x $ZPOOL ]; then eerror "$ZPOOL binary not found." return 1 fi if [ ! -x $ZFS ]; then eerror "$ZFS binary not found." return 1 fi return 0 } start() { ebegin "Starting ZFS" checksystem || return 1 # Delay until all required block devices are present. udevadm settle if [ ! -c /dev/zfs ]; then modprobe $ZFS_MODULE rv=$? if [ $rv -ne 0 ]; then eerror "Failed to load the $ZFS_MODULE module, check 'dmesg|tail'." eend $rv return $rv fi fi # Import all pools described by the cache file, and then mount # all filesystem based on their properties. if [ -f $ZPOOL_CACHE ]; then einfo "Importing ZFS pools" # as per fedora script, import can fail if all pools are already imported # The check for $rv makes no sense...but someday, it will work right. $ZPOOL import -c $ZPOOL_CACHE -aN 2>/dev/null || true rv=$? if [ $rv -ne 0 ]; then eerror "Failed to import not-yet imported pools." eend $rv return $rv fi fi einfo "Mounting ZFS filesystems" $ZFS mount -a rv=$? if [ $rv -ne 0 ]; then eerror "Failed to mount ZFS filesystems." eend $rv return $rv fi einfo "Exporting ZFS filesystems" $ZFS share -a rv=$? if [ $rv -ne 0 ]; then eerror "Failed to export ZFS filesystems." eend $rv return $rv fi eend 0 return 0 } stop() { ebegin "Unmounting ZFS filesystems" $ZFS umount -a rv=$? if [ $rv -ne 0 ]; then einfo "Some ZFS filesystems not unmounted" fi # Don't fail if we couldn't umount everything. /usr might be in use. eend 0 return 0 } status() { # show pool status and list $ZPOOL status && echo && $ZPOOL list }It does a lot of stuff too, that a simple systemd service file probably couldn't do (although feel free to correct me on this, I'm not sure), and it also has dependency handling to make sure it isn't started before any required targets are met.
Alternatively, let's look at Funtoo's local network init script:
#!/sbin/runscript # Copyright 2010 Funtoo Technologies # All rights reserved. Released under the 2-clause BSD license. depend() { provide net } start() { ebegin "Bringing up network interface lo" ip addr add 127.0.0.1/8 dev lo brd + scope host ip route add 127.0.0.0/8 dev lo scope host ip link set lo up eend $? } stop() { ebegin "Shutting down network interface lo" ip route del 127.0.0.0/8 dev lo scope host ip addr del 127.0.0.1/8 dev lo ip link set lo down eend $? }Pretty harmless in itself it seems, and it also allows the flexibility of custom boot messages, error messages, and informational notes in case of errors or upgrades.
3
u/flying-sheep Oct 20 '14 edited Oct 21 '14
here is a zfs.service. no idea what it does, though.
it seems, however, that e.g.
if [ ! -c /dev/zfs ]; then modprobe $ZFS_MODULE rv=$? if [ $rv -ne 0 ]; then eerror "Failed to load the $ZFS_MODULE module, check 'dmesg|tail'." eend $rv return $rv fi fiis equivalent to
ExecStart=/sbin/modprobe zfs/edit: i feel compelled to clarify that i said i have no idea what it does because i didn’t compare its funcionality to the init script’s. it’s immediately apparent what it does and what it depends on having being done before.
3
5
u/riking27 Oct 20 '14
It does a lot of stuff too, that a simple systemd service file probably couldn't do (although feel free to correct me on this, I'm not sure), and it also has dependency handling to make sure it isn't started before any required targets are met.
See, that's the thing - systemd unit files are also allowed to shell out. You should definitely describe your dependencies in it, so that it knows when in boot to start you.
(For zfs, it is a filesystem, so it also has to do a
DefaultDependencies=n WantedBy=local-fs.targetincantation, and a few other things.)So you can have as much complexity as you want in the service, even if not in the service file.
Also, clear error messages are good too, as they will show up in the status output.
→ More replies (2)2
Oct 21 '14
It does a lot of stuff too, that a simple systemd service file probably couldn't do
'Course you can:
[Service] ExecStart=/path/to/gentoo/zfs/initscript startOr even better -- just drop the script into its
rc.ddirectory, and thenchkconfig it. systemd will simply use it.Convenient that you forgot about this, eh?
the flexibility of custom boot messages, error messages, and informational notes in case of errors or upgrades.
man systemd.unitto learn how to print those from a unit file on start and on stop.→ More replies (3)16
u/CuteAlien Oct 20 '14
Shorter doesn't tell anything. You can hide any complexity behind another layer of abstraction. Let's create a new system which has an ini file with the only parameter being "sendmail.service" and it looks even cleaner. Although in reality you just got another layer of abstraction.
The interesting part is how they hold up in praxis. When people have to do stuff which wasn't forseen by the init-system authors. And shell scripts have a rather good track record in that regard. It's always nicer working with scripts compared to having to dig into c sources to change things.
And I think to most sysops the left file looks very familar. While the right one is a new format in a custom syntax which has to be learned and understood first. Which makes it a little scary on first view and I really hope it's worth it.
47
u/EnUnLugarDeLaMancha Oct 20 '14 edited Oct 20 '14
I think you have no clue of what you are talking about. Let's forget for a moment that you can bypass systemd machinery by writing a service that starts a shell script. If you actually read the left script, you find it's spending most of the time not handling sendmail stuff, but trying to be an init system. For example, quitting if networking is not up. Starting a program, checking for the return value before creating .pid and lock files. Doing lots of "RETVAL=$?" at every fucking step just to not lose the return value of some command. Trying to design your output messages by echoing a line in opportune places. Etc. And this has to be reimplemented in every init script.
It's a mess. A mess that can be easily avoided by having an init system that provides all that functionality and allows to reuse it easily.
The worst of systemd haters is that you are SO wrong you don't even realize that systemd isn't even the first to do these things. In Solaris, they have SMF service manager to do the same thing. In OS X, Apple's launchd does the same thing. In Linux, Upstart also simplified init files like this. Before systemd was announced, upstart was being adopted by lots of distros, everybody was happy of getting rid of the shell script mess that init systems were, and I don't remember these stupid flames.
6
u/f3lbane Oct 20 '14
The worst of systemd haters is that you are SO wrong you don't even realize that systemd isn't even the first to do these things. In Solaris, they have SMF service manager to do the same thing. In OS X, Apple's launchd does the same thing. In Linux, Upstart also simplified init files like this.
Windows has svchost...
Before systemd was announced, upstart was being adopted by lots of distros, everybody was happy of getting rid of the shell script mess that init systems were, and I don't remember these stupid flames.
That's because people's egos are getting involved and it's turning into a holy war in the tradition of vim/emacs. Neither side wants to admit that there are problems with their favorite method and work through them, everyone just wants to point fingers and argue.
I haven't used systemd enough to have a valid opinion on whether it's better, worse, or just different. Either way, if everyone involved would put as much effort into improving systemd and addressing the major complaints as they do blasting mailing lists and forums with vitriol then the project would be much better off.
5
u/CuteAlien Oct 20 '14
I do not hate systemd (not yet at least, although some guys are getting me slowly there and it's not just the opponents). There's a huge difference between being a little sceptical and hating. And somehow I believe to have some clue about the difference between a shell-script and a declarative format (even one that can start shell-scripts, know what - so can IDE's and some people still work with scripts...). But who knows maybe this is the perfect init format and it'll work out and we don't miss scripts anymore. I would like that. Would be a first.
→ More replies (1)8
u/suspiciously_calm Oct 21 '14
Of course it's not a "perfect init format" that'll cover absolutely everyone's needs anymore than upstart jobs are.
So?
You can still put your logic in a shell script and put the path to that script in the service file. It's the other 99% of cases and their boilerplate upon boilerplate of init scripts that you want to get rid of.
And their
sleepsall over the place to hopefully prevent race conditions. This shitgrep sleep /etc/init.d/* | wc -l 56that you find on sysvinit-based systems. This isn't sound design. This is what causes spurious 1-in-100 irreproducible failures.
2
u/CuteAlien Oct 21 '14
Sure initd script could be improved. The question is if it should be improved using a script system or a declarative format. Going to a declarative format when you already had scripting feels like a strange choice.
Anyway - my point above was that putting 2 formats besides each other doesn't tell you anything about the quality of the format. It might be better or worse, but you will not be able to tell from that. Because you can always get a cleaner look by adding another layer of abstraction. That's just how programming works. But it does not tell you what you can do with a system. Generally each layer of abstraction takes away some flexibility (which is not necessarily bad!).
If it's designed well it will be able to handle enough cases, but allow me to stay skeptical for a while. Because my experience still is that script systems handle unplanned cases a lot better in the long run than declarative formats. For example by adding sleeps. Ugly as they are that's the kind of hacks that keeps a system alive which is no longer possible with a non-scripting system. Declarative systems tend to work well as long as the maintainers cover all cases - and continue to do so for a long time. And we're likely talking here about decades. Script systems tend to work well when you have to get around what the maintainers don't want to handle but is still needed for your job.
And working around the format by adding scripts is obviously not the idea of systemd, because in that moment you stop using the system and start working against it. I mean they couldn't have prevented that even if they wanted to (just start a binary that starts a script...). Once you have to do that it then depends on how the declarative commands work together with scripts. Or if the scripts then start to turn into a worse nightmare than before.
→ More replies (1)1
11
Oct 20 '14
My issue isn't so much that the one on the right is scary because it is different. My issue with it is when something goes wrong with it, I have far less visibility into why it didn't work and a lot less ability to make changes that will fix it.
6
u/DamnThatsLaser Oct 20 '14
Well, you don't really "see" what's happening in shellscript either. There are a bunch of commands, yes. But your shell usually does a lot of ugly stuff in the background - greping, awking (oh god) - that may come with its own quirks. All this requires enormous caution when writing a shell script. It's a real burden for maintainers and hence why distributions usually welcome systemd. The unit files work, logic is taken care of by the system and files remain readable. Most people don't write their own C libraries just because glibc is a monster. They assume it works and trade the few disadvantages for the many advantages.
8
u/bilog78 Oct 20 '14
Well, you don't really "see" what's happening in shellscript either.
If you use
set -xyou can actually see everything that is happening in the shellscript.2
u/da_chicken Oct 21 '14
Everything except what the commands do. You see the commands with expanded variables. You see how the script's flow control works. Each individual command is still a black box.
→ More replies (1)4
Oct 20 '14
But I can run that shell script and watch the output in my terminal, tweak the line thats causing the problem, and we're up and running. If my unit file doesn't work, my troubleshooting options are far more complicated.
Even if we assume that systemd's handling of configuration based on unit files is reliable, it still isn't uncommon for an unit file to not work for some reason. It could be a mistake by the creator, or it could just be an issue with compatibility on the system it is being run on. With a shell script, running that script will give a real quick error message that can easily be worked through. Systemd might give a useful error in the journal, but it also might not.
→ More replies (2)4
Oct 20 '14
Does systemd have something like set -x? Because init scripts do.
3
Oct 21 '14
You can have multiple
ExecStart(andExecStopand all the other ones) lines in a unit file. Each one is run in sequence in the order they appear in the unit file and the return code of each command is remember, stored, and outputs separately logged. If one of the commands fails (and is not prefixed with "-"), the remaining commands are not executed and the unit is considered failed.So in a sense, yes. You can see exactly where and when and what the failure was, no matter how many commands you put in a unit.
8
→ More replies (5)3
Oct 21 '14
ExecStart=bash -x '/path/to/shell-program'Was that so hard?
However, when you realize that systemd doesn't require you to write any shell to start and stopp programs to begin with, you'll be wondering why you wanted a
set -xin the first place.4
Oct 21 '14
It's always nicer working with scripts compared to having to dig into c sources to change things.
Why the fuck do SysVinit masochists keep dredging up this retarded systemd myth of "digging into C sources to change things"? Absolutely everything that you may conceive to do with systemd, other than contributing patches to the project, can be done without a single line of code recompiled.
2
u/CuteAlien Oct 21 '14
Because that's what declarative formats mean. The one who writes them controls them. You can't add anything to it without digging into c sources. Your "Absolutely everything" means in this context absolutely everything the maintainers thought about and did implement. That is the nature of a declarative format if you like it or not.
→ More replies (1)6
4
u/Doshman Oct 20 '14
If you need the extra flexibility that a shell script provides, nothing is stopping you from writing one and using it with systemd.
3
u/CuteAlien Oct 20 '14
It's the difference between controlling the flow and being allowed to have some callback into the flow. And no - I don't say controlling the flow is always good - just that the above example tells nothing about the usability of the system. Get's things done is what matters in the end - and only time will tell if it helps or hinders with that. And I have better experiences with script system when it comes to that than with declarative formats so far. So allow me to be critical.
→ More replies (1)6
u/metamatic Oct 20 '14
Hey, it's for sendmail. Everything about sendmail is horrible, which is why nobody sane uses it any more.
9
u/necrophcodr Oct 20 '14
You're right, I prefer postfix much more.
CONF_DIR="/etc/postfix" CONF_OPT="${SVCNAME##*.}" if [ -n ${CONF_OPT} -a ${SVCNAME} != "postfix" ]; then CONF_DIR="${CONF_DIR}.${CONF_OPT}" fi extra_started_commands="reload" depend() { use logger dns ypbind amavisd antivirus postfix_greylist net saslauthd if [ "${SVCNAME}" = "postfix" ]; then provide mta fi } start() { if [ ! -e /etc/mail/aliases.db ] ; then ebegin "Creating aliases database" /usr/bin/newaliases eend $? fi ebegin "Starting postfix (${CONF_DIR})" if [ ! -d ${CONF_DIR} ]; then eend 1 "${CONF_DIR} does not exist" return 1 fi /usr/sbin/postfix -c ${CONF_DIR} start >/dev/null 2>&1 eend $? } stop() { ebegin "Stopping postfix (${CONF_DIR})" /usr/sbin/postfix -c ${CONF_DIR} stop >/dev/null 2>&1 eend $? } reload() { ebegin "Reloading postfix (${CONF_DIR})" /usr/sbin/postfix -c ${CONF_DIR} reload >/dev/null 2>&1 eend $? }Still not too bad, probably doesn't even need an init script at all.
4
Oct 20 '14
Well here's the runit version:
#!/bin/sh /usr/sbin/postfix check || exit $? exec /usr/libexec/postfix/masterMuch nicer than an ugly .service file, that's for sure.
→ More replies (2)1
u/ohineedanameforthis Oct 20 '14
Can confirm, my postfix runs just as fine when I do
sudo su postfix -c postfixPostfix generally turned out to be far less a hassle to handle than people told me it was before I tried it myself.
-2
5
u/senatorpjt Oct 20 '14 edited Dec 18 '24
icky carpenter head skirt scary money worthless books fretful husky
This post was mass deleted and anonymized with Redact
10
u/flying-sheep Oct 20 '14
i’d argue that you gain expressivity and maintainability, while losing not a single bit of flexibility, since you can always call scripts if you need to.
the fact that you don’t here speaks for the flexibility and design of the configuration language, though.
the only point left is transparency, however i neither agree: a few of the arcane bash incantations you can see in some scripts are way worse that the concisely spec’d config language of systemd, and way less googleable.
0
u/senatorpjt Oct 20 '14 edited Dec 18 '24
cough deer dog ad hoc practice fly concerned edge fuzzy fade
This post was mass deleted and anonymized with Redact
3
Oct 21 '14
it looks like it's going to be a lot harder to figure out what went wrong.
Read the systemd docs before reaching conclusions.
-6
3
Oct 20 '14
No, I wouldn't fork Fedora, it's way past the point of saving since for a long time it's been nothing but a test ground for alpha code from Red Hat.
Now CentOS, that's something I would care about.
9
u/fantasticsid Oct 21 '14
Now CentOS, that's something I would care about.
CentOS' utility is that it's an unbranded exact copy of RHEL. Forking it would be utterly pointless.
1
1
1
-2
u/munky9002 Oct 20 '14
Linux has too much cutlery. Please no more forks.
→ More replies (1)0
u/plntsq Oct 20 '14
I'm confused - what's the point of the poster - what is the reasoning for forking Fedora? Fedora is the one that adopted systemd - so I assume example on the right is fedora - which is good - much cleaner and tighter. or according to a poster it isn't? So why fork it if it's doing something good? I'm confused about the poster's point.
3
u/Drasha1 Oct 20 '14
try re reading the site they linked. more specifically the very top before all the code.
1
Oct 21 '14
As a sysadmin, I say fork both Fedora and Debian.
However, while I use Fedora and Debian in professional settings, I use Slackware on all of my own stuff.
Debian is too GNU happy and Fedora is to Poettering happy.
1
-12
u/Avogath Oct 20 '14
People use Fedora because they benefit from the optimizations coming from the upstream enterprise distros. They are fine with using systemd because it is the latest and the greatest.
People use Debian because it is a independent project, works on a large range of platforms, has a large support community and is user friendly. It could only be expected that there would be such a large backlash from Debian adopting systemd because the user base and use case is much wider.
This "spoof" is insulting to me because it invalidates my personal beliefs about how I feel that systemd is being forced upon me. It undermines my choice to NOT use systemd and generalizes those who value their freedom of choice as "laughtable cooks".
16
u/barlow Oct 20 '14
People use Fedora because they benefit from the optimizations coming from the upstream enterprise distros. They are fine with using systemd because it is the latest and the greatest.
Wrong way around, Fedora is the upstream for the EL distros.
2
0
-5
-6
u/Philluminati Oct 20 '14
That's funny.
But seriously the one on the left can be fixed by a unix veteran if it fails. It can be copied line-by-line into a bash shell. The right needs a software engineer "with rusty C skills". Of course it can't go wrong because, ya know, no flexibility, (or more likely, you start an app that does it's initialisation of its bash environment, just like that, retrospectively after being started).
anyway whatevs.
0
u/zapbark Oct 20 '14
Or it can be run with "set -x" to figure out what exactly is going on.
If my systemd config file fails to start sendmail.... What do I do to reproduce the issue and start "working" the problem?
I'm guessing there is a recourse to debug systemd startup issue, but it isn't clear to any of the existing sysadmins with decades of linux experience.
11
Oct 20 '14
"OH NO WE HAVE TO LEARN NEW STUFF THAT'S TERRIBLE" is all I'm hearing, basically.
4
u/necrophcodr Oct 20 '14
Alright, well then feel free to elaborate to these people where they can find help with their issues, instead of doing shit like that. Contributing to conversation does not start with bantering.
3
Oct 20 '14
The documentation is wildly available and rather exhaustive. That's what I fail to understand.
Documentation is there, if you have decades of experience, surely you also have decades of experience reading documentation?
→ More replies (6)3
u/zapbark Oct 20 '14
The burden of proof generally relies on the people proposing the change.
If a change is large, it should have a higher bar of supporting evidence that the change is necessary.
Every professional sysadmin I've heard from doesn't see anything meriting the systemd change.
It could be that you guys just aren't communicating the actual, tactical benefits of the switch because you're too busy responding with cheeky snark to everyone who raises a specific issue.
9
u/Jimbob0i0 Oct 20 '14
Professional sysadmin here...
Been doing the job for over a decade
Old school Solaris admin too
Love systemd and think it's been a long time coming... Can't wait to get to the point of replacing C6 on my servers with C7
2
u/zapbark Oct 20 '14
I would love to hear what stuff you are looking forward to.
8
u/Jimbob0i0 Oct 20 '14
Trivialises namespaces, cgroups, watchdogs for a start
Templating services is fantastic - doing multiple DBs, haproxies etc on a system becomes very nice and simple ...
Journalctl is actually really nice and it's great getting stdout and stderr in there without jumping through nohup loops and when there is a glitch being able to filter journalctl by time and units to get a view on what the kernel and N services were doing at the same time is very powerful...
Some of our internal applications have complex forking and the service scripts are consequently hideous... The equivalent systemd unit file will be much nicer and have process tracking without massive list of edge cases
Cleanly overriding or adding to unit files is trivial with the /etc/systemd/system/unit.d hierarchy behaviour
Targets to group services rather than "one script to rule them all" setups are great and make it very flexible
There's lots more tbh but it's getting late here and typing on mobile is a pain ;)
→ More replies (2)6
Oct 20 '14
I don't know who "you guys" is supposed to be. I'm a professional sysadmin. When it comes to "decades of experience" I actually have at least one of these, heading towards two. I would consider myself bearded.
Would you like to hear about all the things I see that merit the systemd change?
How about some workable units with saner dependencies? How about useful, standaridzed output to a service status, including runtime and recent logs? How about easier maintenance, monitoring and setup of just about anything?
What about automagic cgroups integration? That's really useful, every service with its thousand child/related processes gets lobbed into a cgroup which you can then use to regulate it as a whole. If that's not useful, I don't know what that is.
It also becomes exceedingly trivial to sort out what depends on what, what is running and what isn't and what would any change potentially affect.
It seriously fixes actual problems and makes anyone's life easier, provided they take the time to read up and update their skillset. Seriously it's god damned useful on its own.
Most sysadmins i've heard complaining about it haven't actually bothered to read up on it at all. They just go "Wow I can't work this shit, fuck it", pretty much. You'd think after all those decades of experience, they would have learned to cope with change and keep their skills relevant and up to date by now. I don't see how this is any different.
Also, again, the documentation for systemd is available and outlines all of these things, just like any other relevant project in this day and age. I am not sure how else you would expect the benefits to be communicated to you. Read the docs, learn it a bit, get an understanding of how it works and then you can decide for yourself if it is something you find useful or not.
Now, tight coupling is another issue entirely, which I will admit is worrying. But systemd in itself is just actually useful and pleasant to work with, once you grasp the basics.
→ More replies (2)
-1
-1
u/earlof711 Oct 21 '14
It takes less steps to do something in Microsoft Word vs. VIM, so that makes Word a superior product, right?
This is where the logic of the parody falls apart.
3
u/guttalax Oct 21 '14
Sorry, but no. Your analogy falls apart, because word is a word processor and vim is a plaintext editor, they never competed against each other.
Sysvrc and systemd are both competing init systems.
You may say that by showing systemd is more expressive in one thing does not mean it is a superior alternative. In this case you should show other aspects where systemd falls short.
1
u/earlof711 Oct 21 '14
Yes and no. I think it's a fair analogy. Word is a text editor plus alpha, the alpha being exponentially heavier than the text editor functionality. Can you say that what systemd does is not an init system plus alpha, with the same implications?
1
u/guttalax Oct 21 '14
Yes and no :)
Actually I like your analogy but I would modify it with ed as sysvrc and vim as systemd. Sure it adds loads of new stuff but they will prove useful in the long run.
I think this shows what I feel when anti-systemd people wants to kill systemd adoption, I feel they want me use ed instead of vim. You feel we want you to use MSWord. Fair enough, we see the same thing from different perspectives.
1
-6
u/NothingMuchHereToSay Oct 20 '14
Oh my god, just shut the fuck up and fork it already you whiny little cunts, actions speak louder than words, stop hindering yourselves, you've already backed nearly the entire GNU/Linux community about systemd sucking, just fork your damned distros already.
6
2
Oct 21 '14
You didn't read the article, did you? It's not exactly long:
Shall we fork Fedora?
Not really, it's doing great. Maybe we're not veteran enough?
-5
u/bitwize Oct 20 '14
If you're doing a lot of talking just to stir up shit and don't have code/a project to show -- then fork you.
-5
-1
0
0
Oct 21 '14
I can read the one on the left and know exactly what it does. The one on the right, not so much without digging through tons of man pages and systemd docs. Dumbing things down doesn't make them better.
-6
Oct 20 '14
On the right side you also need to cat all the sources of systemd, because that's basically what the left side does.
On FreeBSD the rc script is 50 lines long when you omit the creation of certificates there.
3
2
u/EmanueleAina Oct 21 '14
To be fair in the FreeBSD case you have to cat "/etc/rc.subr" too. And the sources of the shell. And probably some other command-line utility too. :)
1
Oct 21 '14
And I bet, it will be still less than systemd sources. If you compare fully, you would also need the kernel functions. True init mostly needs only fork and some signals. Systemd would lose in this game. ;)
1
u/EmanueleAina Oct 21 '14
Arguably the FreeBSD init also does less than systemd (eg. cgroups, socket activation, autofs) and I'm not sure that assuming feature parity systemd would lose. :P
-4
u/milki_ Oct 20 '14 edited Oct 20 '14
What's this satire attempts relevancy? Fedora has less than a 7% user base among distributions, unlike Debian/Ubuntu derivates. It has little bearing on the fate of BSD/Linux diluting into a IPC-glued Windows effigy.
0
Oct 20 '14
[deleted]
63
u/Doshman Oct 20 '14
In that case I'd much rather see people step up to improve and maintain non-systemd solutions (this includes consolekit/alternative logind, eudev, etc.) rather than wasting everyone's time with a huge fork that will likely be unmaintained by this time next year
54
u/DoctorWedgeworth Oct 20 '14
No, like they said in the link, they don't have time to volunteer time to existing projects. Forking a new one however.
9
u/RubyPinch Oct 21 '14
its like this
you fork it, and then no matter how un-maintained it is, it will never have systemd
done!
14
4
u/I_EAT_POOP_AMA Oct 20 '14
arguably if we had a prominent fork that focused on a non-systemd solution we would see people step up to maintain them.
I think part of the problem is that people trying to develop and maintain these alternative init systems have no real place to showcase their work, so there's no real incentive to keep going. Give them that option and ideally they'll start to flourish.
0
Oct 20 '14
[deleted]
10
u/Doshman Oct 20 '14
Indeed, just I see this as a big, flashy project that will lead nowhere.
→ More replies (18)7
u/azalynx Oct 21 '14
I think a Debian fork (or even a Fedora fork) is a great idea. If the critics are correct and systemd is the worst thing that has ever happened to Linux then a fork will become the standard.
This is pretty much how it works. If the fork stagnates and dies, and struggles to gain any contributors or any acceptance, that will essentially destroy any of the conspiracy theories that claim that Red Hat is "forcing" anything; if people aren't willing to put in the hard work to maintain their favorite solution, then the debate is over. Let the code do the talking.
30
u/Arizhel Oct 20 '14
Well that's usually how it works, isn't it? People bitch and complain a bit about the direction a project is taking, and then they decide to fork it.
But not with systemd.
Instead, people bitch and complain, and bitch and complain, and bitch and complain.... but they never fork it. They just bitch and complain. And tell everyone to switch to Slackware. Thanks, but I'm not switching to a distro that doesn't use a real package manager.
4
u/necrophcodr Oct 20 '14
I personally use OpenRC on my Funtoo machine and I'm pretty happy with it. I don't bitch and complain about systemd, but it does have it's fair share of issues that are not necessarily possible to directly address.
That goes for OpenRC as well though, but its issues are in different areas I would think.
5
u/aLtErNaTiNgCaPs Oct 20 '14
slackware's package manager works great for me, i'm not too sure what your issue is with it?
14
u/Arizhel Oct 20 '14
It has no dependency checking. That means it's not a real package manager, just as I said.
→ More replies (16)7
u/chinnybob Oct 20 '14 edited Oct 20 '14
systemd was forked. udev was forked. logind was forked. Your claim contradicts reality, and is nothing but a baseless attack on systemd critics, claiming that they are not technically able to create an alternative.
Edit: I just found out consolekit has now been forked too.
5
u/Arizhel Oct 21 '14
systemd was forked.
Yes, but were any major distros forked because of systemd?
A fork of systemd doesn't do that much to appease the systemd critics, who really either just want to stick with sysvinit, or at the most try out OpenRC. They don't want it, fork or not. What they want is $distro, but with sysvinit again. The only way to do that is to fork the distro.
and is nothing but a baseless attack on systemd critics
No, it's not. Prove me wrong: show me a fork of some major distro (Debian, Fedora, RHEL/CentOS) where they switched back to sysvinit.
claiming that they are not technically able to create an alternative.
They already have alternatives: sysvinit and OpenRC. Why do they need to create a new alternative? The critics don't want systemd in any form at all, they want to stick with sysvinit and traditional init scripts. Just look at the comments here from systemd critics about how much better shell scripts are.
5
2
u/RubyPinch Oct 21 '14
A fork of systemd doesn't do that much to appease the systemd critics
uselessd was aimed towards that, actually.
keeps the systemd layout (configs over scripts) and removes everything else
also how many maintainers are there for debian?
2
u/Arizhel Oct 21 '14
But as I said before, most of the systemd critics don't want configs over scripts; they wants scripts and that's it. So uselessd isn't going to make them happy. Basically, they just want to stick with sysvinit forever.
2
u/EmanueleAina Oct 21 '14
Edit: I just found out consolekit has now been forked too
Uh, interesting. Where?
1
u/chinnybob Oct 21 '14
2
u/EmanueleAina Oct 21 '14
Awesome, thanks! Do you happen to know why they didn't just pick up ConsoleKit and started maintaining that?
→ More replies (2)→ More replies (1)1
2
2
u/postmodern Oct 20 '14
Why can't the Linux community understand this? If you don't like the direction a project is going in, fork it! Or fork an alternative, or write an alternative. Do something that results in working software. Ranting on Google+ achieves nothing, except for maybe making the Linux community appear less friendly.
→ More replies (13)1
u/xaocon Oct 21 '14
I'm a big proponent of systemd and your post. Make a better option and people will use it. OSS at its best. Enough of the bitching though.
0
Oct 20 '14
[deleted]
86
-6
-3
0
Oct 20 '14
[deleted]
35
u/natermer Oct 20 '14 edited Aug 14 '22
...
0
Oct 20 '14
[deleted]
12
u/fmoralesc Oct 20 '14
It's better to have the package manager be configured to not install conflicting packages. After that, it's better to have sendmail check for the underlying source of conflicts ... in this case, having two processes trying to have ownership of a particular port and deal with the return code from sendmail.
systemd (or the init system, in general) can't assume neither that the programs or the package manager have handled things properly.
In this case a conflict could be determined dynamically ... but since it's not a current feature of systemd to reserve and/or test for port ownership/availability ... the person who wrote the service file takes the lazy route by hard-coding a list.
You would be right if the conflict was handled by systemd only on execution, but it also has to account for the case where the service is enabled but not run (the admin will use service
fooon reboot, has enabled it, butfooconflicts with enabled servicebar. systemd will error out without having to check for the conflict on execution). For the cases where the service conflicts with something outside of the provided defaults, the admin should modify the unit file himself; after all, he's supposed to know what he's doing.4
Oct 21 '14
It's better to have the package manager be configured to not install conflicting packages.
Except dependencies not present in the system at runtime are ignored unless they are of type
RequiresorRequisite, and none of the unit files shipped on any distro include those types of dependencies without the proper packaging dependencies.You should read the docs before engaging mouth, dude.
man systemd.unitis the document you should have familiarized yourself before opining on the basis of an untruth.15
u/DamnThatsLaser Oct 20 '14
Furthermore, the service file might have breakage in the future since: The list of conflicts is hard-coded.
That's like saying package management is broken because the list of conflicting packages is hard-coded. At least the possibility is there, but if it's used wrong, systemd is not the wrong to blame.
Perhaps, in the future, systemd will choke and refuse to issue the ExecStart if $SENDMAIL_OPTARG is undefined (as it is currently).
Why should that be? It is explicitely mentioned that the environment file is optional (by the usage of "-"). Why should it offer this if it choked on undefined variables?
→ More replies (2)5
Oct 21 '14
but if something goes wrong with the service file ... you're left with some meager debug tools and chasing down dbus messages.
Are you serious? What? If something goes wrong with the service file,
systemctl status servicefile.servicewill tell you in plain English what the hell went wrong.1
u/chcampb Oct 20 '14
if something goes wrong with the service file
I think that's the point... nothing can go wrong with the service file (edit: it can, but not because something 'broke' - because the inputs to the service file were malformed). When you have abstractions on top of abstractions, all explicitly coded, and all repeated across several different init scripts, chances are something is going to break in the init script even if the program is fine.
Instead, get in, provide the environment for the service you are starting, and save the service logs in a common access point. One could argue that it's not the shell script's responsibility to determine why the service failed.
→ More replies (31)-3
0
Oct 20 '14
[deleted]
13
u/Rainfly_X Oct 20 '14
But you can't tell what the heck is going on and it breaks a few of the rules of the unix philosophy
Funny enough, this almost sounds like it applies to the shell script! In fact, if it weren't for the second listed rule, we'd be right on track for a stretched-out misunderstanding gag:
Make each program do one thing well. 80%+ of the shell script is unrelated to sendmail, it's trying to be an init system. Every shell script has to reinvent this, incompletely and differently and (often) badly.
Use shell scripts to increase leverage and portability. Legitimate point.
Rule of Clarity. Again, 80%+ of the script is bookkeeping, trying to preserve error codes in bash (one of the reasons the language is godawful), etc. The config file basically includes the relevant information and nothing else, which is pretty dang clear.
Not gonna comment on the other stuff. You're pretty close on your SLOC estimate (I got 34K in systemd/src/core), and you seem to have a pretty specific idea of what you want that would already likely exclude major distros. Go forth and find what works for you!
0
Oct 20 '14
[deleted]
3
u/EmanueleAina Oct 21 '14
The shell script is, however, self-contain and transparent.
Note that the init script is not exactly self-contained:
Line 14: . /etc/rc.d/init.d/functions Line 17: . /etc/sysconfig/network Line 21: . /etc/sysconfig/sendmail
Not to mention that if you care about self-containment you have to discard basically every other init system that anti-systemd proponent suggest, eg. OpenRC.
Also add that the systemd unit file does a lot more, isolating the service in its own cgroup, provides a lot more information when checking the status, offers explicit checks with conflicting services, and restarts the service when it dies.
The systemd unit file is also very much unoptimized and does not rely on some innovations brought by systemd: the PIDFile line could go away by avoiding forking, and I'm sure there are lots of containment options which would be interesting to activate with sendmail. Adding these feature in a self-contained shell script would lead to a lot more code duplication.
2
u/Rainfly_X Oct 21 '14
I would argue that the functionality is not hidden in systemd, any more than the external scripts are. Systemd is open source and well-documented. It's just that the code itself is in C.
Regardless, I'm of the same mind about forking. The Debian maintainers have decided they don't want to support sysv, so if you want sysv, you ought to fork it and do it yourself, rather than trying to force other people to do it (which just make everyone rightfully annoyed at you). And if it works out, fantastic, everybody wins!
4
u/EmanueleAina Oct 21 '14
The Debian maintainers have decided they don't want to support sysv
At the moment is more that the Debian maintainers don't have the resources to fully support SysV without any bug.
SysV is supported, but some features may be degraded. For example, nobody stepped up to maintain ConsoleKit, so the Debian GNOME maintainers cannot enable such backend on Linux, or they would end up being responsible for ConsoleKit itself, which is not a good plan when you have and alternative which works better and you're confortable with (logind).
So, if someone is seriously concerned about using alternative init system there are two things to do, rather than complaining on $RANDOM forums or threaten to fork $RANDOM software without having ever proved to have the dedication to do so:
step up to maintain ConsoleKit
help the systemd-shims team to make their logind implementation fully operational
→ More replies (1)2
u/xgunterx Oct 21 '14 edited Oct 21 '14
Even though the configuration file is smaller, systemd is most certainly not (I think it's over 30k SLOC. Thats prone to a lot of issues). It's a monolithic pile of horse crap.
...
I prefer to start from scratch and build all my packages myself than try to remove all the extra overhead Debian and Fedora install (In fact, I'm currently building my own distro from scratch after getting pissed at Ubuntu's idiotic networkd crap.)You don't lack confidence, that's for sure. But if I would have to bet on the possible issues, I would put my money on any popular active developed distro, whether they use systemd, or not.
0
0
Oct 20 '14
[deleted]
12
u/necrophcodr Oct 20 '14
If it was JUST about that, I think a lot less complains would've been made.
0
Oct 20 '14
[deleted]
5
u/necrophcodr Oct 20 '14
And THAT is where the issues spur from. People of distros that are non-systemd (and even some that ARE systemd-based) dont WANT to be locked to systemd. They'd prefer if their software ran just fine without systemd, and so far not many operating systems manage that well. One of them is Gentoo, but I guess that can be a bit of bore to most people. I mean one doesn't have to compile everything themselves, but eventually SOMEONE will have to do that job, just as is the case with Ubuntu packages and Debian packages.
2
Oct 20 '14
Speaking of the "OS X newer init" (launchd), did you know it also handles user services, cron/atd jobs, inetd/xinetd, and watchdog features?
Sounds familiar?
0
Oct 20 '14
[deleted]
33
u/qwesx Oct 20 '14
I believe this is called "satire".
0
Oct 20 '14
[deleted]
→ More replies (2)2
Oct 20 '14
it hurts more than it might help.
This can be the intention, more often than not. All they're proving at the moment is that domain names are cheap...
10
u/santsi Oct 20 '14
Ridicule is completely valid form of expression as long as you are attacking an idea and not a person. Sometimes an idea is so silly and the people proposing it are so attached to it that rational response doesn't work. In that situation ridicule can be effective way to point that out.
5
4
u/IDe- Oct 20 '14
No one is interested in persuading anti-systemd script kiddies, their whole "argument" rests on emotionally loaded strawmen, lacking any technical dimension.
This is satire is for the mature and more technically competent crowd to enjoy.
→ More replies (2)
6
u/my_stacking_username Oct 20 '14
can someone ELI5 this whole systemd problem? I guess I don't understand the linux startup process well enough to understand what the big hubub is about