[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

Can't say that I've ever come across it used on this list.

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.

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?

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

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

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

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.

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

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. 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, not "take it upstream."

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
- for Windows, it's installer files
- for *nix, I use packaged stuff for all the routine, environmental stuff (libraries, tools, utilities, and stuff), while more often than not building critical applications from upstream source (.tar.gz source files are a package)

From this perspective, systemd seems to be creating instabilities, reducing flexibility, and generally making Debian (and many other distros) far less hospitable platforms. It's a headache I don't need, for zero benefit to our environment.
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. Having to package, or be packaged for a specific environment is a major inconvenience - especially when said packaging relies on human beings. From an upstream point of view, the goal is to develop for the least-common-denominator that's supported across the broadest range platforms used by one's target users.

As I see it, a critical consideration for platform builders is to make life easy for upstream, not the other way around.

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.

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. Autotools and cross-compilers are the tools of choice. Packaging is a convenience for users, to simplify handling dependencies.

From an upstream perspective, increased use of systemd, just makes lives more difficult - 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.


Miles Fidelman

In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

Reply to: