Re: init scripts [was: If Not Systemd, then What?]

[Scott Ferguson <scott.ferguson.debian.user@gmail.com>]

On 18/11/14 23:14, Miles Fidelman wrote:
> Scott Ferguson wrote:
>> On 18/11/14 15:06, Miles Fidelman wrote:
<snipped>
>>> 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

Not if you are a programmer, or read this list often.
http://mywiki.wooledge.org/XyProblem

> 
>>
>> 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?  

No.

> 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? 

Please read again. I never said "mail servers do not involve the init
system" - I said "mail servers don't care about the init system". They
simply need to be initiated, and, depending on the admins desires,
monitored - typically by a daemon. Whether started by /etc/rc.local,
cron/acron, or *any* init system - mail servers don't care.

<snipped>
> 
>>
>> 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

Apropos of what??!!

> 
> pretty much works for pretty much any major server application

It "pretty much" works to *build* any package; test the build, and then
(crudely) install it.

> - which
> includes installing init scripts from upstream that just work

"Pretty much"  i.e. sometimes.  IMO it's too generic to apply a process
that's designed to work in non-specific situations to *specific*
situations - in this case, Debian.

> 
> 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)

Agreed. But, "huh"??  You talk of a need for stability then choose
bleeding edge corner cases.

Current upstream version of sendmail is 8.14.9 which:-
;"just works" with Jessie or Wheezy when systemd is installed using the
Debian packaged systemd session configs for sendmail
; 8.14.8-1 from RC installs on Debian just fine.

> 
> generally, I can rely on upstream code to "just work" - and usually, but
> not always, packaged versions are reasonably current and "just work"

Agreed. Though the Debian way isn't always what upstream supports - and
often I've found their "Debian" package is actually Ubuntu packaging, so
I've had to tweak things (likewise checkinstall and rpm conversions
don't always work). That's the price of choosing the bleeding edge don't
you think?

> 
> but... when upstream provides sysvinit scripts, that adds complexity
> and/or extra code:

Yes, though:-
;I don't expect upstream to support all distros and releases
;I had many LSB errors from upstream sysvinit scripts - so as a rule I
expect problems when installing packages from upstream. Lack of support
for downstream *is to be expected*.


> - 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?)

Agreed "pretty much". Lack of support for downstream *is to be
expected*. If you have a problem with that take it upstream.


> 
>>
>>> 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 discern.
>>
>>> If anything, what I'm seeing are "oh sh&t, I
>>> guess we should develop systemd service units at some point."

Read again please - I haven't said that at all, only that your claim
that as upstream sendmail doesn't ship with systemd service units
"proves" sendmail doesn't support systemd is false logic.


>> 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,

Please don't make claims you aren't prepared to support. Your time is no
more or less precious than others.

>  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.

Here they are, I note you've since added sendmail:-
bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin
amavisd clamav sendmail


All those packages are available in the Debian repository, most are
available in the latest upstream versions or very close to it. If you,
as you've mentioned previously, are running Debian stable, or unstable,
and you also "require" the bleeding edge on a production server *and*
that version is not available in the Debian repositories - it's likely
because Debian can't backport it easily (and likely neither can you).

Some specific instances would be useful.

You've posted more than 50 times to this list alone in the last month
with "concerns" and tangents which a number of people have patiently
tried to help you with. I assume best intentions despite the Gish Gallop
format, and I understand your reluctance to abandon old scripts and
procedures - however I truly don't understand why you'd require bleeding
edge apps on productions servers running old stable and stable. BP is to
deploy only what is well tested - the same sensible objection you have
to systemd, but:-
;systemd is not bleeding edge
;systemd is not forced on you (or me) - avoiding it is easier than
installing most of the upstream apps you say you install from outside Debian

Call me a fanboy if you wish but for the record (again); I don't
"advocate" systemd (only Debian); I am 'considering' deploying it for
production in *two to four years time*


> 
> But you could start here:
> http://search.gmane.org/?query=systemd&group=gmane.comp.db.postgresql.devel.general

Thanks, but you are the one making the claims and it's incumbent on you
to support them with specifics, not me. That's only polite don't you think?

> 
> 
> Miles Fidelman
> 
> 
> 
> 
> 

Kind regards


-- 

"My watch runs 3 hours slow and I can't fix it, so I'm moving to Perth"