systemd 250 Released With A Huge Number Of New Features, Improvements

[pal666]

Dracut and iwd and others are at kernel.org is because the Linux kernel development is not past going into userspace. when there is strict relationship between kernel and the area.

but there's no strict relationship between kernel and desire to start container as non-root user

[pal666]

What if my employer used RHEL and if I've even bought packaged Redhat distros, in the past?

then your employer or you can complain about packaging issues

[pal666]

Wow. Why? It feels like this would fit better in a driver API for those classes of devices.

so you are happy to put everything into kernel, but you are not happy with db in systemd? lol, you know your complaints are illegitimate when proposed solutions make them worse

[coder]

Please note your highly skilled C coders are not your highly skilled documentation writers.

That's BS. I'm not talking about user manual stuff. I mean bare bones API documentation, mostly. If you can't write a structured comment block specifying the pre-conditions, the post-conditions, the semantics of the parameters and return values, and any special error conditions, then you have no business writing production code, either. Someone else can massage that stuff into nice manpages (even better, if you can use something like Doxygen to do it, but that's not a "must").

It really comes down to the policies these projects choose to institute. If they adopted such standards, if only for public functions and data structures, it might slow down their programmers by a couple %, max. There's usually a ratio of about 10:1 between private and public functions (in well-written C code, anyway), and maybe 100:1 between lines of implementation code vs. those of public header files.

It's not that much of a burden, and would probably pay for itself in the amount of bugs it would avoid. Plus, the discipline of having to think through what you're going to do before actually starting the implementation can save time on false-starts that have to be scrapped and rewritten.

Even better is to have developers write design documentation, providing a high-level view of what they're going to implement. It only sounds like a chore until you actually do it, a couple times. It ends up feeling a lot more like programming than you might expect. And if you don't understand your plan well enough to describe it to someone, then you probably don't understand it well enough to implement correctly, either.

That provides a natural place for interns to start, as well. They can write some user-level docs, based on design docs and API docs. In the process, they will learn about the code well enough to start doing some bug-fixing. That sets them up to take on some minor feature-additions, etc. So, it's a really good way to ramp them up.

those people happen to be poor at commenting their code as well.

If people pester you with questions often enough, you will eventually learn where & what you need to comment, in the code. Code reviews, like when you submit a PR, are where a lot of these issues come up. I mostly write inline comments for myself, so that I can easily see the important details if I come back to it after 5 years.

There is a repeating set of failures.

It's a solvable problem, if only there's the will.

If you work at a place like Google, I'm sure you won't get away with writing undocumented code.
(I only pick on them, because I know they have high standards. I've never worked there, myself.)

[coder]

so you are happy to put everything into kernel,

Only what's necessary to query information from the device, itself. If the device can self-describe, then it should be the preferred source (unless it's known to be inaccurate).

but you are not happy with db in systemd?

I already said I accepted the need for a higher-level DB to contain overrides, when necessary. However, that should only be a secondary solution. Devices are likely to report the correct information, and will tend to do a better job of staying up-to-date than a bolt-on DB.

lol, you know your complaints are illegitimate when proposed solutions make them worse

LOL, try reading what I wrote and then your criticisms might actually carry some weight. Still, probably not much, because you take so many pot-shots at people.

[gotar]

I didn't say it should. I criticized its endless scope-creep.

Nobody stepped in for years, all they took is a field of abandoness.

There are two things I wish: that the systemd maintainers will eventually reach a point where they start building separate and independent services to solve additional problems, and maybe that they'll one day refactor systemd into a set of independent services. Of those, I think only the former is particularly likely.

The services are separate and independent. I got half of them masked, remaining mostly not running nor pulled.

# ps axw | grep -i systemd | wc -l
9

2 of which are systemd --user and one being grep itself... systemd (init), journald, udevd, timesyncd, logind and dbus --address=systemd:.

# rpm -ql systemd-units | grep -i /lib/systemd/system | grep -i service | wc -l
129

How much exactly do you want them to be separated?! Have you ever been involved in development of rc-scripts? I was.

There is one example that has burn into my brain - it took me some enormous effort to pin this down within rc-scripts functions (the one I currently got is 1376 lines of shellcode), functions.network (690 lines), ifup, ifup-vlan and all the "independent" binaries and shells (as mentioned in commit, pdksh, mksh, bash, zsh...). This (s)hell-hell was causing over minute delay of boot at the time as I got ~30 network interfaces then (now it's ~80, so 2.5 minutes of pointless waiting only for arping to return). And despite the fancy code, the concept of "online" was not existing - systemd-networkd can tell per-interface status at selected level and make this configurable per-service, so finally, after all that years, I can start a network-facing server as soon as as the interfaces required for bind() are set up, but without waiting for actual carrier to be present (like when booting without network cable plugged in) and run some network-using app after the "internet" thing has a chance to work. At that time I got servers shutting down for over 5 minutes, mostly waiting for squid etc. so my routine was to manually shut down some of the services first in order to reduce downtime.

No, shell doesn't fit into service management at all. It doesn't even fit for glueing together building blocks. Not to mention supervision... How do you want to provide such fine-grained dependencies (like "routable IP address set up and carrier present" or "device-mapper target started, but degraded") without introducing some declarative language? Can you invent this on the side? How do you want to manage hardware status externally to some daemon running in the background and making renaming, IRQ mapping, symlinking, managing permissions? By keeping all the data in mysql tables? Currently I got udev rules that to this (for specialized cards) by PCI slot. I got USB devices whitelisting (so no rogue keyboard nor drive would mess in the system) and the hardware watchdog being used from the very beginning. And finally, when something goes wrong, I got the log output from early boot available without taking photos from the monitor screen...


Or maybe you're just complaining about common source tree? Start changing the world here:

$ rpm -ql coreutils | grep -i bin | wc -l
104
$ rpm -ql util-linux | grep -i bin | wc -l
97

[oiaohm]

I mean bare bones API documentation, mostly. If you can't write a structured comment block specifying the pre-conditions, the post-conditions, the semantics of the parameters and return values, and any special error conditions, then you have no business writing production code.

There is a problem here.
Human diversity is one of the cursed factors<< I said this before and this is absolutely a major problem.

A person may not be able to write the pre-conditions and post-conditions in english. That does not mean the person is bad at writing code. Remember Linux kernel comments have to be in english. Yes and this person with poor english may be the very person who designed the hardware and has stacks of it test if something works or not.

There is absolutely a need for people who are masters in documentation writing and translation even for basic comments and this is before legal.

Some employment contracts people can submit code to the Linux kernel without comments based on publicly released documentation for the hardware but they legally cannot put comments themselves in their code. Interesting point of someone else submits a patch to add a comment they can say yes or no if that comment being added is correct or not and even merge the patch. Important thing they did not write the code.

So there are two causes with the Linux kernel why code is missing comments. Both the best fix is more people who job is just to focus on putting documentation on items missing documentation.

If people pester you with questions often enough, you will eventually learn where & what you need to comment, in the code. Code reviews, like when you submit a PR, are where a lot of these issues come up. I mostly write inline comments for myself, so that I can easily see the important details if I come back to it after 5 years.

With something like the Linux kernel this does not work at all. Yes the people were its breach of comment to release comments themselves without approval of legal will not matter how much you pester them they are not doing. Yes those with poor english are not going to do it either.

Good comments in code is really helped by coders writing code having access to a technical document editor to review their comments to make sure they don't do embarrassing mistakes as well.

If you work at a place like Google, I'm sure you won't get away with writing undocumented code.

Here a shocking one some of the coders at google in their complete time working at google have never written a single code comment yet the code the work on is all perfectly documented. That is what the technical document writer/editor person in their team does is cover for their limitations. Yes some of them have dyslexia and other issues where they can write very solid code but their comments are totally messed to the point of being more of a hazard then a help.

The hard reality here is some people are really good at writing computer code but have a problem. Yes problem be it something like dyslexia or a language barrier they are absolutely useless at writing comments/documentation in the type projects want. These people do need the support of technical document writers and editors..

Yes good technical writers and editors are even helpful in the legal problem case as well.

Documentation team is something a lot of open source project underestimate the importance. Yes a lot of people are like you coder who think that documentation team has nothing todo with comments in code when in reality that is documentation that falls under their domain. As a team they can help people around any problems properly documenting their code be it a language issue or a legal issue if the team exists with enough members.

[coder]

The services are separate and independent. I got half of them masked, remaining mostly not running nor pulled.

Try independently upgrading/downgrading them and you'll see exactly how independent they really are.

There is one example that has burn into my brain - it took me some enormous effort to pin this down within rc-scripts functions (the one I currently got is 1376 lines of shellcode), functions.network (690 lines), ifup, ifup-vlan and all the "independent" binaries and shells (as mentioned in commit, pdksh, mksh, bash, zsh...). This (s)hell-hell was causing over minute delay of boot at the time as I got ~30 network interfaces then (now it's ~80, so 2.5 minutes of pointless waiting only for arping to return). And despite the fancy code, the concept of "online" was not existing

Yes, I get it. The bad, old way was bad. I'm not sure exactly what you think you're arguing against.

No one in this thread has said systemd doesn't contain lots of improvements. I'll go further and say it even has some awesome features and capabilities. Sometimes, they even go too far, like I'm really not wild about homed - although, because I don't know much about it beyond what I've skimmed from a few articles on this site, I'm withholding final judgement until I have some firsthand experience with it.

But, any newer replacement for the old init scripts would probably be better in a lot of ways. Especially as it matured to the point systemd is now at. You could even say the same thing about Linux: that any open source OS kernel that had become dominant instead of Linux would probably have many/most of the same features and benefits as Linux, simply by virtue of the fact that people will contribute patches to improve whatever system they happen to be stuck using.

No, shell doesn't fit into service management at all.

Okay, I'll give you an example. I have a service that only runs on certain hardware. It uses a 3rd party library that fails in some pre-main() code, if the hardware isn't present. So, I really can't even afford to start it, on an incompatible system. Back in the days of init scripts, I could insert that check directly in my script and use it to conditionally run the service when the start command is given. In the land of systemd, it wants that service running when asked. This became very annoying to work around, until systemd finally added the ExecCondition feature.

So, if systemd anticipates your need (and the feature doesn't have a bug, which sometimes happens), then life is good. Otherwise, we see a downside to getting rid of the old init scripts. In general, I do not want to go back to the init scripts of old. I've seen more than enough complicated ones that took too much work to puzzle and simply understand. I'm not too sure exactly what I'd do differently, in this case. I guess if systemd exposed a lower-level API for service states, then maybe it could support .service files that are actually scripts or programs that drive its internal state in a more direct way. That would enable some .service files to implement features not yet integrated into systemd, itself, but then your typical .service file would still be the mostly declarative syntax we have today.

Anyway, that's really getting into the details and isn't one of my top-level concerns about it.

P.S. thanks for taking the time to share your specific knowledge & experiences. I think this sort of exchange has more value than most of the responses a critical post seems to draw.

[oiaohm]

Okay, I'll give you an example. I have a service that only runs on certain hardware. It uses a 3rd party library that fails in some pre-main() code, if the hardware isn't present. So, I really can't even afford to start it, on an incompatible system. Back in the days of init scripts, I could insert that check directly in my script and use it to conditionally run the service when the start command is given. In the land of systemd, it wants that service running when asked. This became very annoying to work around, until systemd finally added the ExecCondition feature.

There was a work around prior to ExecCondition. ExecStartPre= If this did not return 0 the service use to go into failed state so stopping the ExecStart= in the systemd service file from running.

https://bugzilla.redhat.com/show_bug.cgi?id=651797

Yes ExecStartPre was put into systemd from the start to basically do what ExecCondition does. Only real change is the service does not have to go failed state with ExecCondition. Yes failed state can in fact better in case of incompatible hardware because that the service is failed you cannot just run a start and have it attempt to run again. Of course some people had a problem with cases were you could add hardware latter and did not want service in failed state in way to activating service again.

Early systemd without RestartPreventExitStatus= was more of a problem.

coder I will give you getting brain around how systemd was designed to-do thing early on is confusing. Even today documentation for ExecStartPre= is not super clear. Particularly on the fact it designed to put the service into the failed state.

So yes coder from day one there was a method to insert extra check into a systemd service file to result in a service conditionally going into failed state.

Yes this has kind of been the problem all the way along with systemd. People were using to adding X line to script to deal with issue and systemd mostly could do all same things but it need it done slightly differently.

[coder]

There was a work around prior to ExecCondition. ExecStartPre= If this did not return 0 the service use to go into failed state so stopping the ExecStart= in the systemd service file from running.

I did see that, of course. I didn't want the service to go into failed state, as that created other issues. The service isn't standalone.