3 ms·

> 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/proc

> 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.

simoncion 2y ago
The systemd maintainers are pretty particular about things that aren't a "supported use case", so even if you bother to do the work, you stand a solid chance of having your work be wasted. In my professional experience, "unsupported use case" effectively means "I don't want to work on that". [0] 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.
- throwaway2037 2y ago
  > we run into mysterious systemd failures and misbehaviors at least once a year Can you share an example?
  - simoncion 2y ago
    > Can you share an example? 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.
  - Yizahi 2y ago
    An example from my company - sometimes on a few of the many thousands of identical devices in field something fails due to bug or hw failure. After recovering the device we get the dump of all info we deem interesting, including all logs and journals. In a small but not insignificant numbers of such archives the journal has multihour gaps in the logs. And they are gaps, so there are logs before the gaps and after. I think we never succeeded to reproduce or fix this issue in the lab, and relied on duplicating logs to the file on the device fylesystem (not optimal due to storage size and wear of the ssd memory). PS: personally I like systemd more that the script mess which preceded it. But the are some outstanding issues with it to be improved.
  - mkipper 2y ago
    I ran into this issue on an embedded system before it was raised / fixed: https://github.com/systemd/systemd/issues/8398 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.
lmm 2y ago
> Ooh ooh, I know! It's to improve systemd for the use-cases outlined and build a really great open source init/process manager. 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.

> 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.

simoncion 2y ago

The systemd maintainers are pretty particular about things that aren't a "supported use case", so even if you bother to do the work, you stand a solid chance of having your work be wasted. In my professional experience, "unsupported use case" effectively means "I don't want to work on that". [0] 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.

throwaway2037 2y ago
> we run into mysterious systemd failures and misbehaviors at least once a year Can you share an example?
- simoncion 2y ago
  > Can you share an example? 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.
- Yizahi 2y ago
  An example from my company - sometimes on a few of the many thousands of identical devices in field something fails due to bug or hw failure. After recovering the device we get the dump of all info we deem interesting, including all logs and journals. In a small but not insignificant numbers of such archives the journal has multihour gaps in the logs. And they are gaps, so there are logs before the gaps and after. I think we never succeeded to reproduce or fix this issue in the lab, and relied on duplicating logs to the file on the device fylesystem (not optimal due to storage size and wear of the ssd memory). PS: personally I like systemd more that the script mess which preceded it. But the are some outstanding issues with it to be improved.
- mkipper 2y ago
  I ran into this issue on an embedded system before it was raised / fixed: https://github.com/systemd/systemd/issues/8398 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.

lmm 2y ago

> Ooh ooh, I know! It's to improve systemd for the use-cases outlined and build a really great open source init/process manager. 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.