[systemd-devel] Antw: [EXT] Re: Q: ypbind-systemd-pre[1756]: \nError: NIS domain not specified.\n

[Ulrich Windl]

>>> Lennart Poettering <lennart at poettering.net> schrieb am 29.05.2020 um 15:11
in
Nachricht <20200529131159.GA119402 at gardel-login>:
> On Fr, 29.05.20 08:22, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) 
> wrote:
> 
>> >>> Lennart Poettering <lennart at poettering.net> schrieb am 28.05.2020 um
22:25
>> in
>> Nachricht
>>
<24474_1590697505_5ED01E21_24474_24_1_20200528202504.GA118706 at gardel-login>:
>> > On Do, 28.05.20 15:43, Ulrich Windl (Ulrich.Windl at rz.uni‑regensburg.de)
>> wrote:
>> >
>> >> Hi!
>> >>
>> >> Monitoring the messages created when booting SLES12 SP5, I noticed
these:
>> >>
>> >> ypbind‑systemd‑pre[1756]: \nError: NIS domain not specified.\n
>> >> systemd[1]: ypbind.service: Control process exited, code=exited
status=1
>> >> systemd[1]: Failed to start NIS/YP Clients to NIS Domain Binder.
>> >> systemd[1]: ypbind.service: Unit entered failed state.
>> >> systemd[1]: ypbind.service: Failed with result 'exit‑code'.
>> >> systemd[1]: Reached target User and Group Name Lookups.
>> >>
>> >> The interesting point is that ypbind.service is disabled. So why is
>> > ypbind‑systemd‑pre complaining about NIS domain not being set?
>> >
>> > Maybe ypbind‑systemd‑pre.service has Wants= or Requires= on
>> > ybind.service?
>>
>> Neither, sorry. Or at least I could not find such.
>>
>> # systemctl status ypbind-systemd-pre
>> ● ypbind-systemd-pre.service
>>    Loaded: not-found (Reason: No such file or directory)
>>    Active: inactive (dead)
> 
> Hmm, maybe ypbind-systemd-pre is simply an ExecStartPre= command of
> your ypbind.service?

But if so, why would it be started if that service is disabled? Indeed the
service section is:
[Service]
Type=notify
NotifyAccess=all
EnvironmentFile=-/etc/sysconfig/ypbind
ExecStartPre=/usr/lib/ypbind/ypbind-systemd-pre
ExecStartPost=/usr/lib/ypbind/ypbind-systemd-post
ExecStart=/usr/lib/ypbind/ypbind-systemd-exec
ExecStopPost=/bin/sh -c "/bin/rm -f /var/yp/binding/* /var/run/ypbind.pid"
ExecReload=/bin/kill -HUP $MAINPID

(And the service is still disabled)
# systemctl status ypbind.service
● ypbind.service - NIS/YP Clients to NIS Domain Binder
   Loaded: loaded (/usr/lib/systemd/system/ypbind.service; disabled; vendor
preset: disabled)
   Active: inactive (dead)
     Docs: man:ypbind(8)


So some script may have started the service manually. I wonder: How
complicated and efficient would it be if "systemctl status" would output the
reason (e.g.: "manual|dependency") for the last service start (or maybe even
stop)?

Regards,
Ulrich

> 
>> # systemctl status ypbind
>> ● ypbind.service - NIS/YP Clients to NIS Domain Binder
>>    Loaded: loaded (/usr/lib/systemd/system/ypbind.service; disabled;
vendor
>> preset: disabled)
>>    Active: inactive (dead)
>>      Docs: man:ypbind(8)
>>
>> BTW: Is it a bug that "systemctl show no-such-service" does not signal any
>> error (besides maybe ``LoadError=org.freedesktop.DBus.Error.FileNotFound
"No
>> such file or directory"'')?
> 
> No, "systemctl show" is supposed to be a relatively low-level command
> that shows you what systemd knows. And that can be quite a bit even
> for units that aren't properly loaded. That's because other units can
> have Wants= or After= or Before= deps on a non-existing unit just fine
> (they are weak dependencies after all), and it is interesting to know
> what precisely those are. For example, in your case it might be
> interesting to do "systemctl show" on the ypbind.service unit to check
> the WantedBy=, RequiredBy= deps it has, which tell you which other
> units might be causing it to be pulled in.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin