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
Description=PostgreSQL Cluster %i

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.


Reply via email to