[systemd-devel] How to mount NFS prior to start postgresql from this volume

[Lennart Poettering]

On Fri, 01.07.16 14:44, wolfgang.wagner at riwa-gis.de (wolfgang.wagner at riwa-gis.de) wrote:

> My postgresql.service is this:  (unmodified file)
> [Unit]
> Description=PostgreSQL RDBMS
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/true
> ExecReload=/bin/true
> RemainAfterExit=on
> 
> [Install]
> WantedBy=multi-user.target

Hmm, not sure how postgresql is setup on your distro, but the above
unit file is pretty much a nop. How does your postgresql at .service
template unit file look like though?

Normally, if you want a service to run only after all NFS mounts are
in place, add an ordering dependency towards remote-fs.target to
it. Specifically: add a drop-in file
/etc/systemd/system/postgresql at .service.d/50-nfs.conf and write into
it:

<snip>
[Unit]
After=remote-fs.target
</snip>

> Maybe it is caused by this  (ssome lines before in journalctl-log):
> Jul 01 16:09:57 postgis1 systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service f
> Jul 01 16:09:57 postgis1 systemd[1]: Found ordering cycle on basic.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on sysinit.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on network-online.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on vmware-tools.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on basic.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Breaking ordering cycle by deleting job rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Job rpcbind.service/start deleted to break ordering cycle starting with basic.target/start

So, there's an ordering cycle: basic.target → sysinit.target →
rpcbind.service → network-line.target → vmware-tools.service →
basic.target. Reach each arror in this as "After=" ordering.

This suggests some borkage probably either in vmware-tools.service or
in rpcbind.service. Not sure why the latter wants to be ordered until
after the network is fully up, and not sure why the former wants to be
ordered before that... The key of the issue though is that
vmware-tools is declared a late-boot service (since it wants to be
ordered after basic.target) while rpcbind.service is declared an early
boot service (since it wants to be ordered before basic.target), but
of course that cannot be fulfilled, given both their request for
ordering towards network-online.target.

Consider asking your distro for help, or vmware. This is really
borkage in those unit files. Most likely rpcbind is most broken
service in this regard.

Lennart

-- 
Lennart Poettering, Red Hat