On Mon, Aug 1, 2016 at 8:50 AM, Solomon Peachy <pi...@shaftnet.org> wrote: > On Mon, Aug 01, 2016 at 07:58:42AM -0400, Nico Kadel-Garcia wrote: >> There remain compelling reasons to avoid systemd for daemons. The need >> for system privileges to activate systemd based startups instead of >> being to debug init scripts as a non-root user and the complete > > I'm confused; are you saying that these mythical init scripts don't > require root to function? If not, why would an equivalent systemd unit
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. > file somehow require root to activate/invoke? > As for debugging, if anything, systemd makes it simpler to debug > failures. > >> incompatibility of systemd based startip configurations with any other >> operating system, including all the actual UNIX operating systems, >> means a very real compatibility cost for cross-platform work. > > Um, not even "real" UNIX uses sysvinit any more. And, incidently, only > the most trivial of init scripts is portable -- even to other Linux > environments, much less non-Linux systems. (Years ago I lost quite a > bit of my life trying to maintain "portable" networking-related > init scripts. What a cluster@$#%@) And yet, the "most trivial of UNIX scripts" are embedded in stable packages decades old that have had little to no benefit from systemd. >> Sysv init compatibility is invaluable for cross-platform or older OS >> work, such as for the still supported RHEL 5 and RHEL 6, which makes >> supporting such projects for EPEL backporting require multiple sets of >> init scripts. > > 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. > How about -- To provide consistency across the whole system, which means > everything behaves and can be logged/debugged/analyzed the same way? 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?) >> I'd leave the sleeping dog lie. It's going to keep coming up with >> cross-platform packages and maintainers who don't care to spend spare >> cycles to integrate systemd support. > > Just so you know, "not caring to spend cycles to integrate systemd > support" means that you're now ignoring the overwhelming majority of > your userbase. 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. > Anyway. > > - Solomon > -- > Solomon Peachy pizza at shaftnet dot org > Delray Beach, FL ^^ (email/xmpp) ^^ > Quidquid latine dictum sit, altum viditur. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
