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.