On Fri, 01.07.16 14:44, wolfgang.wag...@riwa-gis.de (wolfgang.wag...@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@.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@.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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
