On Mon, Aug 01, 2016 at 08:25:01PM -0400, Nico Kadel-Garcia wrote: > Depends on the init script. I can set up sshd, for example, to run on > a non-privileged port as a non-root user, and tweak the init script > very slightly to support that. Other testable daemons, like Jenkins or > Tomcat, certainly can run as non-privileged users on non-privileged > ports, and are often done exactly that way for debugging in parallel > with a production system on a privilieged port. I did not ask why you wish to do this, only why it was something that was supposedly impossible (or more difficult) with systemd. (FYI: I routinely run daemons as an unprivlidged user, using systemd units. Versus running by hand I get first-rate logging and all of the other cgroup-enabled manageablility that systemd brings to the table) > And yet, the "most trivial of UNIX scripts" are embedded in stable > packages decades old that have had little to no benefit from systemd. So what are these decades-old daemons? (Heck, of the four systems I directly control, there is only one sysvinit script in use -- for the 3ware RAID controller management daemon) >> Um, it's a fairly trivial bit of specfile work to alternatively include >> an init script or a systemd unit file based on EPEL5/6 or PEL7/Fedora >> builds. > It's a burden, usually solved by ignoring one or the other. Since > systemd is always incompatible and always will be incompatible with > anything but relatively modern Linux distrubitutions, guess which > packages never get ported to non-Linux systems. We're talking about EPEL 5/6 vs EPEL7/Fedora here, not "Linux distributions" in general. You could have written a complete unit script (and the condifitonal specfile logic) in fraction of the time you've spent writing these emails. But since you brought it up, I'd love to hear an example of something that isn't getting ported to non-Linux systems solely due to systemd, as opposed to utilizing some other feature unique to "relatively modern Linux distributions". I can think of many examples of the latter, but not the former. When it comes to non-Linux systems, in my experience folks who deliberately chose those fringe platforms are nearly always willing to help out. Patches are almost always welcome. > That would be very sweet, if it ever worked that way. We've seen to > many times when systemd merged logging is not intelligible to stable, > cross-platform tools and even cases where systemd settings alter > system behavior with no logging whatsoever, so there's frankly little > reason to trust its completeness. (KullUserProcess=yes, anyone? Making > /etc/resolv.conf a sylink for the new dhcp service, then failing to > ever restore it if someone hand edits it with vi and breaks the > symlink?) You appear to be conflating several unrelated things, so let me address them individually. * Logging -- Got any examples that aren't resolved by enabling syslog passthrough? (Log parsing is something historically quite brittle; I can recall many things that broke release-to-release far before systemd was ever conceived) * Systemd settings altering system behavor with no logging -- Given that a setting is in of itself intended to alter system behavior, I'm not really sure what your point is. * KillUserProcesses=yes -- Given that this setting was only part of Fedora Rawhide for about a week, if you're complaining that you got bitten by unexpected behavioral changes I really must question why you're running Rawhide. If you weren't running Rawhide, then the only way it could have bitten you is if you manually changed the setting yourself (in which you only have yourself to blame) or if you compiled your own systemd instance (ditto). Meanwhile, to give credit where it's due, systemd now logs when it kills stuff due to this setting, rendering the whole argument moot. * Symlinking /etc/resolv.conf -- It was due to a combination of conflicting changes in systemd and NetworkManger, and if I understand correctly, only ever affected Rawhide (or Fedora pre-releases). It's a perfect example of the sort of issues that come up when distributions attempt to integrate low-level software developed by different teams. > No, most of my userbase doesn't use systems capable of supporting > systemd. Not many stable industry systems do. Fedora is where I get a > handle on up and coming projects and try to help prevent trouble for > myself down the road. By your own words, doesn't this indicate that proper systemd support is something you should be concerned about? After all, all marketshare-relevant Linux distributions now utilize systemd, along with the current releases of enterprise-y/stable/LTS distributions. Their installed/market share will only grow. - Solonmon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur.
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
