Upgrading a model to 2.3.7 caused an unexpected outage when PostgreSQL was shutdown. The charm thankfully recovered when the first hook was run post-upgrade, so the outage was limited to 60 seconds.
It seems that upgradin jujud also sends kill signals to all processes spawned by its subprocesses, such as the PostgreSQL daemon started by running 'pg_ctlcluster 9.5 main start' from a hook.
We think everything linked by the cgroup gets affected, so even though pg_ctlcluster switches user id and group it is killed:
To reproduce, deploy a cs:postgresql unit with an older version of juju, and upgrade to 2.3.7. /var/log/postgresql-9.5-main.log will show the shutdown signal being received, and starting up again when the next hook is run.
systemd services seem unaffected, so pgbouncer (started by systemctl start pgbouncer) did not get signaled.
Upgrading a model to 2.3.7 caused an unexpected outage when PostgreSQL was shutdown. The charm thankfully recovered when the first hook was run post-upgrade, so the outage was limited to 60 seconds.
It seems that upgradin jujud also sends kill signals to all processes spawned by its subprocesses, such as the PostgreSQL daemon started by running 'pg_ctlcluster 9.5 main start' from a hook.
We think everything linked by the cgroup gets affected, so even though pg_ctlcluster switches user id and group it is killed:
# cat /proc/4776/cgroup # The root PostgreSQL pid cpuacct: /system. slice/jujud- unit-postgresql -1.service /system. slice/jujud- unit-postgresql -1.service /system. slice/jujud- unit-postgresql -1.service /system. slice/jujud- unit-postgresql -1.service net_prio: / /system. slice/jujud- unit-postgresql -1.service systemd: /system. slice/jujud- unit-postgresql -1.service
11:cpu,
10:pids:
9:devices:
8:perf_event:/
7:memory:
6:freezer:/
5:net_cls,
4:hugetlb:/
3:blkio:
2:cpuset:/
1:name=
To reproduce, deploy a cs:postgresql unit with an older version of juju, and upgrade to 2.3.7. /var/log/ postgresql- 9.5-main. log will show the shutdown signal being received, and starting up again when the next hook is run.
systemd services seem unaffected, so pgbouncer (started by systemctl start pgbouncer) did not get signaled.