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

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

On 19/11/14 15:12, Miles Fidelman wrote:
> Scott Ferguson wrote:
>> 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
> 
> Can't say that I've ever come across it used on this list.

https://www.google.com/search?q=+"xy+problem"+site%3Ahttps%3A%2F%2Flists.debian.org

> 
> And while I can't claim to be much of a programmer, at least these
> days,  I've managed and worked with an awful lot of programmers, and I
> can honestly say that I've never come across the term in general usage.

Odd - it's commonly employed on stack exchange and various programming
lists.

> 
> Of course, your mileage may vary.
>>
>>>> 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.
> 
> I still don't think I'm seeing your point.  

Agreed. As demonstrated in the next two paragraphs.

> Mail servers, and servers in
> general need to be initialized, usually rely on the o/s init system, and
> generally come packaged with a collection of init and utility scripts. 
> To date, every single major server we rely on, for a relatively standard
> collection of web, mail, list, and database servers comes stock with
> ONLY sysvinit scripts.
Are you saying those apps can't be managed other than by sysvinit? (I
hope not).

> 
> To me, that's "caring" about the init system.  Can you elaborate on what
> you mean by "don't care?"

Are you deliberately being obtuse?

> 
>>
>> <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.
> 
> Well, for all of the servers I've installed, I've at various times
> installed from upstream source, on multiple distros, and BSD, and things
> "just worked."
> 
> The gnu autotools are pretty clever that way.
> 
>>
>>> 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.
> 
> At various times, I've found the packaged versions of mission-critical
> software to lag way behind upstream - particularly in the case of the
> list management software we use, and at times, antispam and antivirus
> software.  Also, some of the stuff we experiment and develop with
> (various NoSQL databases, and Erlang). Sometimes waiting for packaging
> to catch up just doesn't cut it (anti-spam stuff, for example - always
> looking at new tools there).
> 
> I worry a lot more about stability in the sense of environment and
> regression testing.  I really don't like it when my platform changes
> under me.  Applications, I expect to change.
> 
> <snip>
>> 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, to date, the Debian way has always provided a pretty stock Linux
> environment (LSB, etc.) - that allows for situations where Debian
> packages aren't available.  And, by and large, when I review the
> Debian-specific changes to a package, they're usually pretty minor. 
> (Yes, I tend to read changelog.Debian and README.debian files :-)
>>
>>> 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*.
> 
> As noted above, my experience is a little different.  I've generally
> found things to just work when I install them from upstream - on Debian
> in particular.
> 
> I guess that one of my concerns is that I've found a lot of stuff that I
> play with - cluster stuff, virtualization stuff, some NoSql databases -
> seem to be developed on Debian first, but in the form of raw source
> code, not packages.  


> I'm kind of worried that major changes in the
> Debian platform might change that.

I don't see an additional choice of an init system as a "major change" -
and I'm confident, based on experience, that Debian will continue to be
Debian (just work).

But that's just a difference of opinion - both based on "expectations"
of the future. Perhaps I differ in expectation only because I rely on
the triumph of optimism *based* on Debian experience -somewhat (I still
use the belt *and* suspenders approach i.e. 1 - 2 years to develop a
Plan B).

>>
>>
>>> - either the packager has to write systemd init info (one more thing to
>>> go wrong and that should be regression tested),

I have no problems with the idea that Debian packages are re-packaged
from upstream - in fact I expect it. As for "one more thing to go wrong"
- that's why I use stable and old-stable as the base for production
boxes. I expect minor problems with Testing, that's why that release is
so named. Stable has, in two decades, never proved less than advertised.

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

They don't.

>> Agreed "pretty much". Lack of support for downstream *is to be
>> expected*. If you have a problem with that take it upstream.
> 
> Well... I kind of look at it the other way around.  A distro is a
> platform.  


> It's job is to provide a hospitable environment for
> installing stuff from upstream.  

Huh? Where do I find this job description for *Debian*??

> And a mix of flexibility and stability
> is what makes a platform hospitable.   


> If I have problems with a
> platform, I'm going to change platforms,

Likewise.

> not "take it upstream."

Now your talking of "distos" (in this instance Debian). Before you were
talking of upstream package support.
Please don't use employ the Gish Gallop - it negates respectful
consideration of your concerns.


> 
> Maybe not the greatest analogy, but....
> 
> - My personal laptop is a Mac - partly because I've been using Macs
> forever, partly because I like the general form, fit, and function, but
> mostly because it's the most versatile platform around (I can run
> commercial applications, native unix code, and pretty much anything else
> in a virtual machine).
> 
> - My work laptop is Windows based - because the company issues it, and
> because Microsoft's business stuff actually is quite good supporting
> organizations (outlook, sharepoint, active directory, etc.).
> 
> - My (small) server farm (legacy of once owning a hosting company, now
> used to provide pro-bono hosting to a bunch of local nonprofits and
> community groups, as well as providing a development sandbox for future
> endeavors) -- started as Solaris, migrated to RedHat, then migrated to
> Debian and has been Debian for maybe 15 years
> 
> In all cases, I've tended to rely on code as "packaged" by its creators:
> - for Macs, it's either installer files or .dmg files

You get what you pay for - value is in the eye of the beholder.

> - for Windows, it's installer files

Likewise.

> - for *nix, I use packaged stuff for all the routine, environmental
> stuff (libraries, tools, utilities, and stuff), 

If by *nix you mean Debian (which is in no way Unix).

> while more often than
> not building critical applications from upstream source (.tar.gz source
> files are a package)

YMMV.

> 
> From this perspective, systemd seems to be creating instabilities,
> reducing flexibility, and generally making Debian (and many other
> distros) far less hospitable platforms. 

This is not my experience - or my situation. I've not deployed systemd
on any production boxes *yet* and I don't see that I'll ever be *forced* to.

*Do you have any specific examples*?
(I note sendmail.com doesn't have a single reference to systemd - make
of that what you will).

> It's a headache I don't need,

Why do you have problems with something you say that you *do not* use
,and, which you *will not* be *forced* to use?
That seems to be simply a problem of intolerance to other people's choices.

> for zero benefit to our environment.

[confused] How is this anything other than irrelevant fear based on
speculation. Irrelevant because you don't use it - you won't be forced
to use it. Speculation because it's all based on what you "believe" will
happen sometime in the distant future.

>>>>> 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.
> 
> Again, this seems like a backwards perspective.  When I put on my
> product manager's hat (which I've done at one time in my life), from a
> developer's point of view, one generally tries to develop for
> cross-platform compatibility.  

[confused] How is that relevant if you are *not* doing that now. And,
even if you were - you wouldn't have to support systemd??

<snipped>
> Again, not the greatest analogy, but people buy windows, because there's
> software available for it, that isn't available elsewhere. That's
> because developers develop for Windows, not because Windows packagers do
> their thing.

Great analogy or not - I'm not going to comment on Windows - or
Mac/Apple. I don't consider them relevant to why I use Debian. (nor are
silly car analogies - this is not /.).

> 
>>>>
>>>>> 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.
> 
> But that's not what I said.  What I said is that upstream sendmail
> developers don't see any need to develop for systemd - presumably
> because a., they don't need any capabilities not already provided,
> pretty much universally, by the sysvinit system, and b., because
> sysvinit scripts are supported pretty much everywhere (for now).
> 
> From an upstream perspective, the goal is to write software, and ship it
> in a form that can be readily used on lots of platforms, WITHOUT the
> need for additional packaging. 

Are you speaking for upstream?
If so why?

How does Debian including support for systemd as one of several init
system choices impact on upstream?
The only circumstances where that 'might' matter is for commercial
products - and I could care less about them.

>  Autotools and cross-compilers are the
> tools of choice.  

For those who which to go *outside of distro support*.

> Packaging is a convenience for users, to simplify
> handling dependencies.

Which, in Debian's case - it does superbly.

> 
> From an upstream perspective, increased use of systemd, just makes lives
> more difficult -

Only if systemd was the only choice. It's not.

 once can no longer count on simply including a set of
> sysvinit scripts with confidence that they'll just work. At a minimum,
> they have to start worrying about incompatibilities between their init
> scripts and systemd's implementation of sysvinit.  Beyond that, they
> have to either rely on packagers, or start including systemd service
> files.  That just strikes me as a less desirable situation - more things
> to go wrong, more people and steps in the delivery chain.

I believe the logic behind your fears is wrong.

> 
> <snip>
> 
> Miles Fidelman
> 
> 


Kind regards

--

"If pro means in favour of, and con means not in favour of...
what is the opposite of constitution?"