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

[Christoph Berg]

Re: Michael Biebl 2018-03-02 <c4dd387a-016b-6524-cab4-da7bef5650c1 at debian.org>
> > 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:
> > 
> 
> 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 at .service
[Unit]
Description=PostgreSQL Cluster %i
ConditionPathExists=/etc/postgresql/%I/postgresql.conf

Starting postgresql at 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