openssh 7.6 and 7.7 on Oracle Linux 7 (compiled from source) doesn't start correctly with systemd

[Peter Stuge]

Damien Miller wrote:
> If it's in the code that we maintain then it's a dependency. I'm don't
> think any other definition makes sense.

I define dependency as external library or component, required at
compile- and runtime.


Emmanuel Deloget wrote:
> Not sure I should step in, but the code to deal with the user selection

What user selection?

> and to notify systemd is a dependency - even if it's compiled out. The
> fact is that you still ave to maintain it and to test it regularly.

Did you read the code I sent? It does six system calls in about 85 lines,
three of which can't fail. I wrote it exactly because something so short
is sufficient.

The existing code in OpenSSH which sends messages with ancillary data
was last touched in 2010, 8 years ago. This isn't complicated, making
a compile- and runtime dependency on libsystemd doubly undesirable.


> The problem looks like a systemd configuration error. systemd allows
> you to start a non-systemd-aware daemon. You need to look at [Service]
> / Type (notify is used for systemd-aware daemons).

The discussion isn't about the basic functionality known from sysvinit,
using init scripts or even inittab directly. sshd of course already runs
fine on many systemd systems, and it runs fine also without debian's
patch to depend on libsystemd, when only considering the bare minimum
of a service manager.

But that ignores the additional functionality offered by systemd to its
users. I think it makes sense for sshd to support that functionality if
the cost of doing so is low. I suggest that my proposed code is low cost.


The implemented API (AF_UNIX message with ancillary data) is documented
and there's no technical reason for it to change, so the maintenance burden
will likely be similar to monitor_fdpass.c - little change in 8 years.


kevin martin wrote:
> seems like remaking the wheel to me

It is, but I think avoiding the library dependency is a good reason to
do so, especially considering how little code is needed.


> would still require ongoing maintenance and testing

Did you read the code?


> If *you as the developers included the API access as a configurable option
> then *we the consumer could move to your newer codebase products sooner and
> get the enhancements that you folks work so diligently to make in your
> application which is a win-win for all of us.

You imply an obligation for developers to enable consumers to "move
to newer codebase products" in their systems - please re-read the
software license, and please remember that no such obligation exists.

Over the years I've learned that open source software only works if you
take responsibility for it yourself. If you fail to do so then you will
inevitably have a bad experience.

One way is to get a support contract (like Red Hat in this case) and
then they are of course obliged to honor that. You'll get something,
(a dependency on libsystemd) but since they too optimize for cost you
can be pretty sure that it's not the best solution - that would come
from upstream.


David Newall wrote:
> I'm old school and think systemd is an overly complicated abomination.

I agree completely that the systemd implementation and overall ambition
is overly complicated.

But the unit data model is very very good, and I think systemd is a great
improvement in service management compared to anything on Linux before.

While we argue, Windows has proper service management since the 1990s.


> The more projects that do support it, the more legitimacy it is lent.

That ship has sailed. Please think more about the role of Red Hat in
the Linux ecosystem.


Jochen Bern wrote:
> wrapper to translate as needed would seem a pragmatic solution

I consider that wrapper to be Type=forking in the service file, but
anything short of explicit notification from daemon to service manager
leaves the service manager without complete information about the state
of the daemon. That's not great.


> (*) PID file, lookup in the process table, check for a LISTEN, pattern
> match in a logfile, running a dedicated *client* executable / Nagios
> plugin / ${DAEMON}ctl tool for a test, throwing the daemon a
> SIGAREYOUWELL/shmem/semaphore/... request, you name it

Neither are both explicit and generic (across services).

I think the notify socket is a good simple solution, and one that is not
tied to systemd, I think it is worth supporting.


//Peter