Your message dated Thu, 14 Feb 2019 17:44:31 -0500
with message-id <[email protected]>
and subject line Re: Bug#922082: src:systemd: please package a minimal build of
systemd-socket-activate separately
has caused the Debian Bug report #922082,
regarding src:systemd: please package a minimal build of
systemd-socket-activate separately
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
922082: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922082
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: src:systemd
Version: 240-5
Severity: wishlist
More daemons are beginning to offer systemd-style socket activation,
which is a very nice feature for security and isolation.
However, those daemons are difficult to run on non-systemd systems, so
most upstream daemon authors continue to ship a lot of
non-socket-activated code (opening sockets, dropping privileges, etc),
much of which is buggy.
If those non-systemd systems had a simple-to-install socket activation
wrapper, then we could convince the daemons to drop their
non-socket-activated codepaths, and encourage them to launch their
daemons something like this:
systemd-socket-activate -l $portnum -- \
runuser -u special-user -- \
daemon-command daemonarg1 daemonarg2
So what i'd like to see is minimalist systemd-socket-activate,
packaged and installable separately.
The current systemd-socket-activate isn't well-tuned for that -- it
links to libsystemd-shared-240.so -- but if we could build it without
that linkage (or statically-linked?), i think it would be useful to
help convince daemon upstreams to reduce their code complexity.
--dkg
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (200,
'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Tue 2019-02-12 09:10:57 +0100, Ansgar wrote:
> Maybe a separate implementation (like opentmpfiles for tmpfiles) would
> be a better approach?
Yep, i see your point. I've now filed https://bugs.debian.org/922353 --
an ITP of a simple python3 implementation of the sd_listen_fds(3)
convention that should provide something similar, so i'm closing this
bug report.
I welcome feedback on the "socket-activate" implementation from anyone
interested in encouraging more widespread development of simple,
socket-activated services.
--dkg
signature.asc
Description: PGP signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
