Bug#960672: [Pkg-sssd-devel] Bug#960672: sssd: Update service file
On 1.7.2020 11.57, Jörg Behrmann wrote:
> On 01.07.20 09:14, Timo Aaltonen wrote:
>> I'm not doing this, instead I'll add DEBUG_LOGGER template to
>> /etc/default/sssd and mention that DAEMON_OPTS is only used for the
>> initscript.
>>
>
> I would like to argue, that the total removal of the coupling of the
> service file and /etc/defaults/sssd might be the better way forward.
>
> The current state is that /etc/defaults/sssd has no effect on
> sssd.service. I don't think it's a good idea to introduce it now, since
> it's a hidden layer of configuration that cannot be accessed via
> `systemctl cat`.
>
> It's perfectly fine for init scripts to use /etc/defaults, as there is
> no better mechanism to alter configuration, but for systemd unit files
> drop-ins are far superior, since `systemctl cat` aggregates them,
> shifting the burden of piecing together the configuration away from admins.
>
> Furthermore, using drop-ins in /lib/systemd/system/sssd.service.d would
> allow to carry Debian changes to the default config in files that could
> be changed atomically on updates without interfering with locally
> supplied changes.
Feel free to suggest that upstream then, they still use sysconfig for
the daemon configuration, and expect us to have /etc/default/sssd, as
shown in the commit that introduced DEBUG_LOGGER:
commit a7277fecf7a65ab6c83b36f009c558cdfbf997d2
Author: Lukas Slebodnik
Date: Mon Oct 23 18:03:46 2017 +0200
SYSTEMD: Replace parameter --debug-to-files with ${DEBUG_LOGGER}
Users can set variable DEBUG_LOGGER in environment files
(/etc/sysconfig/sssd or /etc/default/sssd; depending on the
distribution)
to override default logging to files.
e.g.
DEBUG_LOGGER=--logger=stderr
DEBUG_LOGGER=--logger=journald
Resolves:
https://pagure.io/SSSD/sssd/issue/3433
--
t
signature.asc
Description: OpenPGP digital signature
Bug#960672: [Pkg-sssd-devel] Bug#960672: sssd: Update service file
On 01.07.20 09:14, Timo Aaltonen wrote: > I'm not doing this, instead I'll add DEBUG_LOGGER template to > /etc/default/sssd and mention that DAEMON_OPTS is only used for the > initscript. > I would like to argue, that the total removal of the coupling of the service file and /etc/defaults/sssd might be the better way forward. The current state is that /etc/defaults/sssd has no effect on sssd.service. I don't think it's a good idea to introduce it now, since it's a hidden layer of configuration that cannot be accessed via `systemctl cat`. It's perfectly fine for init scripts to use /etc/defaults, as there is no better mechanism to alter configuration, but for systemd unit files drop-ins are far superior, since `systemctl cat` aggregates them, shifting the burden of piecing together the configuration away from admins. Furthermore, using drop-ins in /lib/systemd/system/sssd.service.d would allow to carry Debian changes to the default config in files that could be changed atomically on updates without interfering with locally supplied changes. signature.asc Description: OpenPGP digital signature
Bug#960672: [Pkg-sssd-devel] Bug#960672: sssd: Update service file
On 15.5.2020 12.43, Jörg Behrmann wrote: > Package: sssd > Version: 1.16.3-3.2 > Severity: normal > Tags: patch > > The service file for sssd seems to be the upstream one, but on Debian it has > some minor issues: > > 1. PIDFile is set to /var/run/sssd.pid via PIDFile=@pidpath@/sssd.pid during > the >build, but systemd-analyze complains > >/lib/systemd/system/sssd.service:13: PIDFile= references a path below > legacy directory /var/run/, updating /var/run/sssd.pid → /run/sssd.pid; > please update the unit file accordingly. > >The path is automatically updated, but it does produce unnecessary logspam. > >The configure script seems to have an option --with-pid-path to change > this. this is done in git > 2. The EnvironmentFile is set to -/etc/default/sssd, but said file says that > it >is only used for /etc/init.d/sssd and its DAEMON_OPTS, that are thankfully >unused in the service file, would daemonize sssd in contradiction to the >explicit foreground option in ExecStart and also use the deprecated >--debug-to-files option (via its shorthand -f). > >It would be best to just remove the line, although this would need to be > done >in all sssd service files. > > 3. The DEBUG_LOGGER environment variable should be unnecessary, when all sssd >services are socket activated, and --logger could be set on the ExecStart >line, making the configuration clearer. > > Attached is how the sssd.service file could look. I do understand, though, > that > all the service files for the socket activated mode of service would need to > be > changed as well. I would do the busy work if needed. I'm not doing this, instead I'll add DEBUG_LOGGER template to /etc/default/sssd and mention that DAEMON_OPTS is only used for the initscript. -- t
Bug#960672: sssd: Update service file
Package: sssd Version: 1.16.3-3.2 Severity: normal Tags: patch The service file for sssd seems to be the upstream one, but on Debian it has some minor issues: 1. PIDFile is set to /var/run/sssd.pid via PIDFile=@pidpath@/sssd.pid during the build, but systemd-analyze complains /lib/systemd/system/sssd.service:13: PIDFile= references a path below legacy directory /var/run/, updating /var/run/sssd.pid → /run/sssd.pid; please update the unit file accordingly. The path is automatically updated, but it does produce unnecessary logspam. The configure script seems to have an option --with-pid-path to change this. 2. The EnvironmentFile is set to -/etc/default/sssd, but said file says that it is only used for /etc/init.d/sssd and its DAEMON_OPTS, that are thankfully unused in the service file, would daemonize sssd in contradiction to the explicit foreground option in ExecStart and also use the deprecated --debug-to-files option (via its shorthand -f). It would be best to just remove the line, although this would need to be done in all sssd service files. 3. The DEBUG_LOGGER environment variable should be unnecessary, when all sssd services are socket activated, and --logger could be set on the ExecStart line, making the configuration clearer. Attached is how the sssd.service file could look. I do understand, though, that all the service files for the socket activated mode of service would need to be changed as well. I would do the busy work if needed. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages sssd depends on: ii python3-sss 1.16.3-3.2 ii sssd-ad 1.16.3-3.2 ii sssd-common 1.16.3-3.2 ii sssd-ipa 1.16.3-3.2 ii sssd-krb51.16.3-3.2 ii sssd-ldap1.16.3-3.2 ii sssd-proxy 1.16.3-3.2 sssd recommends no packages. sssd suggests no packages. -- no debconf information [Unit] Description=System Security Services Daemon # SSSD must be running before we permit user sessions Before=systemd-user-sessions.service nss-user-lookup.target Wants=nss-user-lookup.target [Service] ExecStart=/usr/sbin/sssd -i --logger=files Type=notify NotifyAccess=main PIDFile=/run/sssd.pid [Install] WantedBy=multi-user.target
