Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Am 03.03.2018 um 09:57 schrieb Christoph Berg:
> Re: Michael Biebl 2018-03-03 <87ba8f59-ec84-d3ed-c162-1fd849256...@debian.org>
>> Well, I don't think those two cases are the same and as such should be
>> treated equally by systemd.
>> I see typoing the template name more like adding a typo to
>> ExecStart=/sbin/foobard /etc/typo_in_file_name
>> In this case foobard would most likely fail to start and systemd would
>> mark the service as failed. This is more comparable to your case,
>> because the template name is passed as a config option to the service
> 
> In that case the error is in a config file, and marking the service as
> faulty makes sense. In the unit@instancetypo case, there's nothing
> wrong with the system.
> 
> (Maybe I'm overzealous here, but my first experience with systemd when
> it became default in Debian was setting up postgresql@.service, and
> the fact that @typo was sticking around permanently was really
> freaking me out, so I was glad I figured a way to avoid it. Iirc
> "systemctl reset-failed" was only invented later.)

I think it would be better to just show the error.
Hiding those error messages makes it hard do diagnose that there was a
typo in the first place.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Control: reassign -1 postgresql

Am 03.03.2018 um 11:16 schrieb Christoph Berg:
> Re: To Michael Biebl 2018-03-03 <20180303085701.ga9...@msg.df7cb.de>
>> In that case the error is in a config file, and marking the service as
>> faulty makes sense. In the unit@instancetypo case, there's nothing
>> wrong with the system.
> 
> Fwiw, it looks like AssertPathExists=/etc/postgresql/%I/postgresql.conf
> would do what I'm looking for. I'll play with that a bit and report
> back.

Reassigning this to postgresql. Suppressing the error message is
apparently a deliberate choice made by the package maintainer.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Christoph Berg]

Re: To Michael Biebl 2018-03-03 <20180303085701.ga9...@msg.df7cb.de>
> In that case the error is in a config file, and marking the service as
> faulty makes sense. In the unit@instancetypo case, there's nothing
> wrong with the system.

Fwiw, it looks like AssertPathExists=/etc/postgresql/%I/postgresql.conf
would do what I'm looking for. I'll play with that a bit and report
back.

Christoph

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Christoph Berg]

Re: Michael Biebl 2018-03-03 <87ba8f59-ec84-d3ed-c162-1fd849256...@debian.org>
> Well, I don't think those two cases are the same and as such should be
> treated equally by systemd.
> I see typoing the template name more like adding a typo to
> ExecStart=/sbin/foobard /etc/typo_in_file_name
> In this case foobard would most likely fail to start and systemd would
> mark the service as failed. This is more comparable to your case,
> because the template name is passed as a config option to the service

In that case the error is in a config file, and marking the service as
faulty makes sense. In the unit@instancetypo case, there's nothing
wrong with the system.

(Maybe I'm overzealous here, but my first experience with systemd when
it became default in Debian was setting up postgresql@.service, and
the fact that @typo was sticking around permanently was really
freaking me out, so I was glad I figured a way to avoid it. Iirc
"systemctl reset-failed" was only invented later.)

Christoph

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Am 02.03.2018 um 20:48 schrieb Christoph Berg:

> "systemctl start foo.service" throws an error, but does not mark
> foo.service as failed.
> 
> If "systemctl start postgresql@foo.service" would not have
> ConditionFileExists, it would permanently be marked as failed (until
> "systemctl reset-failed").
> 
> Both should behave the same in the sense that typoing the service name
> on start shouldn't leave the system in a degraded state. (It would be
> nice if "systemctl start postgresql@foo.service" would throw a
> one-time error, but it doesn't look like that could be achieved.)

Well, I don't think those two cases are the same and as such should be
treated equally by systemd.
I see typoing the template name more like adding a typo to
ExecStart=/sbin/foobard /etc/typo_in_file_name
In this case foobard would most likely fail to start and systemd would
mark the service as failed. This is more comparable to your case,
because the template name is passed as a config option to the service


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Christoph Berg]

Re: Michael Biebl 2018-03-02 
> >>> I agree that it is not helpful that it doesn't raise an error here,
> >>> but I think it is working as intended by systemd. Or should we rather
> >>> be using AssertFileExists here? But starting the non-existing "foo"
> >>> service doesn't put "foo" into a permanent error state either.
> >>
> >> Why not just drop the Condition altogether?
> >> This way you'd get a proper error message from posgresql, and it would
> >> be easier to diagnose what's going wrong?
> > 
> > For the same reason that "systemctl start nonexisting.service" doesn't
> > permanently leave nonexisting.service in a error state that is visible
> > e.g. via "systemctl". I'd think that would be worse.
> 
> Not sure what you mean by that. Can you elaborate?

"systemctl start foo.service" throws an error, but does not mark
foo.service as failed.

If "systemctl start postgresql@foo.service" would not have
ConditionFileExists, it would permanently be marked as failed (until
"systemctl reset-failed").

Both should behave the same in the sense that typoing the service name
on start shouldn't leave the system in a degraded state. (It would be
nice if "systemctl start postgresql@foo.service" would throw a
one-time error, but it doesn't look like that could be achieved.)

Christoph

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Am 02.03.2018 um 17:23 schrieb Christoph Berg:
> Re: Michael Biebl 2018-03-02 <4c3431e8-36e3-d86b-4bb8-1f99eaa38...@debian.org>
>> Am 02.03.2018 um 13:45 schrieb Christoph Berg:
>>
>>> I agree that it is not helpful that it doesn't raise an error here,
>>> but I think it is working as intended by systemd. Or should we rather
>>> be using AssertFileExists here? But starting the non-existing "foo"
>>> service doesn't put "foo" into a permanent error state either.
>>
>> Why not just drop the Condition altogether?
>> This way you'd get a proper error message from posgresql, and it would
>> be easier to diagnose what's going wrong?
> 
> For the same reason that "systemctl start nonexisting.service" doesn't
> permanently leave nonexisting.service in a error state that is visible
> e.g. via "systemctl". I'd think that would be worse.

Not sure what you mean by that. Can you elaborate?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Christoph Berg]

Re: Michael Biebl 2018-03-02 <4c3431e8-36e3-d86b-4bb8-1f99eaa38...@debian.org>
> Am 02.03.2018 um 13:45 schrieb Christoph Berg:
> 
> > I agree that it is not helpful that it doesn't raise an error here,
> > but I think it is working as intended by systemd. Or should we rather
> > be using AssertFileExists here? But starting the non-existing "foo"
> > service doesn't put "foo" into a permanent error state either.
> 
> Why not just drop the Condition altogether?
> This way you'd get a proper error message from posgresql, and it would
> be easier to diagnose what's going wrong?

For the same reason that "systemctl start nonexisting.service" doesn't
permanently leave nonexisting.service in a error state that is visible
e.g. via "systemctl". I'd think that would be worse.

Christoph

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Am 02.03.2018 um 13:45 schrieb Christoph Berg:

> I agree that it is not helpful that it doesn't raise an error here,
> but I think it is working as intended by systemd. Or should we rather
> be using AssertFileExists here? But starting the non-existing "foo"
> service doesn't put "foo" into a permanent error state either.

Why not just drop the Condition altogether?
This way you'd get a proper error message from posgresql, and it would
be easier to diagnose what's going wrong?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Christoph Berg]

Re: Michael Biebl 2018-03-02 
> > I think the problem is postgres has:
> > 
> > # -: ignore startup failure (recovery might take arbitrarily long)
> > # the actual pg_ctl timeout is configured in pg_ctl.conf
> > ExecStart=-/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start
> > 
> > If postgres would report the error back to systemd, it would at least
> > tell you that.
> > 
> > getty@.service suffers from the same issue. Other units do not:
> > 
> 
> You are spot on, Felipe. Afaics, systemd works as designed.
> Question is, whether this bug report should be assigned to postgresql to
> not use '-'.

The problem is elsewhere:

# /lib/systemd/system/postgresql@.service
[Unit]
Description=PostgreSQL Cluster %i
ConditionPathExists=/etc/postgresql/%I/postgresql.conf

Starting postgresql@foo-bar.service requires
/etc/postgresql/foo/bar/postgresql.conf to exist. Otherwise, it won't
do anything.

   ConditionArchitecture=, ConditionVirtualization=,
   ConditionHost=, ConditionKernelCommandLine=,
   ConditionSecurity=, ConditionCapability=, ConditionACPower=,
   ConditionNeedsUpdate=, ConditionFirstBoot=,
   ConditionPathExists=, ConditionPathExistsGlob=,
   ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=,
   ConditionPathIsMountPoint=, ConditionPathIsReadWrite=,
   ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=,
   ConditionFileIsExecutable=, ConditionUser=, ConditionGroup=
   Before starting a unit, verify that the specified condition
   is true. If it is not true, the starting of the unit will
   be (mostly silently) skipped, however all ordering
   dependencies of it are still respected. A failing condition
   will not result in the unit being moved into a failure
   state. The condition is checked at the time the queued
   start job is to be executed. Use condition expressions in
   order to silently skip units that do not apply to the local
   running system, for example because the kernel or runtime
   environment doesn't require its functionality. Use the
   various AssertArchitecture=, AssertVirtualization=, ...
   options for a similar mechanism that puts the unit in a
   failure state and logs about the failed check (see below).

I agree that it is not helpful that it doesn't raise an error here,
but I think it is working as intended by systemd. Or should we rather
be using AssertFileExists here? But starting the non-existing "foo"
service doesn't put "foo" into a permanent error state either.

Christoph

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Am 01.03.2018 um 20:35 schrieb Felipe Sateler:
> On Thu, Mar 1, 2018 at 2:46 PM, Michael Biebl  wrote:
>> Control: tags -1 moreinfo unreproducible
>>
>> Am 01.03.2018 um 16:00 schrieb Martin von Wittich:
>>> Hi Michael,
>>>
>>> On Thu, 1 Mar 2018 15:10:26 +0100 Michael Biebl  wrote:
 I can't reproduce this, neither on v237 nor on v232:

 # systemctl stop postgresql@does-not-exist
 Failed to stop postgresql@does-not-exist.service: Unit
 postgresql@does-not-exist.service not loaded.

 # systemctl start postgresql@does-not-exist
 Failed to start postgresql@does-not-exist.service: Unit
 postgresql@does-not-exist.service not found.

 # systemctl restart postgresql@does-not-exist
 Failed to restart postgresql@does-not-exist.service: Unit
 postgresql@does-not-exist.service not found.
>>>
>>> Do you have a postgresql template installed (should be the case when you
>>> have a postgresql-9.{4,6} (jessie/stretch) server package installed)? If
>>> not, try another template, maybe getty (I hope that's available on every
>>> system, would make reproducing this a lot easier):
>>
>> Hm, right. I completely missed the part about "valid-template", and no,
>> I didn't have postgresql@.service.
>>
>> But I'm not sure if what you are seeing is actually a bug. A templated
>> service does not necessarily need a representation on disk. It is very
>> much possible, that you simply want to pass a command flag to a daemon
>> for example.
>>
>> So systemd will happily start/stop/restart such a noop in your case. The
>> only case where it fails is, on a reload, because there wasn't actually
>> a process running which could be reloaded.
>>
>> Sounds a bit strange but is imho consistent.
>>
> 
> I think the problem is postgres has:
> 
> # -: ignore startup failure (recovery might take arbitrarily long)
> # the actual pg_ctl timeout is configured in pg_ctl.conf
> ExecStart=-/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start
> 
> If postgres would report the error back to systemd, it would at least
> tell you that.
> 
> getty@.service suffers from the same issue. Other units do not:
> 

You are spot on, Felipe. Afaics, systemd works as designed.
Question is, whether this bug report should be assigned to postgresql to
not use '-'.

CCing Christoph for his input.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Felipe Sateler]

On Thu, Mar 1, 2018 at 2:46 PM, Michael Biebl  wrote:
> Control: tags -1 moreinfo unreproducible
>
> Am 01.03.2018 um 16:00 schrieb Martin von Wittich:
>> Hi Michael,
>>
>> On Thu, 1 Mar 2018 15:10:26 +0100 Michael Biebl  wrote:
>>> I can't reproduce this, neither on v237 nor on v232:
>>>
>>> # systemctl stop postgresql@does-not-exist
>>> Failed to stop postgresql@does-not-exist.service: Unit
>>> postgresql@does-not-exist.service not loaded.
>>>
>>> # systemctl start postgresql@does-not-exist
>>> Failed to start postgresql@does-not-exist.service: Unit
>>> postgresql@does-not-exist.service not found.
>>>
>>> # systemctl restart postgresql@does-not-exist
>>> Failed to restart postgresql@does-not-exist.service: Unit
>>> postgresql@does-not-exist.service not found.
>>
>> Do you have a postgresql template installed (should be the case when you
>> have a postgresql-9.{4,6} (jessie/stretch) server package installed)? If
>> not, try another template, maybe getty (I hope that's available on every
>> system, would make reproducing this a lot easier):
>
> Hm, right. I completely missed the part about "valid-template", and no,
> I didn't have postgresql@.service.
>
> But I'm not sure if what you are seeing is actually a bug. A templated
> service does not necessarily need a representation on disk. It is very
> much possible, that you simply want to pass a command flag to a daemon
> for example.
>
> So systemd will happily start/stop/restart such a noop in your case. The
> only case where it fails is, on a reload, because there wasn't actually
> a process running which could be reloaded.
>
> Sounds a bit strange but is imho consistent.
>

I think the problem is postgres has:

# -: ignore startup failure (recovery might take arbitrarily long)
# the actual pg_ctl timeout is configured in pg_ctl.conf
ExecStart=-/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start

If postgres would report the error back to systemd, it would at least
tell you that.

getty@.service suffers from the same issue. Other units do not:

% sudo systemctl start systemd-nspawn@does-not-exist
Job for systemd-nspawn@does-not-exist.service failed because the
control process exited with error code.
See "systemctl status systemd-nspawn@does-not-exist.service" and
"journalctl -xe" for details.

-- 

Saludos,
Felipe Sateler

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Control: tags -1 moreinfo unreproducible

Am 01.03.2018 um 16:00 schrieb Martin von Wittich:
> Hi Michael,
> 
> On Thu, 1 Mar 2018 15:10:26 +0100 Michael Biebl  wrote:
>> I can't reproduce this, neither on v237 nor on v232:
>>
>> # systemctl stop postgresql@does-not-exist
>> Failed to stop postgresql@does-not-exist.service: Unit
>> postgresql@does-not-exist.service not loaded.
>>
>> # systemctl start postgresql@does-not-exist
>> Failed to start postgresql@does-not-exist.service: Unit
>> postgresql@does-not-exist.service not found.
>>
>> # systemctl restart postgresql@does-not-exist
>> Failed to restart postgresql@does-not-exist.service: Unit
>> postgresql@does-not-exist.service not found.
> 
> Do you have a postgresql template installed (should be the case when you
> have a postgresql-9.{4,6} (jessie/stretch) server package installed)? If
> not, try another template, maybe getty (I hope that's available on every
> system, would make reproducing this a lot easier):

Hm, right. I completely missed the part about "valid-template", and no,
I didn't have postgresql@.service.

But I'm not sure if what you are seeing is actually a bug. A templated
service does not necessarily need a representation on disk. It is very
much possible, that you simply want to pass a command flag to a daemon
for example.

So systemd will happily start/stop/restart such a noop in your case. The
only case where it fails is, on a reload, because there wasn't actually
a process running which could be reloaded.

Sounds a bit strange but is imho consistent.






-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Martin von Wittich]

Hi Michael,

On Thu, 1 Mar 2018 15:10:26 +0100 Michael Biebl  wrote:

I can't reproduce this, neither on v237 nor on v232:

# systemctl stop postgresql@does-not-exist
Failed to stop postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not loaded.

# systemctl start postgresql@does-not-exist
Failed to start postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.

# systemctl restart postgresql@does-not-exist
Failed to restart postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.


Do you have a postgresql template installed (should be the case when you 
have a postgresql-9.{4,6} (jessie/stretch) server package installed)? If 
not, try another template, maybe getty (I hope that's available on every 
system, would make reproducing this a lot easier):


stable.iserv.eu ~ # systemctl stop getty@does-not-exist
stable.iserv.eu ~ #

If the template itself doesn't exist, this leads to the expected error 
message:


stable.iserv.eu ~ # systemctl stop does-not-exist@does-not-exist
Failed to stop does-not-exist@does-not-exist.service: Unit 
does-not-exist@does-not-exist.service not loaded.


To ensure that this issue is not caused by our custom server 
configuration, I also tried to reproduce the issue on my Ubuntu 17.10 
client:


martin@dogmeat ~ % systemd --version
systemd 234
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS 
+KMOD -IDN2 +IDN default-hierarchy=hybrid


martin@dogmeat ~ % sudo systemctl restart getty@does-not-exist
martin@dogmeat ~ %

--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 01.03.2018 um 13:24 schrieb Martin von Wittich:
> Package: systemd
> Version: 232-25+deb9u1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> the following commands unexpectedly do not print any error messages or
> return non-zero exit codes:
> 
> martin.mein-iserv.de ~ # systemctl stop postgresql@does-not-exist
> martin.mein-iserv.de ~ # systemctl start postgresql@does-not-exist
> martin.mein-iserv.de ~ # systemctl restart postgresql@does-not-exist
> 

I can't reproduce this, neither on v237 nor on v232:

# systemctl stop postgresql@does-not-exist
Failed to stop postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not loaded.

# systemctl start postgresql@does-not-exist
Failed to start postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.

# systemctl restart postgresql@does-not-exist
Failed to restart postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Martin von Wittich]

Package: systemd
Version: 232-25+deb9u1
Severity: normal
Tags: upstream

Dear Maintainer,

the following commands unexpectedly do not print any error messages or
return non-zero exit codes:

martin.mein-iserv.de ~ # systemctl stop postgresql@does-not-exist
martin.mein-iserv.de ~ # systemctl start postgresql@does-not-exist
martin.mein-iserv.de ~ # systemctl restart postgresql@does-not-exist

reload on the other hand does:

martin.mein-iserv.de ~ # systemctl reload postgresql@does-not-exist; echo $?
postgresql@does-not-exist.service is not active, cannot reload.
1

martin.mein-iserv.de ~ # systemctl stop does-not-exist
Failed to stop does-not-exist.service: Unit does-not-exist.service not loaded.
martin.mein-iserv.de ~ # systemctl restart does-not-exist
Failed to restart does-not-exist.service: Unit does-not-exist.service not found.
martin.mein-iserv.de ~ # systemctl restart does-not-exist
Failed to restart does-not-exist.service: Unit does-not-exist.service not found.
martin.mein-iserv.de ~ # systemctl reload does-not-exist
Failed to reload does-not-exist.service: Unit does-not-exist.service not found.

-- Package-specific info:

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1
ii  libc6   2.24-11+deb9u1
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u2
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 232-25+deb9u1
ii  mount   2.29.2-1
ii  procps  2:3.3.12-3
ii  util-linux  2.29.2-1

Versions of packages systemd recommends:
ii  dbus1.10.24-0+deb9u1
ii  libpam-systemd  232-25+deb9u1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u1

-- no debconf information