EmanueleAina

> Except that rc.subr is shell scripting alone.

Again, "read the source" is a sad answer. I can read systemd C sources too, but given that it comes with proper documentation there should be no need to do it.

My point is that either one has to get some domain-specific knowledge or they have to reverse engineer some code. Given that I believe that the second one is a bad choice (people will rely on the implementation rather than on the intended interface) if you have to get some domain-specific knowledge it does not matter if you're using posix sh syntax or a INI-style one.

> your only goal is to have terse daemon configuration with a minimum of boilerplate, you can already do this with shell scripts

Literally nobody ever claimed that systemd "only goal" is to have terse daemon configuration. It was one of the many goals. Sure, it could have been done with posix sh syntax, nobody disputes that, but since backward compatibility was being dealt in other ways (using LSB header), switching to a INI-style format seems a good choice if one wants to enforce a declarative-only style.

And if someone claims that init script are needlessy complex and redundant it is because that's the situation of most distributions before the switch to systemd. Switching to OpenRC would probably have fixed that aspect, but systemd solves many more problems that distributors faced and OpenRC did not address, faring more positively in a costs/benefits analysis.

> the systemd folks assumed that they were the center of the universe and decided "well fuck the kernel, we're going to use the 'debug' flag for ourselves, everything else be damned"

Note that even Linus said that "parsing [the 'debug' and 'quiet' flag] and doing something sane with them is not a bug, it's a feature". So the issue revolved on what people believe is "sane", not about userspace using kernel bootparams (systemd still does and Linus is ok with it). The systemd folks argued that the kernel should not affected if something broke and started throwing too many messages at it during early boot (indeed, the kernel was fixed to rate limit in those cases). The kernel people instead said that it's not ok for userspace to flood the kernel, not even in broken setups (indeed, systemd was fixed to stop sending messages to dmesg as soon as journald is up).

I believe that sending emails here and there to ask "it's ok to do that?" would not work. LKML is already high traffic as is, such messages would just get ignored until things break.

Interesting read, thanks!

However I would not characterize that as "Poettering completely misunderstanding a perfectly valid use of su".

It seems a quite complex issue about a workflow that is only half-working even without systemd. A systemd patch has been committed that fixes the most blatant error, but of course it doesn't solve all problems since most of them existed before systemd.

> It's a parameter passed to the kernel.

Just like "quiet", which is totally meant to affect userspace programs.

> It's a ridiculous clunky hack that stinks of large company coding practice: what they actually needed was a way to pass arguments to systemd itself.

Having a global "debug" knob would have been useful when one does not know if the problme lies in the ramdisk, plymouth, systemd, udev, lvm, whatever. Having a systemd-specific flag defeats that purpose.

> The logical way to do that in an OS that has to be portable and flexible is to implement a mechanism for the kernel to pass some of the arguments it receives to init. Because there's no reason to assume that init is going to be systemd, that there's going to be a procfs ready for it so as to be able to read the kernel's parameters, or that the init process can read it for that matter.

The kernel command line, readable from procfs, has been used for this purpose (see the "quiet" flag) for a very long time now.

> what do you mean "this can have unwanted side-effects", it works perfectly fine on my system.

It worked perfectly on every system until the kernel bug triggered the feedback loop.

> The fact that the developers (again, it's a known pattern) decided to play the PR game and call it "expected behaviour" doesn't make it less of a bug.

It was "expected behaviour" in the presence of a kernel bug, which is why it was obviously not generally "expected behaviour" as you seem to imply.

Yep, my point is that knowing shell scripting alone is no longer enough and it's not different than running `man systemd.service`, only that you're keeping the weirdness of the shell language just to set a couple of variables.

Thanks, that wasn't the point. What I was trying to say is that if you use those helpers you're looking up stuff in a man page anyway, so knowing shell scripting isn't enough any longer.

My personal opinion is that having a simple, INI-derived language is better than keeping the weirdness of the shell language just to assign a couple of variables (and you can still launch shell scripts from units anyway).

I mean, I know that it sets a variable, I can't even guess what are the effect of setting that variable.

And "look at the source" is a sad answer, no matter if the source is a shell script or C program.

The point is that with your example you need domain knowledge, knowing bash is not enough: what does the pexp assignment do, what rc_reload=NO means, should flags be specified in the daemon variable or that's meant to only contain the binary, does that path be full or it takes in consideration a standard PATH?

And now you got two things to know: the bash (or even strictly posix sh) language (which, admittedly, isn't the best one in the world) and the domain specific functions/variables.

This isn't much different than with systemd: the language is much more simple and far less surprising being INI-like (the same as .desktop files), and it's basically just setting a list of rather well documented variables.

> A -> B -> C -> D. Easy.

Oh, sure, sequentially starting up a fixed list of services is probably easier with sysvinit, given that's the only thing it does.

With systemd you probably want to set Requires=foo and After=foo in bar.service to have foo running before bar. It does not seem overly complex, or you meant something else?

> I must create 10 different unit files, and then create a bunch of different dependencies (A depends on B and C, B depends only on D, can C then start at same time as D?, etc).

Wouldn't you create 10 different init script for sysvinit, each with its own LSB header listing the dependencies such that tools like Debian's insserv could correctly schedule them?

I'm quite sure that it's far easier to express complex dependencies with systemd than with sysvinit, if that's your concern.

Correct me if I'm wrong, your dependencies could be handled like the following:

[A] Requires=B Requires=C

[B] Requires=D

If A needs B to be running before A even starts (ie. they cannot be run in parallel) just add After=B to A. With sysvinit I'm not sure if there's a way to say that A needs B but that they can be started in parallel.

I don't get your question "can C then start at same time as D": if they do not depend on each other, I don't see the problem. If they have a dependency, just add After= to the one that needs to be launched later in the process. If you don't know, add After=C to D and you've got a slightly slower but sequential boot as with sysvinit.

> That's... not true. From the first line of the hostname manpage: "Hostname is used to display the system's DNS name, and to display or set its hostname or NIS domain name."

Oh, indeed, sorry. I then guess `hostnamectl` only provides notifications and some extra info on top what `hostname` already does.

> If I lived in a blue sky world, where I was fresh installing one new server with a simple set of services that I had built in systemd, I think I be quite happy with it. The problem is that I have thousands of servers, and a decade or more of accumulated infrastructure that relies on those traditional tools. Then systemd comes barging in and breaks a bunch of stuff, and that is frustrating. I'm not saying I hate systemd, in fact I agree that many of the new tools are quite nice. But it's kind of like the loud hipster that shows up at your party and starts talking shit about the music you are playing, and making fun of your choice in beer. Maybe my music does suck, and maybe these clothes aren't cool anymore, but we were sitting around having a fine time until he came around.

I totally understand your concerns. I guess you don't have many options: you can stick with sysvinit for a while (eg. Debian still officially has full support for it) and in the meantime start making sure your scripts run fine with the LSB compatibility support in systemd (if you're just starting services they should work transparently with no effort).

But consider that in any case, staying with sysvinit has never been an option: during the Debian debate, the contenders for the default were systemd and Upstart, sysvinit has always been kept only as the baseline to test compatibility.

With that in mind, the LSB support in Upstart (and in every other contender) is far less mature than the one in systemd. As the incredibly smooth migration done by the Debian systemd team proves, systemd has the best compatibility support of the pack.

(I mention Debian as that's what I use and for the fact that the systemd maintainers poured a big deal of effort to provide the best systemd/sysvinit compatibility)

Honestly I find that a single global "debug" option would have been useful, instead of having to know which component (the kernel, the ramdisk, sysvinit, sysv-rc, systemd, upstart, udev, whatever) is at fault.

Unfortunately such mechanism introduced a feedback loop in the presence of a bug in the kernel. I understand that it would be difficult for the kernel to guard from such loops, but my sincere impression is that they threw out the the baby with the bathwater.

It worked before, it stopped after a change in the kernel, another change made the problem disappear: the root of the problem was definitely a bug in the kernel.

That said, it's perfectly fine for the kernel developers to clarify that a flag is for their own exclusive use, and indeed it seems that this is how things ended up. Note that there are multiple userspace applications parsing the flags on the kernel command line: the most striking example when discussing the "debug" flag is the "quiet" flag.

Never heard about it, is there any link with more details?

> Complex needs are better solved with source code rather than special blobs of $system.

Arguably, reinventing multiple complex wheels is often a not particularly good choice.

So either you're implementing something really novel in your init script (which does not sound like the best place for it) or it's something that may benefit from a single, shared and tested implementation.

And, again, you can still fallback to LSB shell scripts if you really need something incredibly special: my point was that, bloat notwithstanding, you don't lose any feature but gain many.

Are you seriously saying that most distribution maintainers were happy with sysvinit?

For what is worth, all the Debian maintainers I know, even those who are not systemd supporters, felt that sysvinit had to go in a way or the other (eg. during the default init debate the options were systemd and Upstart, sysvint was doomed to be replaced and only kept as a compatibility option in any case.)

Why is resolved feature-creep? It's rather nice to have working name resolution out of the box when coupling it with networkd and firing up a container.

I mean, it's not my standard usecase in this moment of my life, but I see how it can be useful.

(Also, your last link reports that "This bug is for livecd-tools which has been fixed", I don't know what's the point you're trying to make.)

The per-unit cgroup and the ability to kill it is rather nice too, without delving in the container-related features where the systemd server-side support really shines.

Many systemd features are explicitly tailored for server workload (eg. resource management), and a particular effort is being put over container-based deployments.

CoreOS has been quite successful in basing their own infrastructure on systemd and with rkt they are moving to use systemd even more.

> My deadline for almost all work I do is "yesterday".

Having more or less worn both hats, it's exactly the same for developers. :)

> but software developers tend to forget that software is just a tool, and sysadmins use it like a tool. They just want to get in, get out, and move on to the next problem

Which is exactly why developers don't get to write any documentation other than the bare minimum: software for the client is just a tool, once it is running they want developers to move on to the next problem, not wasting time on any additional documentation (which, arguably, is not strictly a developer task, more a QA one).

If your needs are simple, the resulting unit file is trivial and you can basically copy and paste from any example without looking at any documentation.

If your needs are complex, you have better chance by mixing different options in the completely declarative syntax of systemd than mixing shell snippets from different scripts using different styles.

In any case systemd happily launches LSB-compatible init scripts, you literally don't lose anything.

Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes).

Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.

> The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files

How that's different from sysvinit?

> The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary.

`journalctl` prints plain text on its stdout, so you can think of it as a glorified `cat` if you don't want to use its extra features. On the contrary, if one needs its extra features on plain text log files one usually resolves to using fragile parsing hacks.

> The venerable "hostname" command is now "hostnamectl" because it must go through systemd

They do different things, `hostname` only reads the current hostname. `hostnamectl` is able to set the hostname, standardizing what used to be a per-distribution custom mechanism. Despite being shipped with systemd (to make sure everyone can rely on it) it doesn't actually depend on systemd and in no way goes through it.

> They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot.

`chroot`'s purpose has never been the ability to run an init system inside it, no matter if it is sysvinit or systemd. On the other hand `systemd-nspawn` creates isolated containers, I'd be surprised you can't run sysvinit inside it.

Again, you're comparing apples to whole orange trees as the systemd utilities do much more than the traditional ones you mentioned.

Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either.

One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.

You can still use plain shell-based LSB-compliant init scripts just fine, which is what Debian is still doing as they didn't want to have flag days like all the other distributions who switched.

I don't see why you should feel homeless.

I don't think it's really fair to compare writing unit files to being able to program in shell.

True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented.

And for sure, these options are immensely more reusable when writing a new unit file than mixing and matching shell snippets taken from different init script using different styles and conventions.

(Not to mention how subtly tricky programming in shell is even when you're doing trivial things, see http://www.dwheeler.com/essays/filenames-in-shell.html )

As I see it, unless you can guarantee that you give zero false positives (which, knowing how certain users compose their mail, is arguably impossible) you still have to do it.

Also I suppose that the false positive/negative rate can only be given on a well defined corpus, I'm not sure there is one that is a good representation of the current and future spam trends, so in the end giving those numbers could be very misleading.

Again, I never assumed that because somebody is interested in a woman they just want her body. To the contrary, I have no reason to believe it, and I assume we're discussion honest interest here.

> Who would it be OK for an investor to date?

Anyone who's not asking them an investment, which I guess still leaves plenty of options. It's a conflict of interest issue: the entrepreneur will likely consider the possible consequences on the investment outcome of their response. I would really avoid asking someone out for a data when I'm in a position of power in their regard, as I'd prefer that whoever I'm asking out is free to decide without fear of consequences.

I'm not saying that nobody can ask someone out from a position of power: I'm saying that it requires a lot of extra care, as I guess it would only be ok after you get to know each other really well and there have been multiple blatant signs of interest from the other party.

People get called unfunny names regardless they actually have sex with someone.

And no, I'm not assuming that men are incapable of being genuinely interested in a woman. To the contrary, I have no reason to think otherwise. It's just that a funding meeting is not really the appropriate venue to express such interest, just like it's better to wait until one has reached the toilet before expelling fluids in excess.

I already mentioned some of relevant points in the comment you replied to:

1) compartimentalized, not a big, global dumping ground 2) same builders network as unstable/testing 3) no need for a reupload to push to unstable/testing

Qt, LibreOffice, OpenStack, Linux itself, WebKit, GStreamer, Wayland just to name a few have both paid and freetime contributions (often from the same people too).

Neil works for Collabora, we contribute to quite a few projects in our paid time. ;)

The plan for Debian PPAs is for them to be quite different than the ones from Ubuntu, they will be available only for those that already have upload privileges. They will be a sort of compartimentalized experimental, with no different builders network and no need for a reupload to push to unstable/testing.