search for: sd_listen_fd

...indly use SACT_VAR_PUSH(, > > h->sact_name,). That has ripple effects earlier in the series to > > support those semantics. > > For understanding your point, I have had to read up on systemd socket > activation: > > https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html > > Let me quote a part: > > > Under specific conditions, the following automatic file descriptor names are returned: > > > > [...] > > "unknown" -- The process received no name for the specific file > > descriptor from the...

...based activation]) + fi + ] +) + use_stack_protector=1 use_toolchain_hardening=1 AC_ARG_WITH([stackprotect], @@ -3376,6 +3386,18 @@ AC_CHECK_LIB([crypt], [crypt], [ AC_CHECK_FUNCS([crypt]) LIBS="$saved_LIBS" +if test "x$systemd" == "xyes" ; then + # Check for sd_listen_fds in libsystemd for socket activation + saved_LIBS="$LIBS" + AC_CHECK_LIB([systemd], [sd_listen_fds], [ + LIBS="-lsystemd $LIBS" + AGENTLIBS="-lsystemd $AGENTLIBS" + ]) + AC_CHECK_FUNCS([sd_listen_fds]) + LIBS="$saved_LIBS" + AC_SUBST([AGENTLIBS]) +fi + # C...

...act_name != NULL)', and just blindly use SACT_VAR_PUSH(, > h->sact_name,). That has ripple effects earlier in the series to > support those semantics. For understanding your point, I have had to read up on systemd socket activation: https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html Let me quote a part: > Under specific conditions, the following automatic file descriptor names are returned: > > [...] > "unknown" -- The process received no name for the specific file > descriptor from the service manager. > [...] I've...

...e upstream would not be interested in this patch, but >> as it may be useful on linux, I'm submitting it here. > > yeah - unfortunately libsystemd is under the LGPL and we've tried hard > to keep our license free of additional obligations. Would a version that reimplemented sd_listen_fds(3) be okay? sd_listen_fds(3) is just a convenience function. The actual protocol is independent of both libsystemd and of systemd itself. -- Sincerely, Demi Marie Obenour (she/her/hers) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB288B55FFF9C22C1...

On Thu, Mar 23, 2023 at 01:10:16PM +0100, Laszlo Ersek wrote: > When the user calls nbd_set_socket_activation_name before calling > nbd_connect_system_socket_activation, pass the name down to the server > through LISTEN_FDNAMES. This has no effect unless the new API has > been called to set the socket name to a non-empty string. > >

On Fri, 16 Jun 2023, Ronan Pigott wrote: > This adds support for systemd socket-based activation in the ssh-agent. > When using socket activation, the -a flag value must match the socket > path provided by systemd, as a sanity check. Support for this feature is > enabled by the --with-systemd configure flag. > > --- > Something tells me upstream would not be interested in

On 04 Feb (10:46:55), Daniel Kahn Gillmor wrote: > On Thu 2016-02-04 07:40:39 -0500, David Goulet wrote: > > > I would like to know if adding support for Unix socket to sshd would be a > > feature that would be consider to be added upstream? (ListenAddress). > > fwiw, i think this is a good idea, but i wouldn't implement it as an > explicit ListenAddress option:

V4 was here (incorrectly versioned on the mailing list as v3): <http://mid.mail-archive.com/20230323121016.1442655-1-lersek at redhat.com>. See the Notes section on each patch for the v5 updates. Laszlo Ersek (2): socket activation: generalize environment construction socket activation: set LISTEN_FDNAMES Richard W.M. Jones (2): common/include: Copy ascii-ctype functions from nbdkit