Re: Michael Biebl 2018-03-02 <c4dd387a-016b-6524-cab4-da7bef565...@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@.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
