Re: init scripts [was: If Not Systemd, then What?]
Scott Ferguson wrote:
On 18/11/14 15:06, Miles Fidelman wrote:
Please don't top post - it's not hard to move the mouse.
Scott Ferguson wrote:
On 18/11/14 12:54, Miles Fidelman wrote:
<snipped> I left out sendmail, but I just checked, and guess
what, no systemd service file in upstream).
xy?
Ummm.... those are NOT systemd scripts shipped by the upstream
sendmail developers.
Your point was noted - hence the "xy?" comment.
ummm.... that's awfully cryptic
However - I don't 'believe' it's a relevant point.
A. Mail servers don't care about init systems. Quite the reverse.
B. systemd's ain't systemd's (e.g. what constitutes "systemd" varies
according to release and distro). (i.e. ~/.bashrc from debian isn't
identical to upstreams).
Are you kidding me? Mail servers generally start up automatically as
system services, and need to get restarted if they die. How does that
not involve the init system? Same again for pretty much any server.
To ensure I wasn't falling into the trap of confirmation bias - before
checking upstream for init support I'd be asking myself if it was
necessary (cart before horse?).
e.g. Why *should* sendmail ship *a* systemd .session file? After all
sendmail developers have to support a wide range of systems and
apportion resources according to their definition of needs.
1. Compared to configuring sendmail correctly it's trivial to create one
to suit the usecase.
2. Like sendmail itself there is no "one-size-all" session/timer
configuration.
3. If the user installs from a distro repostitory they get a "default"
.session file to match the distro. (If the distro is going to do the
work why should upstream do it?)
They ship sysvinit scripts, period. Which is
my point.
I suspect the logic you base the point upon is flawed.
./configure
make; make test; make install
pretty much works for pretty much any major server application - which
includes installing init scripts from upstream that just work
packaging adds some convenience in handling dependencies and managing
system configuration, usually at the expense of running well behind what
comes from upstream (and checkinstall makes it pretty easy to integrate
upstream source into package management)
generally, I can rely on upstream code to "just work" - and usually, but
not always, packaged versions are reasonably current and "just work"
but... when upstream provides sysvinit scripts, that adds complexity
and/or extra code:
- either the packager has to write systemd init info (one more thing to
go wrong and that should be regression tested), or,
- systemd has to handle the init script properly - again one more thing
to go wrong, particularly if the upstream script runs afoul of one of
the documented (or undocumented) incompatibilities in systemd's handling
of init scripts (and why should upstream have to worry about that when
they code?)
Major upstream application developers do not seem to be
jumping on systemd.
More important than trying to find evidence of a negative 'might' be
determining whether there is a need. If there is none[*1] then the
absence of proof has little value.
[*1]you mention sendmail, which is widely deployed on distros that use
systemd *despite* upstream not distributing systemd "support" - because
upstream "support" for systemd is redundant. Do you have something less
fuzzy than "major upstream application developers"?? It's puzzling as
this is Debian and most of us use the *Debian packaged* version of
upstream so the relevance is difficult to dissern.
If anything, what I'm seeing are "oh sh&t, I
guess we should develop systemd service units at some point."
Can you point to some upstream references for this please?
(my Google-fu fails me).
Don't really have a lot of time to retrace my steps, but I came across
comments to this effect on at least two (I think three) dev lists for
programs on the list of major server apps that you clipped from this thread.
But you could start here:
http://search.gmane.org/?query=systemd&group=gmane.comp.db.postgresql.devel.general
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
Reply to: