I cringe whenever I read anything that mentions "libsystemd". I always think of a quote from one of the BSD devs (in a really great youtube interview linked somewhere in one part of this thread), where he says "If the name of your library is lib<my-daemon-name> you're doing it wrong". Hahah...Amen to that.

The problem is that the configuration parser as shipped disagrees with the common understanding of the configuration file by end users.

I agree with you! I wanted to mean that the developers of systemd could have cooperated with the developers of the software involved in the problem.
Thus, a suitable solution would have been proposed and users could have apprehended the functioning of systemd services.

Naib wrote:

more bugs, more locks

Their communication should be more conciliatory. However, GitHub seems to be their bug tracking system: "editorial" criteria are tightened in bug reports.

On their mailing list, someone has opened the discussion about the user issue discussed in this thread.

When new configuration options are added, the same unit file can
almost always be used with older systemd, and it'll just warn & ignore
the parts it doesn't understand.

First i was thinking: WTF anyone would care about new options and unit reject by an older buggy systemd?
But on second thinking: it would allow them to break configurations "abi" at will too ; and an unit for systemd v1000 is working with any systemd <1000 because they will just ignore new options they aren't aware of ; and the compatibility they are wishing to keep is that : having a newer unit able to be run under an old systemd, just to remove any need to made versioned unit.

So they are marking this as notabug, because if systemd use the only safe and logical choice to refuse to run an unit with something in it that is not know by your systemd, it would be reject and the unit would fail to work.
Meaning that if anyone is making a unit for a specific systemd version using a keyword this version and newer handle, all previous systemd would fail to work with it.

LOL like if bash 4 would run specific bash 4 command in a script and bash 3 and below will just ignore them "for compatibility"
What a broken design!
In this sense, it really seems not a bug, but a wanted behaviour.

LOL like if bash 4 would run specific bash 4 command in a script and bash 3 and below will just ignore them "for compatibility"
What a broken design!
In this sense, it really seems not a bug, but a wanted behaviour.

This makes the most sense when you have a developer using newer packages than their users, who are on Debian, Ubuntu, etc. Unfortunately there are far better ways to do it than the way they have chosen, and an implementation that isn't a bug would probably avoid default values that most people do not want.

When new configuration options are added, the same unit file can
almost always be used with older systemd, and it'll just warn & ignore
the parts it doesn't understand.

First i was thinking: WTF anyone would care about new options and unit reject by an older buggy systemd?
But on second thinking: it would allow them to break configurations "abi" at will too ; and an unit for systemd v1000 is working with any systemd <1000 because they will just ignore new options they aren't aware of ; and the compatibility they are wishing to keep is that : having a newer unit able to be run under an old systemd, just to remove any need to made versioned unit.

At some point in future, this design philosophy will kick back hard.
Ignore unknown syntax --> use default values --> run the service. What could possibly go wrong?
It's only matter of time until someone (black hat) finds a severe security flaw from this behaviour and shit starts to hit the fan._________________..: Zucca :..
This space is not for rent.

You don't depends on Pottering to fix any and do it yourself, and it's like raising your stupid badly broken sh script security by like 200%

LOL.

tld wrote:

Don't even get me started about all this FUD regarding the horrors of shell scripts.

Yes, the position whereby "We cannot write shell, so trust us to write C.."
Shell is just very forgiving: it has to be, since its primary purpose is as an interface between an interactive user and UNIX; so it does the best it can to accept whatever input you throw at it.
That this makes it easy to throw together scripts which aren't well thought-out is not shell's fault. It really is by design, and there is a valid reason for it. (I'm amazed that is seemingly so hard to understand.)

You can write a crap program in any language. It's funny that here we are, 40 years later, still using sh. That is because the underlying design of UNIX was very well thought-through: a stark contrast to the kitchen-sink approach of systemdbust, and so many others that are also best forgotten.

Don't even get me started about all this FUD regarding the horrors of shell scripts. Even in the slashdot post that Naib quoted (where the guy is in fact very critical of how this one was handled) he says "systemd is a key part of the GNU/Linux infrastructure, and it exists for a reason: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste.".

According to who? What the HELL does that even mean? More importantly does it mean that you're better off inserting the functional equivalent of the Windows OS...the epitome of shitty and fragile written with the most clueless ignorance out there...between the kernel and everything else?

Even Redhat doesn't believe any of that shit, and anyone paying attention knows as much.

Tom

the key part in what he wrote was: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste

he and others were not saying all shell scripting is shitty, just that there is. Its a bit of a misdirection because a shitty coder will write shit in whatever they use.
Maybe redhat had an abundance of shitty shell writers ... maybe they had mostly C writers and only a few loosely knew shell...

What probably facilitated Systemd being accepted as a RH project was the fact the low-level code is in C and they quite possibly had a lot more quality C coders (ie to deal with libc etc...) than they did sh coders (who prob only hacked to get things done).

The issue is the architecture of systemd is flaky...

On the username issue... what I find amusing is RedHat, the employer of Pottering, has coreutils that permits a username starting with a numeric character_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

Even in the slashdot post that Naib quoted (where the guy is in fact very critical of how this one was handled) he says "systemd is a key part of the GNU/Linux infrastructure, and it exists for a reason: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste.".

I feel a bit guilty for posting this, but this one is such an easy target. By adopting systemd, we avoid relying on fragile shell scripts that are made insecure through ignorance or haste, and instead get nicely constrained systemd unit files that are made insecure by deliberate design (ignoring security-relevant attributes because there is no way to mark them as a mandatory directive).

On a serious note: I have hinted at this a few times, and I think at least some of the people posting here are thinking along the same lines (in particular krinn's remarks on versioning): the systemd unit file parser needs to have a distinction of advisory directives versus mandatory directives. The unit file parser can ignore unknown advisory directives, but must fail a unit file which has an unknown mandatory directive. Preferably, it would always fail a directive that was known but unacceptable (such as an ill-formed username, or passing a string where a number is expected, etc.). There are several ways that the mandatory versus advisory split could be done.

The simplest is to declare all directives mandatory and refuse units which use any unknown directives. The systemd maintainers have already declared they do not like that approach. I agree that this form is a bit limited.

They could instead include a version number, and commit to increasing the version number whenever new mandatory directives are added to the language. If systemd encounters a file with unknown directives, and the version number exceeds its own, then this file requires a newer systemd and must be abandoned. If it encounters an unknown directive and the version number is not greater, then this directive can be assumed to be advisory and the unit file accepted.

They could divide the namespace, such as by saying that directives with a leading ! are important and are always mandatory. Directives without a leading ! are advisory.

Other possibilities may exist. These are just some quick ones to provide ways to version the file without needlessly removing compatibility with old versions.

Of course, the best solution according to the general systemd design philosophy is that they need to add a new component, provisionally named systemd-packaged, that will automatically update systemd to the latest code tagged by systemd upstream, so that they need never worry about the existence of downlevel installations. Since systemd already runs with privilege, it could update itself out-of-band of the normal distribution packaging system, bypassing distribution maintainers who may take hours or even days to ship new versions and users who might wait until a scheduled downtime to install the new version.

Of course, the best solution according to the general systemd design philosophy is that they need to add a new component, provisionally named systemd-packaged, that will automatically update systemd to the latest code tagged by systemd upstream, so that they need never worry about the existence of downlevel installations. Since systemd already runs with privilege, it could update itself out-of-band of the normal distribution packaging system, bypassing distribution maintainers who may take hours or even days to ship new versions and users who might wait until a scheduled downtime to install the new version.

This sounds really close to what M$ is doing with windows 10... With their mandatory update on their schedule (regardless that the patches are not well tested, evidenced by the number of major issues that frequently pop up from the updates). Sure they say it's all about keeping people updated to fix security vulnerabilities, but it does the same thing as you said; takes control out of the System admin's hands and puts it in some corporation's hands that only think their use cases matter.

Of course, the best solution according to the general systemd design philosophy is that they need to add a new component, provisionally named systemd-packaged, that will automatically update systemd to the latest code tagged by systemd upstream, so that they need never worry about the existence of downlevel installations. Since systemd already runs with privilege, it could update itself out-of-band of the normal distribution packaging system, bypassing distribution maintainers who may take hours or even days to ship new versions and users who might wait until a scheduled downtime to install the new version.

Err ... No. Replace one buggy version with another and nobody knows.
What about air gapped installs?_________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

the key part in what he wrote was: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste

Yes, "we've been writing crap shell, so let's not bother learning the implementation language," let's just switch to C programs that are all-too-easily made insecure through ignorance, lack of domain knowledge, haste and ill-conceived design.
Only now we've made it a helluva lot harder for the admin to exercise any real control over the machines they're liable for. Funny, that; almost like a bot-farm.

Quote:

he and others were not saying all shell scripting is shitty

It certainly sounded like it.
At best then, in your version of events, they were saying that their own shell scripting is shitty; which is hardly news to #bash regulars.
And hardly a reason to ditch shell; more of a reason to swallow your pride and learn from people who know what they're doing. (Or hire some.)

Quote:

Its a bit of a misdirection because a shitty coder will write shit in whatever they use.

That's why it's hardly a reason to ditch shell.
If you don't understand your implementation language, the answer is not to blame the language, but to do your fscking job and learn it properly.

Quote:

The issue is the architecture of systemd is flaky...

and it would be flaky in any language, because it's not about what it does at language-level, but about its overall design and the "strategic aims" of RedHat.

That meme about not understanding UNIX? A large part of understanding UNIX is about grokking the shell, and why it's always been a central part of the design.
Nor can you separate C from UNIX, in terms of grokking the language and the standards. C is designed to be called from shell; the distinction of shell preparing (globbing and separating) arguments, and the C runtime using them: that's UNIX, tying together independent processes to achieve the end-result the user wants.
That it seems old-hat, and why would you do anything different, etc, is simply testament to the solidity of the design, which won out against various other competing models in the 1970s. (Winbloze still leaves it to individual programs to eg: glob arguments, or not, which is one of the ways it is so woefully broken by design.)

Nubs who want to parade their ignorance by vilifying shell only show themselves up as ingenues.

Let's not apologise for them, as if they weren't really saying what they were saying.
Even more importantly, let's not follow them into that broken by design vision of the future, where we're no longer admins and users, but just passive consumers, grateful for whatever the Corporation has "rented" us of our own shared work.

(Winbloze still leaves it to individual programs to eg: glob arguments, or not, which is one of the ways it is so woefully broken by design.)

Oh man...do NOT even get me started on that mess. We suffer from that to this day, even for example, with the Linux version of unzip, where you need to use:

Code:

unzip "*.zip"

...to unzip multiple archives, because unzip itself handles the glob itself apparently. Let's not forget Mac OS <= 9 that arguably did Windows one better with no concept of a CLI at all and...if I'm not mistaken...no concept of stdin or stdout. Yuk.

...with no concept of a CLI at all and...if I'm not mistaken...no concept of stdin or stdout. Yuk.

I know I'm crossing the line between Mac, Windows, and systemd here, but...

The systemd people have been doing away with the command line, communicating over dbus instead of stdin/stdout. I wonder if we'll even recognize mainstream Linux in five or ten years._________________.sigs waste space and bandwidth

One thing I find rather interesting is, wasn't the Systemd devs one of the people that was complaining quite loudly that dbus is slow and needs to be replaced. This is even though they are more reliant to dbus and shove even more stuff, including the kitchen sink through dbus (which supposedly is soo slow)...

Let's not forget Mac OS <= 9 that arguably did Windows one better with no concept of a CLI at all and...if I'm not mistaken...no concept of stdin or stdout. Yuk.

I've used Mac OS 9 in the past for many years. So far it's the most unstable OS I've ever used and at the same time the worst. The earlier Mac OS 8 was quite bad too. But before that (System 7) Apple had something there. Apple even had A/UX. Sadly not many applications ran on it. I wish it was more succesful, but Apple pulled the plug, I guess. Later they actually partly funded the MkLinux project(the site is still up :o), which was great, but sadly the provided image didn't recognize my networking interface (some tower PowerMac), so I gave up._________________..: Zucca :..
This space is not for rent.

I wonder if we'll even recognize mainstream Linux in five or ten years.

If their track record stays consistent, GNOME and KDE in ten years will superficially resemble OSX and Windows five years from now, will have system requirements 20 years ahead of Moore's Law, and embody all the maintainability and engineering wisdom of enterprise software written in the late 90s.
The desktop arguments will be stronger than ever by then, everyone having had to go back to native apps after browsers and browserapps begin requiring a small nuclear reactor to render a HTML hello world..._________________*.ebuild // /etc/service/*

For the record, my last paragraph was a joke inspired by the past pattern of systemd subsuming components that ought to remain separate. While I won't be surprised if a systemd maintainer one day tries to do what I described, I don't think it's a good idea for them to supplant distributions.

The problem is that the configuration parser as shipped disagrees with the common understanding of the configuration file by end users.

I agree with you! I wanted to mean that the developers of systemd could have cooperated with the developers of the software involved in the problem.
Thus, a suitable solution would have been proposed and users could have apprehended the functioning of systemd services.

Naib wrote:

more bugs, more locks

Their communication should be more conciliatory. However, GitHub seems to be their bug tracking system: "editorial" criteria are tightened in bug reports.

On their mailing list, someone has opened the discussion about the user issue discussed in this thread.

I have been following the ml around this and they just don't get it... (well some do)

Some are saying username starting with a number should be blocked by Systemd (this is countered by others that SysD should not restrict this)
Some are saying such usernames are invalid (others point out that thats not the case, equally Windows permits it thus samba must THUS linux needs to support it otherwise samba won't work on systemd systems)
Some are saying that the unitfile will run as the UID of the leading number (yet the bug actually states My systemd v232 says: Invalid user/group name or numeric ID, ignoring: 7oz and starts the service as root also. Likely because the 7oz as a whole is not a valid number.)
Some are pulling the usual its systemd-bashing bandwagon so ignore it
Some are saying it isn't a bug..._________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king