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

[Felipe Sateler]

On Thu, Mar 1, 2018 at 2:46 PM, Michael Biebl <biebl at debian.org> 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 <biebl at debian.org> wrote:
>>> I can't reproduce this, neither on v237 nor on v232:
>>>
>>> # systemctl stop postgresql at does-not-exist
>>> Failed to stop postgresql at does-not-exist.service: Unit
>>> postgresql at does-not-exist.service not loaded.
>>>
>>> # systemctl start postgresql at does-not-exist
>>> Failed to start postgresql at does-not-exist.service: Unit
>>> postgresql at does-not-exist.service not found.
>>>
>>> # systemctl restart postgresql at does-not-exist
>>> Failed to restart postgresql at does-not-exist.service: Unit
>>> postgresql at 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 at .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 at .service suffers from the same issue. Other units do not:

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

-- 

Saludos,
Felipe Sateler