systemd.bbclass: restart service in postinst, not start
PATCH 1/1 systemd.bbclass: restart service in postinst, not start
When upgrading packages it's possible that the service is already running because opkg doesn't actually execute the prerm hooks on upgrades, which is where the service should be stopped.
Handle this case by restarting in postinst instead of starting. If the service isn't already running then this doesn't make a difference, but if it is running then the service will be restarted.
[ YOCTO #4213 ]
--- meta/classes/systemd.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/systemd.bbclass +1 -1
@@ -31,7 +31,7 @@ if type systemctl >/dev/null 2>/dev/null; then systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE} if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then - systemctl start ${SYSTEMD_SERVICE} + systemctl restart ${SYSTEMD_SERVICE} fi fi }
Signature · 1 line
1.7.10.4
Op 9 apr. 2013, om 17:48 heeft Ross Burton <[email protected]> het volgende geschreven:
Quoted 7 lines
When upgrading packages it's possible that the service is already running because opkg doesn't actually execute the prerm hooks on upgrades, which is where the service should be stopped.
Handle this case by restarting in postinst instead of starting. If the service isn't already running then this doesn't make a difference, but if it is running then the service will be restarted.
In the specific case of upgrades you'll need to add a
systemctl --system daemon-reload
to catch changed unit files as well.
regards,
Koen
Quoted 5 lines · Koen Kooi
In the specific case of upgrades you'll need to add a
systemctl --system daemon-reloadto catch changed unit files as well.
Good catch, thanks.
I'm not entirely optimistic about opkg postinsts being able to tell the difference between upgrades and fresh installs, so I suspect we'll just have to always do this.
Ross