| > I’m stating the fact that prior to systemd, issuing a service restart command under any Unix at all was prone to inheriting any rlimits your shell session happened to have... IFF the service manager you used was either incompetently written, or had this behavior as an intentional feature. This is a problem (like many other problems that the Systemd Cabal addressed) that was known and resolved by many other folks substantially before systemd came along. Like, think about it for a second. You're saying that systemd has a mechanism to avoid this problem. Systemd uses tools that have been available in Linux for a long time. (I think the newest tool it uses is control groups, which are like seventeen years old.) Are you really saying that none of the big players in the space (nor any of the sysadmins that got REALLY pissed off at the bullshit unreliable behavior that you describe) ever hit upon the technique that systemd uses to avoid this problem? As I (and many other) keep saying, systemd did solve many problems... but it was also not the first to solve many of those problems. > Implementing a service manager that can understand and interpret systemd unit files for FreeBSD... Unit files kinda suck, and so much of the behavior of the various options inside of them are underspecified. (How do I know? I've gotten badly burned in production repeatedly by underspecified behavior shifting out from under me as the software implementation changed.) There's no good reason to use Unit files outside of systemd... especially when services with non-trivial startup and/or shutdown procedures have to have systemd run helper programs because it's just impossible for systemd to handle every conceivable startup and/or shutdown requirement without embedding a general-purpose scripting language inside of systemd (which would just be fucking stupid). |