On 4/20/23 14:48, Perry Naseck wrote:
Hello!I am in the process of updating/upgrading a package from an init.d service to a Systemd service. Are there any recommended guidelines for this process?
My generic advice would be: start your thinking from a perspective of "how should this work in systemd anew", not "how do I 1:1 convert the init.d unit". That is, start in a "systemd native" approach. You may need to pull back from that for backwards compatibility reasons, or consistency with the init.d unit or whatever (and I maintain a package that is that way), but make those decisions intentionally.
Looking through some current packages I see that a lot of them have both an init script and a Systemd service in their debian folder. Do dh_installsystemd and dh_installinit handle this smoothly by default if both files exist?
In my experience, if the files are name the same (i.e. /etc/init.d/foo and /lib/systemd/system/foo.service), everything should Just Work, both in terms of the Debian bits and the systemd bits (discussed below).
When upgrading the package on a machine will it stop the init service and start the Systemd service?There is no such thing as an "init service" on a systemd machine. If you have only /etc/init.d/foo, systemd is dynamically generating a foo.service unit. You can see this with e.g. "systemctl status foo". For example, on my system:
$ systemctl status openipmi
× openipmi.service - LSB: OpenIPMI Driver init script
Loaded: loaded (/etc/init.d/openipmi; generated)
When you install a foo.service unit file, that will take precedence over
the generated one. So (assuming they have the same name), they are the
same service.
This package also stores its configuration in /var/lib/packagename and it should really be in /etc/packagename. Where is the best place to deal with auto-migration? Should this go in postinst or is there a debhelper that I should use?
Take this with a grain of salt, and defer to more knowledgeable folks, but...
If I were in that situation, I'd start with the idea of moving it in a preinst script. I would probably also guard it with version checks (as opposed to only checks for the existence of the folder). So something like (where the "2" in version-2~ is the package version one _higher_ than the version where you made the change, i.e. if you changed in -1, use -2~):
#!/bin/sh
set -e
if [ "$1" = "upgrade" ] && [ -n "$2" ]
then
if dpkg --compare-versions "$2" le-nl "version-2~"
then
if [ -e /var/lib/packagename ] && ! [ -e /etc/packagename ]
then
mv /var/lib/packagename /etc/packagename
fi
fi
fi
That said, I'm not sure what Policy has to say about this. It seems to
me that you want the package to do things right moving forward, and you
want to support clean upgrades, so this seems like the approach that
gets both of those.
-- Richard
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature