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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev