[e12e]

I recently had to write/adapt an init.d script for caddy2 on a legacy server. I must admit even such a simple task, did indeed feel a little bit arduous - I suppose I can relate better with those railing against init-scripts, now that it's been some years since I last had to touch one... (we needed something with a recent ssl implementation to terminate ssl on that box, caddy fit the bill - serving as a stop gap..).

That said, it should be eminently possible to have something like service files, and not systemd.

And I must admit, reading the back and forth on the linked issue, I still have zero confidence in systemd upstream as maintainers of systemd.

That, more than the disturbing complexity, "eat-the-world"-tendency and tight coupling (with lip service to separation, by having tightly coupled parts of the overall monolith be "separate" as individual binaries) worries me most about systemd.

https://github.com/systemd/systemd/issues/13674

[jka]

Thanks for highlighting the GitHub discussion of the issue.

I'd imagine the maintainers are extremely busy and may have a sense (or incentive?) to respond - in any way - to issues swiftly, and that closing them may in many cases be the most time-efficient way to keep their own work under control.

That said I agree that situations like this are frustrating for users, especially when they expose what appear to be genuine and reproducible issues.

[e12e]

I get that they're busy, and "lol, you're on an ancient version #wontfix" is quite all right as a first response (maybe a little less so for RedHat subscribers, considering the link between systemd and RedHat).

But not seing that the design seems fundamentally broken, that's more of an issue (message amplification to millions of messages, the fact that it's questionable if systemd even can use the information for meaningful ordering/dependency reseloution.... When it's not systemd doing the mounting..).