Description

Hi,

This is a followup ticket after triagingPostgreSQL issue.

TL;DR: Juju sendsstart event before the Juju Storage mount points are mounted.
It creates internal races. While the proper way, IMHO, is to wait for all local-fs and networks targets to be mounts and wake up charm via agent in case of those target success only.

Juju version

3.6.11

Cloud

LXD

Expected behaviour

Systemd juju-agent.service is currently starts After network only, ignoring mount targets state:

ubuntu@juju-3491b7-0:~$ systemctl cat jujud-machine-0.service[Unit]After=syslog.targetAfter=network.targetAfter=systemd-user-sessions.service

While expected behavior is (at least):

After=syslog.targetAfter=network.targetRequires=network.targetAfter=local-fs.targetRequires=local-fs.targetAfter=systemd-user-sessions.service

Reproduce / Test

juju deploy postgresql --channel 16/stable # (revision 952)# wait for deploymentlxc stop juju-3491b7-0 # LXD unit/machine ID# wait for stoplxc start juju-3491b7-0

AR: postgresql will be in state(start) Data directory not attached, then it will reboot several times and became Primary
ER: postgresql will be waked up with storage attached.

Notes & References

canonical/postgresql-operator#1250