Count me as a systemd convert(changelog.complete.org)
changelog.complete.org
Count me as a systemd convert
http://changelog.complete.org/archives/9655-count-me-as-a-systemd-convert
140 コメント
So that it's easier to bring up/down a number of related service units with single actions.
Example: systemctl stop smbd nmbd ; systemctl start smbd nmbd
It isn't that the operation is the /middle/ parameter, it's that you have invocation action //LIST//
Example: systemctl stop smbd nmbd ; systemctl start smbd nmbd
It isn't that the operation is the /middle/ parameter, it's that you have invocation action //LIST//
The point of OP's link is that the novelty of systemd is that you can compose chains of dependencies and how that saves time and effort.
So why should it be a common operation for the enduser to start and stop a list of related services? Instead of having to type and remember them individually, I should add a BindTo line in my service files and let systemd handle it. It's like the frontend for systemd is optimizing for a situation that it is supposed to prevent.
And anyway, there's no unixy reason the variadic argument couldn't be in the middle. cp, for example, has
So why should it be a common operation for the enduser to start and stop a list of related services? Instead of having to type and remember them individually, I should add a BindTo line in my service files and let systemd handle it. It's like the frontend for systemd is optimizing for a situation that it is supposed to prevent.
And anyway, there's no unixy reason the variadic argument couldn't be in the middle. cp, for example, has
<command name> <options> <variadic list of files to copy> <single dir to copy to>Because it's the pattern far more Unix tools use. Command name, then flags, then a file/set of files.
I felt exactly the opposite way when I used Debian (not for any justifiable reason other than "that's not the way it's supposed to beeeee") because Debian does it in the way you describe.
Theoretically, you could put on your hacker gloves and write a script that shifts the arguments for you. That might be a fun exercise!
I felt exactly the opposite way when I used Debian (not for any justifiable reason other than "that's not the way it's supposed to beeeee") because Debian does it in the way you describe.
Theoretically, you could put on your hacker gloves and write a script that shifts the arguments for you. That might be a fun exercise!
It seems you are using bash and need to up your shell game, allow to suggest zsh which allow for thing such as:
!!:s/status/stop/
This will recall the last command and substitute status with stop.
!-2:s/status/edit/
Will recall two commands back from history and substitute status with edit.
See http://reasoniamhere.com/2014/01/11/outrageously-useful-tips...
For added awesomeness have a look into history-substring-search[1], zsh-autosuggestions[2], zsh-syntax-highlighting[3].
[1]: https://github.com/zsh-users/zsh-history-substring-search [2]: https://github.com/zsh-users/zsh-autosuggestions [3]: https://github.com/zsh-users/zsh-syntax-highlighting
!!:s/status/stop/
This will recall the last command and substitute status with stop.
!-2:s/status/edit/
Will recall two commands back from history and substitute status with edit.
See http://reasoniamhere.com/2014/01/11/outrageously-useful-tips...
For added awesomeness have a look into history-substring-search[1], zsh-autosuggestions[2], zsh-syntax-highlighting[3].
[1]: https://github.com/zsh-users/zsh-history-substring-search [2]: https://github.com/zsh-users/zsh-autosuggestions [3]: https://github.com/zsh-users/zsh-syntax-highlighting
By the way, are you aware of the keypresses that move the cursor by a word at a time? In particular, <M-Left Arrow> and <M-B> should each move backward by a word. You should be able to go <Up Arrow> <M-Left Arrow> <C-W> [type operation] <Space> <Return>. You might have to enable alt as meta key on an OS X terminal (which is obviously not the case here), or disable alt as referring to file menus on Linux (which may be the case here). Prefixing a command with ESC also works as a meta key, though I'd find it ergonomically intolerable.
Try doing ^status^stop for instance moving between the first and second command.
One-liner lists are handy:
(This clearly extends far beyond systemd.)
for service in <list> do; systemctl <action> <service>; done
for system in foo bar baz; do systemctl stop $system; systemctl start $system; done
(This clearly extends far beyond systemd.)
But it accepts a list, so rather than write the loop:
systemctl stop foo bar baz; systemctl start foo bar baz
systemctl stop foo bar baz; systemctl start foo bar baz
With the caveat that yours and the version above are not the same. With properly written systemd units (e.g. using the notification API to signal when it's actually operational) the former will have fully started foo again before stopping bar (ignoring the lack of error handling in both examples..). Which may or may not matter.
True. It's just that in most cases when I write a loop like that it's to work around the fact that the restart command didn't take a list, not because I need to serialize the service restarts.
In Debian I use "service X action" which I also find preferable for the exact same reason you mention.
> Instead of being able to press <Up Arrow>, <C-Backspace>, and type my operation, I'm instead having to position my cursor to the second argument.
Maybe not as neatly, but you can do this in 5 blind keystrokes (instead of 3):
Maybe not as neatly, but you can do this in 5 blind keystrokes (instead of 3):
Up; Alt-<b; b; Backspace>Thanks for the tip, I didn't know about alt-<b>.
I should try using emacs for a month, if only for the sake of getting to know readline better.
I should try using emacs for a month, if only for the sake of getting to know readline better.
It's not a big deal, since all modern shells have move commands (e.g. "shell-backward-word" in bash) that allow you to jump to the second-to-last argument with a simple key stroke.
What's the default keystroke for bash/dash?
Ctrl-left/right (on comptible terminals) or Alt-b/f (or even Esc+b/f).
same as emacs: alt+b
I use:
"systemctl stop foo" then "stop^start"
Which will substitute stop with start in the previous command (in bash, not sure about other shells)
"systemctl stop foo" then "stop^start"
Which will substitute stop with start in the previous command (in bash, not sure about other shells)
That wouldn't really make sense at all.
Can you name any commands or interfaces that take the variable before the argument?
Can you name any commands or interfaces that take the variable before the argument?
/etc/init.d/<variable> <command>
Those aren't variables though, you are referencing specific files.
How about egrep, then?
Depending on what you're looking for, grep may or may not.
I've been known to write one-liner shell functions to put the variable component of a list of commands at the end of the commandline for easy editing.
grep <pattern> <file>
I've been known to write one-liner shell functions to put the variable component of a list of commands at the end of the commandline for easy editing.
cp, rm, rsync, scp tar...
My problem with systemctl is that it's so woeful to tab-complete. At 'syst[TAB]c[TAB]', you may as well just type out the whole thing, because tabbing only saves you two characters. Why not just take 'ctl', that doesn't seem to be taken by anyone?
cp [list of a great many items] [here]
service [item] [action]
systemctl [action] [list of great many items]
My problem with systemctl is that it's so woeful to tab-complete. At 'syst[TAB]c[TAB]', you may as well just type out the whole thing, because tabbing only saves you two characters. Why not just take 'ctl', that doesn't seem to be taken by anyone?
GNU toolset:
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
As for "ctl": Bear in mind that there are a lot of "ctl" commands. initctl (from upstart), netctl (from Arch), rcctl (from OpenBSD), pfctl (from OpenBSD), ip6addrctl (from FreeBSD), ntpctl (from OpenBSD), hastctl (from FreeBSD), swapctl (from 4BSD), rctl (from FreeBSD), pppctl (from FreeBSD), smartctl, journalctl, bootctl, localectl, busctl, coredumpctl, hostnamectl, machinectl, timedatectl, loginctl ...
Pick unadorned "ctl" for the systemd one, and one begs the question of why systemd alone is special enough not to require its name in the command.
cp -t [here] [list of a great many items]
dir *.txt /s
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
As for "ctl": Bear in mind that there are a lot of "ctl" commands. initctl (from upstart), netctl (from Arch), rcctl (from OpenBSD), pfctl (from OpenBSD), ip6addrctl (from FreeBSD), ntpctl (from OpenBSD), hastctl (from FreeBSD), swapctl (from 4BSD), rctl (from FreeBSD), pppctl (from FreeBSD), smartctl, journalctl, bootctl, localectl, busctl, coredumpctl, hostnamectl, machinectl, timedatectl, loginctl ...
Pick unadorned "ctl" for the systemd one, and one begs the question of why systemd alone is special enough not to require its name in the command.
The "-t" switch in "cp" exists to support the use with xargs, e.g.
find /some/directory/ -name *.txt | xargs cp -t all-the-textfiles/
systemctl --failed | awk '/.service/{print$1}' | xargs systemctl restartTab completion has its limits. Using zsh and some added awesomeness from fish:
sys<alt+f> and it completes to systemctl
sys<ctrl+e> and it completes to the full last systemctl command I used
https://github.com/zsh-users/zsh-history-substring-search
https://github.com/zsh-users/zsh-autosuggestions
https://github.com/zsh-users/zsh-syntax-highlighting
https://github.com/zsh-users/zsh-history-substring-search
https://github.com/zsh-users/zsh-autosuggestions
https://github.com/zsh-users/zsh-syntax-highlighting
IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile of hacks mess with an over-engineered tower of babel mess.
An improvement would be something with modern syntax, sparse features, and good docs.
An improvement would be something with modern syntax, sparse features, and good docs.
> IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile of hacks mess with an over-engineered tower of babel mess.
This is an easy criticism to make. What's no so easy is to actually implement what's needed for a modern system and still achieve what you seem to be asking for. Modern systems are unbelievably complex beasts.
> An improvement would be something with modern syntax, sparse features, and good docs.
This is getting pretty silly and it just looks like you're reaching for anything to criticize here.
What does "modern syntax" mean and why would it be an improvement on the INI-like syntax of systemd configuration?
What earth does "sparse features" mean? You don't want to support everything that a modern system requires? (Take modern system to mean everything from containerized servers to desktops to laptops to a mobile phone. All places where systemd has its place.)
You don't think systemd has "good docs"? IME Systemd has unbelievably good reference documentation for any type of Free Software (in the Unix style of man pages, no less!).
Perhaps tutorial-like documentation is somewhat lacking, but the "systemd for Administrators"[1] blog series is pretty good IMO. (Though, granted, a bit out of date, perhaps.)
[1] http://0pointer.de/blog/projects/systemd-for-admins-1.html
This is an easy criticism to make. What's no so easy is to actually implement what's needed for a modern system and still achieve what you seem to be asking for. Modern systems are unbelievably complex beasts.
> An improvement would be something with modern syntax, sparse features, and good docs.
This is getting pretty silly and it just looks like you're reaching for anything to criticize here.
What does "modern syntax" mean and why would it be an improvement on the INI-like syntax of systemd configuration?
What earth does "sparse features" mean? You don't want to support everything that a modern system requires? (Take modern system to mean everything from containerized servers to desktops to laptops to a mobile phone. All places where systemd has its place.)
You don't think systemd has "good docs"? IME Systemd has unbelievably good reference documentation for any type of Free Software (in the Unix style of man pages, no less!).
Perhaps tutorial-like documentation is somewhat lacking, but the "systemd for Administrators"[1] blog series is pretty good IMO. (Though, granted, a bit out of date, perhaps.)
[1] http://0pointer.de/blog/projects/systemd-for-admins-1.html
Speaking from experience, classic sysvinit was the bane of my existence when trying to deploy Python web applications. Having to use things like supervisor because writing init scripts is such a pain is a hack, nothing more. Writing a 10 line systemd unit file packaged in with the RPM I use to deploy my app is much less of a headache, and I welcome the change - combined with parallel startup I don't have to block nginx from loading while my application loads (or vice-versa).
Ubuntu's Upstart was also pretty nice in this regard.
It was certainly nicer than sysvinit, but its event-based model absolute hell to debug, IME. (It basically required the user to program a state machine around all the events that could happen on a system.) Just look at the bugs on Upstart in the Ubuntu bug tracker if you don't believe me. There were bugs in there that languished for years because they were basically unsolvable.
The original author of Upstart basically admitted (to his credit!) that systemd's model is superior after Upstart had been in out in the wild for a few years.
The original author of Upstart basically admitted (to his credit!) that systemd's model is superior after Upstart had been in out in the wild for a few years.
Upstarts event-driven mess made it extremely hard to debug and rationalize about your dependencies for a service. systemd's approach of a basic dependency graph for services is a lot easier to work with, plus some bonus features like socket activation and work directory creation that upstart doesn't have.
I have a python webapp hosted inside uwsgi reverse proxied by nginx, adding `RuntimeDirectory=mycoolapp` to the unit file automatically creates and destroys `/run/mycoolapp` every time the unit starts and stops. I just plop my socket file inside the runtime directory (which is automatically created with the correct uid/gid based on the user/group the unit runs as) and fly away, I don't have to manage some directory inside /var/ and deal with an rpm scriplet to ensure the correct owner/group are set on it after install.
It's all the little things that systemd does that really make one appreciate it, they add up.
I have a python webapp hosted inside uwsgi reverse proxied by nginx, adding `RuntimeDirectory=mycoolapp` to the unit file automatically creates and destroys `/run/mycoolapp` every time the unit starts and stops. I just plop my socket file inside the runtime directory (which is automatically created with the correct uid/gid based on the user/group the unit runs as) and fly away, I don't have to manage some directory inside /var/ and deal with an rpm scriplet to ensure the correct owner/group are set on it after install.
It's all the little things that systemd does that really make one appreciate it, they add up.
Thank you. I feel like this gets overlooked. It worked well, and was easy to grok. Too bad it lost support.
See the "red herring" discussion in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ and https://news.ycombinator.com/item?id=11641426 on this very page.
It's definitely wrong to think that upstart was overlooked when it came to the Debian hoo-hah, furthermore. Upstart was one of the four major contenders, and one of the two front-runners.
It's definitely wrong to think that upstart was overlooked when it came to the Debian hoo-hah, furthermore. Upstart was one of the four major contenders, and one of the two front-runners.
On your Linux system, type:
man -k systemd
There is extensive and well written documentation for all aspects of systemd so I'm going to call BS on your post. Also, the syntax is consistent and documented. It is infinitely simpler than sysvinit. Either you're trolling, or know very little about systemd. Note that I'm a fan, but far from an apologist.
man -k systemd
There is extensive and well written documentation for all aspects of systemd so I'm going to call BS on your post. Also, the syntax is consistent and documented. It is infinitely simpler than sysvinit. Either you're trolling, or know very little about systemd. Note that I'm a fan, but far from an apologist.
> There is extensive and well written documentation for all aspects of systemd so I'm going to call BS on your post.
As long as you are prepared for the rest of the world to call BS on what you say here, as well. (-:
It's only "extensive and well written" if one sets the bar for those two quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the words that come to mind are "acceptable" and "mediocre". As someone else has already mentioned here, and as people have pointed out passim over the years, the expected as the norm quality of doco for the BSD world is noticeably a higher standard than in the Linux world.
But it's not the BSD world alone where the norm is higher. The norm for the commercial Unices is and was higher, too. A case in point:
I wrote https://news.ycombinator.com/item?id=11629824 a little while ago. Checking my recollection, I referred to several manual pages for the rlogin command. The HP-UX and Solaris manual pages for rlogin actually had whole subsections about escape sequences, beginning with the general notion then proceeding to specifics of the various individual sequences. The HP-UX manual even proceeds to discuss how to send the escape character onwards, and how to send escape sequences across a daisy-chain of rlogin sessions -- something that still applies to SSH today.
The Linux rlogin manual has 1 paragraph, doesn't mention that there's actually a general concept behind the specifics that it lists, doesn't discuss how to escape the escape character, and doesn't discuss daisy-chaining.
If you're just about to point to your Linux ssh manual as a counterexample and observe the treatment that it gives escape characters, as good as that of the HP-UX doco, then scroll to the bottom of the page and enjoy the fact that you're reading BSD doco written by BSD people. (-:
As long as you are prepared for the rest of the world to call BS on what you say here, as well. (-:
It's only "extensive and well written" if one sets the bar for those two quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the words that come to mind are "acceptable" and "mediocre". As someone else has already mentioned here, and as people have pointed out passim over the years, the expected as the norm quality of doco for the BSD world is noticeably a higher standard than in the Linux world.
But it's not the BSD world alone where the norm is higher. The norm for the commercial Unices is and was higher, too. A case in point:
I wrote https://news.ycombinator.com/item?id=11629824 a little while ago. Checking my recollection, I referred to several manual pages for the rlogin command. The HP-UX and Solaris manual pages for rlogin actually had whole subsections about escape sequences, beginning with the general notion then proceeding to specifics of the various individual sequences. The HP-UX manual even proceeds to discuss how to send the escape character onwards, and how to send escape sequences across a daisy-chain of rlogin sessions -- something that still applies to SSH today.
The Linux rlogin manual has 1 paragraph, doesn't mention that there's actually a general concept behind the specifics that it lists, doesn't discuss how to escape the escape character, and doesn't discuss daisy-chaining.
If you're just about to point to your Linux ssh manual as a counterexample and observe the treatment that it gives escape characters, as good as that of the HP-UX doco, then scroll to the bottom of the page and enjoy the fact that you're reading BSD doco written by BSD people. (-:
What aspects of systemd is not well documented?
I am sure it exists, but if you're calling BS, better to be explicit.
Here's the documentation for systemd-random-seed: https://www.freedesktop.org/software/systemd/man/systemd-ran...
What are the command-line options that are available to that tool? Without looking in the source code.
>Note that I'm a fan, but far from an apologist.
An apologist is merely someone who offers a defense of something. It comes from the greek word ἀπολογία, "speaking in defense". Thus you are an apologist, even though you're not dogmatic.
What are the command-line options that are available to that tool? Without looking in the source code.
>Note that I'm a fan, but far from an apologist.
An apologist is merely someone who offers a defense of something. It comes from the greek word ἀπολογία, "speaking in defense". Thus you are an apologist, even though you're not dogmatic.
>It comes from the greek word ἀπολογία, "speaking in defense".
I just want to point out here that just because an English word comes from some Greek word, that doesn't mean the English word actually means that today. You are correct about "apologist" (according to Wiktionary at any rate), it just means someone who speaks in defense of something, but there are other words where the meaning has changed over time. English is a language that is defined by its popular usage, and this can change over time so a word may not mean the same thing today as it did just 100 years ago.
A good example is the word "pathetic". According to Wiktionary, it comes from Greek:
'παθητικός (pathētikós, “subject to feeling, capable of feeling, impassioned”), from παθητός (pathētós, “one who has suffered, subject to suffering”), from πάσχω (páskhō, “to suffer”).'
Obviously, those don't bear that much resemblance to the current popular meaning, which is:
'1.Arousing pity, sympathy, or compassion.' or '2.Arousing scornful pity or contempt, often due to miserable inadequacy.'
In fact, other European languages like German have this same word (I believe this is called a "cognate"; I am not a linguist), from the same root, but their meaning is entirely different and they get confused when they learn English and encounter this word since we use it in such a different manner.
TL;DR: Greek or Latin roots are interesting from a historical and linguistic perspective, but they're no guarantee of the current definition of an English word.
I just want to point out here that just because an English word comes from some Greek word, that doesn't mean the English word actually means that today. You are correct about "apologist" (according to Wiktionary at any rate), it just means someone who speaks in defense of something, but there are other words where the meaning has changed over time. English is a language that is defined by its popular usage, and this can change over time so a word may not mean the same thing today as it did just 100 years ago.
A good example is the word "pathetic". According to Wiktionary, it comes from Greek:
'παθητικός (pathētikós, “subject to feeling, capable of feeling, impassioned”), from παθητός (pathētós, “one who has suffered, subject to suffering”), from πάσχω (páskhō, “to suffer”).'
Obviously, those don't bear that much resemblance to the current popular meaning, which is:
'1.Arousing pity, sympathy, or compassion.' or '2.Arousing scornful pity or contempt, often due to miserable inadequacy.'
In fact, other European languages like German have this same word (I believe this is called a "cognate"; I am not a linguist), from the same root, but their meaning is entirely different and they get confused when they learn English and encounter this word since we use it in such a different manner.
TL;DR: Greek or Latin roots are interesting from a historical and linguistic perspective, but they're no guarantee of the current definition of an English word.
I believe this is called a "cognate"
A cognate is simply a pair of words from the same stem (origin); it doesn't matter if their meaning is still the same. The opposite term is "false cognate", which refers to words that sound alike and mean something similar but stem from different roots.
Regardless of origin (so cognate or not), if two words in different languages sound alike but have different meaning, they're called false friends.
</pedant>
A cognate is simply a pair of words from the same stem (origin); it doesn't matter if their meaning is still the same. The opposite term is "false cognate", which refers to words that sound alike and mean something similar but stem from different roots.
Regardless of origin (so cognate or not), if two words in different languages sound alike but have different meaning, they're called false friends.
</pedant>
Indeed, the word apologize actually does mean apologize
> What are the command-line options that are available to that tool? Without looking in the source code.
While not the greatest example of documentation, it's not completely horrible. It accepts a single parameter which is the seed (yes, I looked at the source). I imagine it was an oversight for a very simple program with a singular purpose and which isn't meant to be called manually. It's not great, but it doesn't carry the same weight with me as if there were multiple possible or required arguments, or even a single optional one. Perhaps there are examples like that, I don't know.
It's hard for me to get worked up about the level of documentation of systemd compared to SysVinit, when things like OpenBSD exist that achieve such a high level of quality that they are both utterly shamed, and appear relatively similar in their mediocrity.
While not the greatest example of documentation, it's not completely horrible. It accepts a single parameter which is the seed (yes, I looked at the source). I imagine it was an oversight for a very simple program with a singular purpose and which isn't meant to be called manually. It's not great, but it doesn't carry the same weight with me as if there were multiple possible or required arguments, or even a single optional one. Perhaps there are examples like that, I don't know.
It's hard for me to get worked up about the level of documentation of systemd compared to SysVinit, when things like OpenBSD exist that achieve such a high level of quality that they are both utterly shamed, and appear relatively similar in their mediocrity.
Accepting something as cryptographicly significant as a rng seed as a command line argument makes my security whiskers bristle.
Especially since the ultimate destination for that value is a root owned 600 perm file.
Especially since the ultimate destination for that value is a root owned 600 perm file.
It doesn't do that, the gp post misread the source code. It reads the data from a file defined at compile time.
As can be checked easily with `systemctl cat`:
$ systemctl cat systemd-random-seed
# /usr/lib/systemd/system/systemd-random-seed.service
[...]
ExecStart=/usr/lib/systemd/systemd-random-seed load
ExecStop=/usr/lib/systemd/systemd-random-seed save
[...]
Yes, I skimmed the file far too quickly. I was working off some assumptions from the portion I saw that errored if argc != 2, with an error along the lines of "There must be only one argument".
That's fine.
Now try to do a retrospective to figure out how the mistake was made, so it doesn't happen again
Now try to do a retrospective to figure out how the mistake was made, so it doesn't happen again
> Now try to do a retrospective to figure out how the mistake was made, so it doesn't happen again
What? It doesn't affect my point in any way. I looked at multiple other man pages for services before posting, and noted that of the ones I checked, they all listed options for the service and/or command. I stand by other other portion of my comment (whether you interpreted them as I meant, or in some more negative light that might induce the negativity I feel from this reply).
I noted my reasoning on why I didn't find your example entirely compelling, but also noted that there could well be other examples that fit the criteria of what I considered more problematic.
I still believe the man pages are lacking quite a bit with respect to OpenBSD equivalents.
What? It doesn't affect my point in any way. I looked at multiple other man pages for services before posting, and noted that of the ones I checked, they all listed options for the service and/or command. I stand by other other portion of my comment (whether you interpreted them as I meant, or in some more negative light that might induce the negativity I feel from this reply).
I noted my reasoning on why I didn't find your example entirely compelling, but also noted that there could well be other examples that fit the criteria of what I considered more problematic.
I still believe the man pages are lacking quite a bit with respect to OpenBSD equivalents.
Ok I'll give you that. Also up vote for the pedantic retort. Well written, and I don't know Greek, so I learned something new.
Look at the docs for something like systemd-service or -exec or -tmpfiles, etc. You found one that as bad. I'm sure you can find a few more. Now find docs for some random 1000 line shell scripts that aren't the code. At least there is a very obvious and consistent way to set the ulimit for my services, even if they don't support pam_limits via systemd, or an obvious way to extend the start script without hacking up the init file, etc. Please allow me to rephrase and say the documentation overall is so far ahead of th documentation for any implementation of init scripts and sysvinit it isn't funny. And this is coming from someone who spent most of his career as a UNIX / Linux SysAdmin.
Look at the docs for something like systemd-service or -exec or -tmpfiles, etc. You found one that as bad. I'm sure you can find a few more. Now find docs for some random 1000 line shell scripts that aren't the code. At least there is a very obvious and consistent way to set the ulimit for my services, even if they don't support pam_limits via systemd, or an obvious way to extend the start script without hacking up the init file, etc. Please allow me to rephrase and say the documentation overall is so far ahead of th documentation for any implementation of init scripts and sysvinit it isn't funny. And this is coming from someone who spent most of his career as a UNIX / Linux SysAdmin.
Also up vote for the pedantic retort.
Nah, it wasn't meant as a retort. It was merely an aside that I thought you might find interesting. And apparently you did :)
Nah, it wasn't meant as a retort. It was merely an aside that I thought you might find interesting. And apparently you did :)
Note that it's not just systemd that has mystery programs.
* https://bugs.pcbsd.org/issues/13566
* https://bugs.pcbsd.org/issues/13565
* https://bugs.pcbsd.org/issues/13564
* https://bugs.pcbsd.org/issues/13563
On the subject of systemd doco:
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
* https://bugs.pcbsd.org/issues/13566
* https://bugs.pcbsd.org/issues/13565
* https://bugs.pcbsd.org/issues/13564
* https://bugs.pcbsd.org/issues/13563
On the subject of systemd doco:
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
When I was a child, I did translate knoppix boot messages, to my mother language, for a local project. In colours.
For me was great and rewarding, a nice learning experience, about livecd's initialization and linux in general at the time.
I don't feel like I could have accomplished the same experience trying to do the same with systemd (with my age and knowledge and resources at the time).
Still more difficult, being a Debian user, where systemd is not in the same shape than RHEL based distros, and documentation is out of sync, or missed in blogs...
What you propose reminds me to openrc or the gentoo dependency based init system.
I Love too the BSD/Slackware/busybox init style (single script init). But I'm a scripting mad.
One of my reasons to live, of and for, opensource, is the ethics and freedom behind it. Other one was being more K.I.S.S. on my system interactions than with MS based products.
I feel capital interests hurts some things very hard to obtain, in voluntary groups of people, using guerrilla warfare, and without any care.
Eventually I've deployed some Debian stable (Jessie) systems with sysvinit this same year, and I'm grateful that people in Debian did that option possible.
I'm not sure if a third, or a new option with modern syntax and sparse features as you say, could be better than the years we've been moving the world using sysvinit or upstart or others... but we, the tech people, seem to like new things!
Totally agree about the docs care, specially when there are distributors involved.
When there are changes in opensource, there should be a lot of more care IMHO than in closed products, and this is not always the case.
Unfortunately people, by brain nature, is driven a lot by media and marketing, two weapons of venture capital techs. And if service providers insert X and media inserts X, people who did never maintain a critical and complex deployments using X and did integrate a lot of things with them, starts talking about the smell of the clouds.
What implementation do you suggest, to reach what you propose? I think is not easy :)
My main feature request could be: reliable and malleable (not easy too).
> An improvement would be something with modern syntax, sparse features, and good docs.
Loved your tower of babel mess definition, upvoted just by that comparison.
Have a nice day.
For me was great and rewarding, a nice learning experience, about livecd's initialization and linux in general at the time.
I don't feel like I could have accomplished the same experience trying to do the same with systemd (with my age and knowledge and resources at the time).
Still more difficult, being a Debian user, where systemd is not in the same shape than RHEL based distros, and documentation is out of sync, or missed in blogs...
What you propose reminds me to openrc or the gentoo dependency based init system.
I Love too the BSD/Slackware/busybox init style (single script init). But I'm a scripting mad.
One of my reasons to live, of and for, opensource, is the ethics and freedom behind it. Other one was being more K.I.S.S. on my system interactions than with MS based products.
I feel capital interests hurts some things very hard to obtain, in voluntary groups of people, using guerrilla warfare, and without any care.
Eventually I've deployed some Debian stable (Jessie) systems with sysvinit this same year, and I'm grateful that people in Debian did that option possible.
I'm not sure if a third, or a new option with modern syntax and sparse features as you say, could be better than the years we've been moving the world using sysvinit or upstart or others... but we, the tech people, seem to like new things!
Totally agree about the docs care, specially when there are distributors involved.
When there are changes in opensource, there should be a lot of more care IMHO than in closed products, and this is not always the case.
Unfortunately people, by brain nature, is driven a lot by media and marketing, two weapons of venture capital techs. And if service providers insert X and media inserts X, people who did never maintain a critical and complex deployments using X and did integrate a lot of things with them, starts talking about the smell of the clouds.
What implementation do you suggest, to reach what you propose? I think is not easy :)
My main feature request could be: reliable and malleable (not easy too).
> An improvement would be something with modern syntax, sparse features, and good docs.
Loved your tower of babel mess definition, upvoted just by that comparison.
Have a nice day.
> I'm not sure if a third, or a new option [...] as you say, could be better than the years we've been moving the world using sysvinit or upstart or others
* 1. System 5 rc
* 2. upstart
* 3. systemd
* 4. "third, new, option"
The "Uselessd Guy" critiqued the thinking that underlies this strange way of counting to three that is being employed here, in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ .
See also https://news.ycombinator.com/item?id=11641426 on this very page.
* 1. System 5 rc
* 2. upstart
* 3. systemd
* 4. "third, new, option"
The "Uselessd Guy" critiqued the thinking that underlies this strange way of counting to three that is being employed here, in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ .
See also https://news.ycombinator.com/item?id=11641426 on this very page.
Because the BSDs don't agree amongst themselves on how services are configured in /etc/rc.conf , OpenBSD (whose tool this is) being a major outlier, this tool does not interoperate at all well with anything other than OpenBSD.
For those with OpenBSD habits, there is a compatibility shim in the nosh toolset that translates to native nosh mechanisms.
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
For those with OpenBSD habits, there is a compatibility shim in the nosh toolset that translates to native nosh mechanisms.
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Have you tried runit?[1]
[1] - http://smarden.org/runit/
[1] - http://smarden.org/runit/
Amen sir. Seems crazy that the tipping point for the OP was being able to require certain services to have come up before others. That seems a fairly elementary aspect of process supervision.
For my money, runit gets the nod for modern syntax, sparse feature ... docs are coming along ;)
For my money, runit gets the nod for modern syntax, sparse feature ... docs are coming along ;)
My personal opinion is it's Redhat's way of seizing control of the Linux ecosystem... But that's a fringe theory
Personally, I'm waiting for Linus Torvalds to make his own init system in the event he's fed up with all the sysvinit and systemd bullshit.
Linux Kernel. Git. $torvaldsinitsystem ?
Linux Kernel. Git. $torvaldsinitsystem ?
He's not going to because it doesn't affect him personally. And let's be honest, systemd isn't that bad, and has some benefits. It's not worth getting religious over.
You'll know there are too many dependencies on systemd when people who don't want it (Devuan, Slackware, openBSD) can't boot a decent system without it. I don't think we're in danger of that: people who don't want systemd don't need it.
You'll know there are too many dependencies on systemd when people who don't want it (Devuan, Slackware, openBSD) can't boot a decent system without it. I don't think we're in danger of that: people who don't want systemd don't need it.
He's actually said that he doesn't think that systemd is that bad. He didn't like the way that they submitted patches initially. He said that he doesn't have a problem with the approach and he said that people make too much of the "unix philosophy" because passing bits of text between programs really hasn't been the way that unix systems have been designed for several decades.
I could see sysvinit as $torvaldsinitsystem because it has been booting linux around the world...
Git did start as a tool, and has been extended, a lot.
The same than the kernel booting was extended across the years to cover usage cases.
If he writes pid 1 code by itself, to get rid of a issue, as he did with the kernel and with git, we will call it the Linus pid 1. But as others said, maybe he doesn't has personally annoying issues with this.
Git did start as a tool, and has been extended, a lot.
The same than the kernel booting was extended across the years to cover usage cases.
If he writes pid 1 code by itself, to get rid of a issue, as he did with the kernel and with git, we will call it the Linus pid 1. But as others said, maybe he doesn't has personally annoying issues with this.
[deleted]
hardly fringe -- it's straight out of the unix wars historical playbook. Every unix vendor tried to make their own conflicting systems in order to promote lock-in. Solaris, AIX, DG/UX, SCO, everyone, all the time. That it's taken so long in the Linux space is pretty amazing, but of course that it's happening is super depressing.
That requires the systems to be proprietary, and, well, conflicting. Systemd isn't proprietary, and with everybody's adoption it's now universal, not conflicting.
I'm not sure where this tendency of Red Had for taking over the ecosystem comes from. The only rational basis for it I can think of is they wanting Linux to stay complex, so they can sell support. But it's way more likely it comes simply by them hiring a big number of developers, and not having enough in-house problems to solve - after that they must lead, not follow (for marketing reasons), so they must push their solution onto everybody.
I'm not sure where this tendency of Red Had for taking over the ecosystem comes from. The only rational basis for it I can think of is they wanting Linux to stay complex, so they can sell support. But it's way more likely it comes simply by them hiring a big number of developers, and not having enough in-house problems to solve - after that they must lead, not follow (for marketing reasons), so they must push their solution onto everybody.
> Systemd isn't proprietary, and with everybody's adoption it's now universal, not conflicting.
Within Linux. Systemd is explicitly anti-portability across Unixes, and encourages dependencies on it that make life increasingly hard for the BSDs, OS X, etc.
So, yeah, if you zoom out a little from Linux, systemd fits right in with the UNIX wars.
Within Linux. Systemd is explicitly anti-portability across Unixes, and encourages dependencies on it that make life increasingly hard for the BSDs, OS X, etc.
So, yeah, if you zoom out a little from Linux, systemd fits right in with the UNIX wars.
Linux won the UNIX wars, by bringing an end to them - yes BSD exists - but in both mindshare, and marketshare Linux beat the rest of them out. Beyond that, sysv was never relevant for BSD - and I don't think many Linux distros went with rc.d either.
So in the end, because of compatibility shims on both sites - and that our software build systems have evolved to support multiple init systems, its largely a moot point.
So in the end, because of compatibility shims on both sites - and that our software build systems have evolved to support multiple init systems, its largely a moot point.
Conway's law
Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
It could be that they both benefit from building complex systems and believe honestly that such systems are the optimal solution from their own perspective. This requires no bad faith or conspiracy theories.
Its simultaneously possible that such a complex solution is sub optimal for other parties.
They are under no obligation to build a solution that is best for other parties and others are under no obligation to adopt or like such solutions.
Its entirely possible for two parties to disagree without either being evil.
Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
It could be that they both benefit from building complex systems and believe honestly that such systems are the optimal solution from their own perspective. This requires no bad faith or conspiracy theories.
Its simultaneously possible that such a complex solution is sub optimal for other parties.
They are under no obligation to build a solution that is best for other parties and others are under no obligation to adopt or like such solutions.
Its entirely possible for two parties to disagree without either being evil.
In regards to this, i ran into a blog posting over at blogs.gnome.org, about Fedora's workstation project. That alone should raise some red flags about mixing roles.
But then i start reading and seeing the guy name others from seemingly unrelated projects, thanking them for their efforts.
But lo and behold, once i start running the bloggers name, and the names he mentions, they all come up as Red Hat employees.
But then i start reading and seeing the guy name others from seemingly unrelated projects, thanking them for their efforts.
But lo and behold, once i start running the bloggers name, and the names he mentions, they all come up as Red Hat employees.
"That requires the systems to be proprietary, and, well, conflicting."
No it doesn't. Different OSS projects already compete with each other in many details of design and implementation. They try to win over users or mindshare instead of dollars. Some with financial backing also have dollars in mind. Even lock-in is approximated by things that many apps depend on but are too big to change without risking a break.
No it doesn't. Different OSS projects already compete with each other in many details of design and implementation. They try to win over users or mindshare instead of dollars. Some with financial backing also have dollars in mind. Even lock-in is approximated by things that many apps depend on but are too big to change without risking a break.
But this kind of competition, or even intent behind a product, is thus not unethical or harmful to the users.
Let systemd try to take over whatever it wants. It is still LGPL licensed, so I can do whatever I want with it as well. Those writing it can do whatever they want - nobody has forced any distro to adopt systemd bseides Red Hat themselves, insofar as it was their project principally so of course their own distro used it.
Arch, Suse, Debian, Ubuntu... all game to use it under consensus. I personally think there is no better outcome than well engineered and linked software seeing uniform adoption to let the ecosystem move on to bigger problems. The degree to which systemd's pervasiveness has enabled the vast simplification and feature richness of so many disparate aspects of development on the platform only reinforces that belief - the ease of writing and shipping service, socket, requires, triggers, timer, mount, etc files. The ubiquitous availability of a session dbus. udev pervasiveness, cgroups already being there and setup, there is so much feature richness systemd gives everyone up the stack to claim shell scripts and grit were better is to say you should never stop reinventing the wheel to build the cart until the wheel is cast from solid gold.
Let systemd try to take over whatever it wants. It is still LGPL licensed, so I can do whatever I want with it as well. Those writing it can do whatever they want - nobody has forced any distro to adopt systemd bseides Red Hat themselves, insofar as it was their project principally so of course their own distro used it.
Arch, Suse, Debian, Ubuntu... all game to use it under consensus. I personally think there is no better outcome than well engineered and linked software seeing uniform adoption to let the ecosystem move on to bigger problems. The degree to which systemd's pervasiveness has enabled the vast simplification and feature richness of so many disparate aspects of development on the platform only reinforces that belief - the ease of writing and shipping service, socket, requires, triggers, timer, mount, etc files. The ubiquitous availability of a session dbus. udev pervasiveness, cgroups already being there and setup, there is so much feature richness systemd gives everyone up the stack to claim shell scripts and grit were better is to say you should never stop reinventing the wheel to build the cart until the wheel is cast from solid gold.
I'm not sure where this tendency of Red Had for taking over the ecosystem comes from.
Because they're willing to fund the work.
Because they're willing to fund the work.
No, it does not need to be proprietary. Instead one need to have control over the commit rights of core repositories.
As for conflicting: i think you have missed server years of conflict, never mind that you can only ever have one process as pid1 on a unix setup.
And if something like your session tracker depends on pid1 being systemd, you get conflict.
As for conflicting: i think you have missed server years of conflict, never mind that you can only ever have one process as pid1 on a unix setup.
And if something like your session tracker depends on pid1 being systemd, you get conflict.
I have to say that it is super fast to boot up with systemd. Maybe 2-3 seconds to boot to my Ubuntu desktop (excluding bios time.) I do use an SSD however.
On embedded devices in the SheevaPlug family, it's a bit slower than the old init, presumably because it's doing a lot more stuff (and the OS is either on slow flash or a slow USB-to-SD card interface). It doesn't seem to scale down to small systems very well. I do like the colors, though.
systemd has boot profiling functionality, you might want to check out which part is slow.
There's always lots of text flying by on the console; it might not be traceable to one single slow part.
Try "systemd-analyze plot >boot.svg" and it will produce a nice svg graph of how much time each step takes.
systemd is slow on my embedded devices booting from flash too.
On slow storage systemd has some problems. Afair you can configure it to not be as parallel. That ought to help.
I could have sworn that i read a notice a year or two ago that they pulled out the readahead code because it had not been maintained in a while and all the devs were using SSDs.
I have a 2-second boot from grub to login with plain-old sysvinit. What's remarkable about systemd? And perhaps more relevant, given that BIOS boot times are still above 10 seconds (and minutes on servers), who cares?
I think the systemd complaints can essentially be reduced to "my init system now knows about cgroups, sockets, dbus, [and other things that didn't used to exist]". I haven't heard anyone offer a replacement that accounts for these features while maintaining "the Unix way".
None of those feature require systemd.
> cgroups
Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect.
> sockets
We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business.
> dbus
Isn't necessary in the init process, though you're free to use it if you wish.
> didn't used to exist
Such as?
> replacement for these features
The replacement in some cases should be "nothing". You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features.
The entire point of this "debate" is that you shouldn't be tying extra features to the init process. There are a wide variety of systems in the Linux ecosystem, and there is no one-size-fits-all solution.
If you want to run a heavyweight, opinionated, monolithic init like systemd, that's fine. If it makes your life easier, that's great. Just remember that other people have different requirements.
> cgroups
Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect.
> sockets
We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business.
> dbus
Isn't necessary in the init process, though you're free to use it if you wish.
> didn't used to exist
Such as?
> replacement for these features
The replacement in some cases should be "nothing". You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features.
The entire point of this "debate" is that you shouldn't be tying extra features to the init process. There are a wide variety of systems in the Linux ecosystem, and there is no one-size-fits-all solution.
If you want to run a heavyweight, opinionated, monolithic init like systemd, that's fine. If it makes your life easier, that's great. Just remember that other people have different requirements.
"foo knows about X, Y, and Z" doesn't mean the same thing as "foo is required for X, Y, and Z".
> > replacement for these features
Did GP edit their comment? The quotes and arguments you're arguing with aren't present in it.
> We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business.
An init system that groks socket activation yields more benefits than just lazy service startup. Services which communicate over a socket can be more loosely coupled, and a service need not be a traditional "forking daemon" for dependent services to start up at the correct time (since , say, the dependency's UNIX domain socket is already created, they can all start in parallel).
edit: I edited the last paragraph in 20 minutes after posting.
> > replacement for these features
Did GP edit their comment? The quotes and arguments you're arguing with aren't present in it.
> We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business.
An init system that groks socket activation yields more benefits than just lazy service startup. Services which communicate over a socket can be more loosely coupled, and a service need not be a traditional "forking daemon" for dependent services to start up at the correct time (since , say, the dependency's UNIX domain socket is already created, they can all start in parallel).
edit: I edited the last paragraph in 20 minutes after posting.
> Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect.
That's not what it's about. The point of cgroups integration in systemd is that it allows systemd to precisely track the processes started under it, which means that e.g. applications where things like double-forking or similar happens can still be completely stopped by systemd even if the parent process des.
> You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features.
They are to me. They massively improves things vs. sysvinit.
> The entire point of this "debate" is that you shouldn't be tying extra features to the init process.
The entire starting point for systemd is that traditional sysvinit is woefully lacking in the functionality required to build reliable systems. And when you start trying to cobble together something on top of it, it quickly becomes clear that it is not easy.
E.g. try to build a reliable process manager outside of pid 1. You still need process restarting functionality in pid 1 for when your process manager dies. What if it fails to restart? How are you going to log those failures reliably? You end up duplicating a lot of functionality of a process manager in pid 1 if you want a reliable system even if you run a separate process manager outside of pid 1.
There are parts of the systemd design I don't agree with, and I think they'd benefit from splitting out various components from the project, not least for "political" reasons. But the design for the core parts of systemd-the-init-system largely follow on from a very limited set of core requirements of being able to reliably start, stop and keep services running and reliably log data from them.
These are requirements that sysvinit basically throws it hands up at and says "not my table", while by owning pid 1 they make it basically impossible to meet them.
That's not what it's about. The point of cgroups integration in systemd is that it allows systemd to precisely track the processes started under it, which means that e.g. applications where things like double-forking or similar happens can still be completely stopped by systemd even if the parent process des.
> You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features.
They are to me. They massively improves things vs. sysvinit.
> The entire point of this "debate" is that you shouldn't be tying extra features to the init process.
The entire starting point for systemd is that traditional sysvinit is woefully lacking in the functionality required to build reliable systems. And when you start trying to cobble together something on top of it, it quickly becomes clear that it is not easy.
E.g. try to build a reliable process manager outside of pid 1. You still need process restarting functionality in pid 1 for when your process manager dies. What if it fails to restart? How are you going to log those failures reliably? You end up duplicating a lot of functionality of a process manager in pid 1 if you want a reliable system even if you run a separate process manager outside of pid 1.
There are parts of the systemd design I don't agree with, and I think they'd benefit from splitting out various components from the project, not least for "political" reasons. But the design for the core parts of systemd-the-init-system largely follow on from a very limited set of core requirements of being able to reliably start, stop and keep services running and reliably log data from them.
These are requirements that sysvinit basically throws it hands up at and says "not my table", while by owning pid 1 they make it basically impossible to meet them.
> The point of cgroups integration in systemd
I know why systemd uses cgroups. I was addressing the myth that systemd is required to use cgroups.
> They are to me.
That's nice. You should use systemd if its features satisfy your requirements better than the other options.
Other people have different requirements. Is this concept difficult to understand? We don't want the same features, for a variety of reasons. Disagreement is fine, but systemd advocates often seem to want a monoculture.
> the functionality required to build reliable systems
That's your opinion, which you're entitled to. I disagree, as I've never had problems like you're describing. I value stability a very strongly, so I consider the methods that worked fine over the past 20+ years.
> requirements
That's the framing I was talking about. There is more than one way to design a stable system, and your requirement list is only one of those methods. Some of those requirements I consider misfeatures that cause problems, but it's fine if you disagree.
> impossible to meet them
Then use systemd or some other solution that solves your needs. Is it so hard to understand that we can choose different software?
I know why systemd uses cgroups. I was addressing the myth that systemd is required to use cgroups.
> They are to me.
That's nice. You should use systemd if its features satisfy your requirements better than the other options.
Other people have different requirements. Is this concept difficult to understand? We don't want the same features, for a variety of reasons. Disagreement is fine, but systemd advocates often seem to want a monoculture.
> the functionality required to build reliable systems
That's your opinion, which you're entitled to. I disagree, as I've never had problems like you're describing. I value stability a very strongly, so I consider the methods that worked fine over the past 20+ years.
> requirements
That's the framing I was talking about. There is more than one way to design a stable system, and your requirement list is only one of those methods. Some of those requirements I consider misfeatures that cause problems, but it's fine if you disagree.
> impossible to meet them
Then use systemd or some other solution that solves your needs. Is it so hard to understand that we can choose different software?
I'm not arguing against your ability to pick something else.
What I see, however, in most of the opposition to systemd is that most who criticise it don't understand these design considerations and often aren't even aware of the problems involved.
This is why they keep coming up. If most people designed systems that took care of these things in other ways, it wouldn't be so much of an issue. But most people don't. E.g. the fact that most Linux distros for the longest time kept running critical system services straight from init scripts with no process manager or other restart logic is a good example.
What I see, however, in most of the opposition to systemd is that most who criticise it don't understand these design considerations and often aren't even aware of the problems involved.
This is why they keep coming up. If most people designed systems that took care of these things in other ways, it wouldn't be so much of an issue. But most people don't. E.g. the fact that most Linux distros for the longest time kept running critical system services straight from init scripts with no process manager or other restart logic is a good example.
And oddly enough those "services" (or daemons as they used to be called, wonder why that changed) could run for years if not decades without a hitch.
But now everything seems to be a case of web monkey balls of yarn that is no better than Windows in staying upright.
Its like i can reuse old UF comics, only replace Murky's love for Windows with Ubuntu or some such.
But now everything seems to be a case of web monkey balls of yarn that is no better than Windows in staying upright.
Its like i can reuse old UF comics, only replace Murky's love for Windows with Ubuntu or some such.
Downvote brigades on factually correct posts you happen not to agree with aren't cricket.
Except that they are on this site and have been so I quit using a single account to ever post anything. If you are actually a contrarian good luck ever even getting to the point where you can downvote other posts.
I do all right. State my piece, supply evidence, and avoid idiotic fights. There's always someone wrong on the Internet. #386.
Speaking for your opposition whilst misrepresenting their arguments is very dirty pool.
There are numerous long-term expert users and developers of Linux who've spoken against systemd, its design, its behavior, and its developers. Including Linus Torvalds, Alan Cox, Ted T'so, and Patrick Volkerding
(That's the original developer of Linux, the long-time second in command, the lead filesystem developer, and the Slackware distro's maintainer -- the oldest extant linux distro.)
Mark Shuttleworth, Eric Raymond, and Ian Jackson are notable other critics.
For actual arguments against systemd:
http://without-systemd.org/wiki/index.php/Arguments_against_...
https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and...
The laptop vs server divide:
http://www.infoworld.com/article/2837182/linux/back-into-lin...
Bad design and bad attitude. One or the other might be survivable. Both are likely not.
http://www.infoworld.com/article/2608798/data-center/systemd...
Uselessd's observations on misrepresentations by systemd advocates:
http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Five troubles:
http://www.draketo.de/light/english/top-5-systemd-troubles
LWN on Debian's debates: https://lwn.net/Articles/452865/
Wikipedia on Systemd's controversy: https://en.m.wikipedia.org/wiki/Systemd#History_and_controve...
There are numerous long-term expert users and developers of Linux who've spoken against systemd, its design, its behavior, and its developers. Including Linus Torvalds, Alan Cox, Ted T'so, and Patrick Volkerding
(That's the original developer of Linux, the long-time second in command, the lead filesystem developer, and the Slackware distro's maintainer -- the oldest extant linux distro.)
Mark Shuttleworth, Eric Raymond, and Ian Jackson are notable other critics.
For actual arguments against systemd:
http://without-systemd.org/wiki/index.php/Arguments_against_...
https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and...
The laptop vs server divide:
http://www.infoworld.com/article/2837182/linux/back-into-lin...
Bad design and bad attitude. One or the other might be survivable. Both are likely not.
http://www.infoworld.com/article/2608798/data-center/systemd...
Uselessd's observations on misrepresentations by systemd advocates:
http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Five troubles:
http://www.draketo.de/light/english/top-5-systemd-troubles
LWN on Debian's debates: https://lwn.net/Articles/452865/
Wikipedia on Systemd's controversy: https://en.m.wikipedia.org/wiki/Systemd#History_and_controve...
Could you point to where Linus said he doesn't like the design of systemd? AFAIK he's only disliked the binary logging (perhaps among a few other small things) but he liked it overall.
> I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues. [1]
or
> I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
> Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
> Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [2]
Both a quick Google away. To sum it up: Linus is okay with systemd. He just doesn't like its maintainers because they're straight up primadonnas. [3]
1: http://www.zdnet.com/article/linus-torvalds-and-others-on-li...
2: https://linux.slashdot.org/story/15/06/30/0058243/interviews...
3: http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dus...
or
> I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
> Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
> Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [2]
Both a quick Google away. To sum it up: Linus is okay with systemd. He just doesn't like its maintainers because they're straight up primadonnas. [3]
1: http://www.zdnet.com/article/linus-torvalds-and-others-on-li...
2: https://linux.slashdot.org/story/15/06/30/0058243/interviews...
3: http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dus...
Their latest may well be that when logind do not find a functioning journald it will dump its output into /dev/kmsg, potentially swamping vital kernel output.
https://plus.google.com/+StevenRostedt/posts/RCCcWG5A5Lb
https://plus.google.com/+StevenRostedt/posts/RCCcWG5A5Lb
Those are the ones I found too, but the previous parent says that Linus has spoken against systemd which is new to me.
I remember seeing a video where he said he didn't care one way or the other about the technical merits and that it seemed good enough, but he did have serious concerns about the attitude of the developers about other people's technical issues when using it.
One of the bigger arguments is also "it only works on Linux, what about BSDs, OS X, etc.?"
> One of the bigger arguments is also "it only works on Linux, what about BSDs, OS X, etc.?"
In what way is that a "big argument"? BSD has their own rc-thing (not sysv init), OS X has launchd (not sysv init, shares many similarities with systemd actually, such as socket activation), Solaris has SMF (again, not sysv init), etc.
Apart from a bunch of non-mainstream Linux distros sticking with sysv init, who else is actually using it?
In what way is that a "big argument"? BSD has their own rc-thing (not sysv init), OS X has launchd (not sysv init, shares many similarities with systemd actually, such as socket activation), Solaris has SMF (again, not sysv init), etc.
Apart from a bunch of non-mainstream Linux distros sticking with sysv init, who else is actually using it?
No one. That's why this is such a stupid argument. BSD and OSX and Solaris and other Unixes have been doing their own thing for ages, and none of them worried about being compatible with other competing Unixes. But somehow Linux distros are wrong to do their own thing (collectively), and should be worried about *BSD and OSX? It makes no sense.
... which is food for thought for the Ubuntu world, now it has Ubuntu on BSD and Ubuntu on Windows NT in addition to Ubuntu on Linux.
* https://news.ycombinator.com/item?id=11415985
* https://news.ycombinator.com/item?id=11416376
* https://news.ycombinator.com/item?id=11326457
* https://news.ycombinator.com/item?id=11415985
* https://news.ycombinator.com/item?id=11416376
* https://news.ycombinator.com/item?id=11326457
Ubuntu and Debian. I _think_ Gentoo might fall under this as well, though I'd have to check.
But yes.
But yes.
The choice isn't binary: sysvinit or systemd. There is a third way. I'm not much of a sysadmin, but I'm intrigued when I read of daemontools and its ilk.
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dae...
http://blog.darknedgy.net/technology/2015/09/05/0/
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dae...
http://blog.darknedgy.net/technology/2015/09/05/0/
There's also http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar... - a daemontools compatible, partially-systemd compatible init system.
There are many more than 3 init systems. There are tens of them.
I meant three families, but you still may be right.
Where does upstart stand in this? That's what I've used so far.
It is dead and gone, Canonical/Ubuntu abandoned it after Debian chose systemd and then Ubuntu did too.
There are dozens of us!!
[deleted]
>I still have serious misgivings
I guess that kinda tells us more than anything else he said.
I guess that kinda tells us more than anything else he said.
You cut the quote to change the meaning.
"Although I still have serious misgivings about the systemd upstream’s attitude, I’ve got to say I find the system rather refreshing and useful in practice."
"Although I still have serious misgivings about the systemd upstream’s attitude, I’ve got to say I find the system rather refreshing and useful in practice."
There are misgivings none-the-less. A new system being "refreshing" is not a reason to use it. "Useful" is hardly a ringing endorsement.
What disturbs me the most is that systemd takes Linux farther away from being a Unix-like system. Linux is now "Linux" and incompatible with anything else.
What disturbs me the most is that systemd takes Linux farther away from being a Unix-like system. Linux is now "Linux" and incompatible with anything else.
I didn't really know anything about init systems until 2014 (so I all but missed the systemd wars) when I found myself in need of process synchronization and supervision on various platforms.
My task was pretty straightforward: I had a group of processes that need to start in a certain order, restart if they die, run as a non-root user, and write logs somewhere. I needed to support RHEL 5, 6, and 7, which all use different init systems (sysvinit, upstart, and systemd). I worked with all of them and also experimented with alternatives (runit, s6, Supervisor).
For my task systemd was a pleasure to work with compared to the others. There was a bit of a learning curve, but once I mapped out what I needed to do the solution was obvious.
I found upstart to be almost good, but the version that ships with RHEL 6 is lacking compared to the later versions that came with Ubuntu. The Python-based Supervisor was surprisingly good. I sort of saw why some people might like s6, but runit's charm was lost on me.
sysvinit was by far the worst. I wound up using sysvinit to hand off to Supervisor in order to not spend my life worrying about the number of forks and pidfile locations.
I can't speak to systemd's shortcomings and perceived hegemony in other areas, but when it comes to acting like an init system it is miles ahead of everything else.
My task was pretty straightforward: I had a group of processes that need to start in a certain order, restart if they die, run as a non-root user, and write logs somewhere. I needed to support RHEL 5, 6, and 7, which all use different init systems (sysvinit, upstart, and systemd). I worked with all of them and also experimented with alternatives (runit, s6, Supervisor).
For my task systemd was a pleasure to work with compared to the others. There was a bit of a learning curve, but once I mapped out what I needed to do the solution was obvious.
I found upstart to be almost good, but the version that ships with RHEL 6 is lacking compared to the later versions that came with Ubuntu. The Python-based Supervisor was surprisingly good. I sort of saw why some people might like s6, but runit's charm was lost on me.
sysvinit was by far the worst. I wound up using sysvinit to hand off to Supervisor in order to not spend my life worrying about the number of forks and pidfile locations.
I can't speak to systemd's shortcomings and perceived hegemony in other areas, but when it comes to acting like an init system it is miles ahead of everything else.
One "interesting" tidbit about systemd is that the init part will keel over if dbus goes down, and if pid1 keels over you are looking at a kernel panic...
I was bitten by this once. A typo in dbus configuration rendered my machine unbootable.
I wonder if issues like this were part of the reason the release of kdbus (dbus as a kernel module) was delayed.
kdbus is mainly delayed because the kernel devs are unconvinced. In the last thread I read (which was likely over a year ago), there were architectural issues with the design that nobody on the kdbus side was willing/able to fix or explain.
I thought one of the main kdbus devs was gregkh (one of the most senior Linux kernel maintainers), is that not the case? I did hear that there was due to be a redesign, but not sure what the issues were.
I'm not sure if GregKH is involved in the actual implementation; he did step in to "foster" this project through the inclusion process, but several other maintainers were outspokenly unhappy about the review process and lack of follow-up ([1] and [2]).
The current kdbus implementation has been withdrawn from rawhide [3], with no indication when it will be back. The most recent response from Linus I've been able to find is [4], roughly half a year before the rawhide removal.
[1] https://lwn.net/Articles/640617/
[2] http://thread.gmane.org/gmane.linux.kernel/1981923/focus=198...
[3] https://lkml.org/lkml/2015/11/8/245
[4] http://article.gmane.org/gmane.linux.kernel/1982561
The current kdbus implementation has been withdrawn from rawhide [3], with no indication when it will be back. The most recent response from Linus I've been able to find is [4], roughly half a year before the rawhide removal.
[1] https://lwn.net/Articles/640617/
[2] http://thread.gmane.org/gmane.linux.kernel/1981923/focus=198...
[3] https://lkml.org/lkml/2015/11/8/245
[4] http://article.gmane.org/gmane.linux.kernel/1982561
I believe this is the redesign: https://github.com/bus1/bus1
EDIT: Replaced with better link. (Old link: http://www.bus1.org/index.html )
EDIT: Replaced with better link. (Old link: http://www.bus1.org/index.html )
https://news.ycombinator.com/item?id=11639659
Found this regarding programming languages (and JS in particular) a bit interesting in the middle of the whole systemd debate, as i wonder if it can be applied to unix as well.
This in that unix have from the early days been made up of loosely coupled parts. This then allowed new parts to be introduced, tested, and either adopted widely or discarded as seen fit. Maybe even adopted in some areas but ignored in others. But you rarely ran into deep dependency chains.
Systemd on the other hand is tightly coupled, continually sprouting new stuff, and foisted on the world via deep dependencies.
Found this regarding programming languages (and JS in particular) a bit interesting in the middle of the whole systemd debate, as i wonder if it can be applied to unix as well.
This in that unix have from the early days been made up of loosely coupled parts. This then allowed new parts to be introduced, tested, and either adopted widely or discarded as seen fit. Maybe even adopted in some areas but ignored in others. But you rarely ran into deep dependency chains.
Systemd on the other hand is tightly coupled, continually sprouting new stuff, and foisted on the world via deep dependencies.
> Systemd on the other hand is tightly coupled
Not really. All its various components are loosely coupled over DBus, and most are entirely optional. There's no technical reason why people can't e.g. implement journald's API in syslog. Or replace the various userspace *ctls (timedatectl, hostnamectl, …), or reimplement logind on top of some BSD (already done, actually), …
Not really. All its various components are loosely coupled over DBus, and most are entirely optional. There's no technical reason why people can't e.g. implement journald's API in syslog. Or replace the various userspace *ctls (timedatectl, hostnamectl, …), or reimplement logind on top of some BSD (already done, actually), …
You seem to be confusing the interface between systemd components and third parties, with internal interfaces.
The latter are expressly non-documented, and non-stable, to allow the systemd devs to change them as they see fit.
As for logind on BSD, got a link? Last i recall they were struggling because it was a sprawling and moving target (Consolekit2 is also having that problem). One example is that recently logind took over much fo the job upower used to do, with upower now being a compatibility wrapper around logind.
Oh btw, dbus is massively more opaque that being able to run a command, look at the output, and then pipe that to another with the proper flags and such.
The latter are expressly non-documented, and non-stable, to allow the systemd devs to change them as they see fit.
As for logind on BSD, got a link? Last i recall they were struggling because it was a sprawling and moving target (Consolekit2 is also having that problem). One example is that recently logind took over much fo the job upower used to do, with upower now being a compatibility wrapper around logind.
Oh btw, dbus is massively more opaque that being able to run a command, look at the output, and then pipe that to another with the proper flags and such.
> reimplement logind on top of some BSD (already done, actually)
If you're thinking of SystemBSD, you are incorrect. There has been no publicly visible change on that front in the past year.
* https://news.ycombinator.com/item?id=10176275
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
If you're thinking of SystemBSD, you are incorrect. There has been no publicly visible change on that front in the past year.
* https://news.ycombinator.com/item?id=10176275
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
Dude, there's literally nothing you can say that will change people's mind on this subject. It has long since crossed into some kind of identity subject.
> I was debugging the boot on a server recently. It mounts a bunch of NFS filesystems
Don't do that. It's a bag of hurt.
(Still sore about the hours that workstations with not-working-fs mounts spent waiting for each other on boot after power failures, ages ago. Nevermore.)
Don't do that. It's a bag of hurt.
(Still sore about the hours that workstations with not-working-fs mounts spent waiting for each other on boot after power failures, ages ago. Nevermore.)
[deleted]
So you just don't use remote filesystems? That's a solution!
Honestly, whenever the init system is configured correctly, you don't run into these problems all ops know a story about. It helps that systemd makes it easier to configure dependencies so that only the units depending on remote fs stall when it is unavailable.
Honestly, whenever the init system is configured correctly, you don't run into these problems all ops know a story about. It helps that systemd makes it easier to configure dependencies so that only the units depending on remote fs stall when it is unavailable.
> So you just don't use remote filesystems? That's a solution!
No, you mount them with autofs, of course.
No, you mount them with autofs, of course.
I found out about autofs when I was trying to figure out some SMB issues while mounting NAS shares on a media server.
It was so ridiculously easy to set up. All of the "copy and paste" newbie answers always involve modifying fstab and there are always issues on boot, but autofs just works. It makes me wonder why it's not recommended as often.
It was so ridiculously easy to set up. All of the "copy and paste" newbie answers always involve modifying fstab and there are always issues on boot, but autofs just works. It makes me wonder why it's not recommended as often.
autofs is great, combined with NFS4 and FreeIPA it's even not a total pain in the butt to configure on a whole farm of servers (having my home directory easily available with my ZSH configuration from every system I log into is great.)
One time I was writing this long story in a text editor that crashed so I stopped writing. Nevermore.
I find myself doing this frequently
> systemctl status someservice
> systemctl stop someservice
> systemctl edit someservice
> systemctl daemon-reload
> systemctl start someservice
> systemctl status someservice
> systemctl enable someservice
Why make the operation the middle parameter? I understand that "systemctl start foo" more closely resembles the English sentence, "SystemD, please start the foo service", but I couldn't give two shits about that, and it's a dumb design decision. Any time that I am entering a systemctl command, I'm probably entering a series of 3 or more of them, and they're probably all related to the same service.
Instead of being able to press <Up Arrow>, <C-Backspace>, and type my operation, I'm instead having to position my cursor to the second argument. It's a mess!