> I wish I knew the solution to this problem
Ooh ooh, I know! It's to improve systemd for the use-cases outlined and build a really great open source init/process manager.
Ooh ooh, I know! It's to improve systemd for the use-cases outlined and build a really great open source init/process manager.
Also, at $DAYJOB, we run into mysterious systemd failures and misbehaviors at least once a year (usually for things that should be super straightforward). Every one of these failures and misbehaviors we've run into has been met with a "Wow. That's weird. Sucks to be you, I guess." with a dash of "No, we won't be updating the documentation to mention that." if the actual behavior is contrary to the documentation.
In short, while it may be true (I really don't know) that the systemd project welcomes changes and patches, IME it's pretty clearly true that if you're working on a problem that the project management doesn't understand, and/or doesn't want to think through, your work won't be considered. [0]
[0] Which, fine, it's not my project, so I don't get to tell you what to work on. Doesn't mean I have to like it or recommend that people use it.
> we run into mysterious systemd failures and misbehaviors at least once a year
The most detail my NDA permits me to get into is that our most recent failure was that the systemd cron replacement gets in a state where it refuses to ever schedule a scheduled task and that the systemd folks were like "aw, shucks" about it.
https://github.com/systemd/systemd/issues/8398
FWIW, I'm generally a fan of systemd. That's a pretty minor issue in the grand scheme of things and it's not really "mysterious" -- the behaviour was consistent but didn't line up with the documentation.
In my experience, almost every time I hit an issue with systemd, it's when I'm interacting with it at a (relatively) low level. e.g. Monitoring / controlling units via D-Bus. There is theoretically enough documentation to do that, but it's often incomplete or ambiguous and you're left trying to figure out systemd's behaviour via experimentation.
But as I said, this isn't _really_ a dig against systemd. Even if monitoring service state transitions via D-Bus is finnicky, it's a heck of a lot easier than the alternatives with busybox init or whatever.
PS: personally I like systemd more that the script mess which preceded it. But the are some outstanding issues with it to be improved.
People already did the latter (sadly no-one used it because there was no mechanism that forced distros to adopt it), and would do the former if the systemd maintainers would let them.