Hi, On 8/19/25 16:30, Emmanuel Arias wrote:
In my work in the Debian Tiny Task I started to work in popa3d [0] to fix #1039320. I've not experiences with systemd, so I'm looking some recomendations about this. I created a .service and .socket files. And I modify a little bit the maintainer script, but I'm not sure if they are enough. Do you have some recommendation or help?
Please note that debhelper will insert some stanzas to enable/restart the installed systemd units. This might conflict with your manual scripts, as it tries to enable newly installed services by default. You may want to use "dh_installsystemd --no-enable --no-start" if you do not want the default behavior. See dh_installsystemd(1) for details
Additionally, you are missing "systemctl --system daemon-reload" before attempting to restart the unit after an upgrade, as systemd will not automatically reload the new unit file. The stanza from debhelper includes this.
Your current setup with popa3d.socket and popa3d.service doesn't work. With "Accept=yes" in your socket unit, you will need a popa3d@.service that is started for each connection (see systemd.socket(5) for the details).
Your popa3d.service could be used for standalone mode, but in that case, "popa3d -D" should be executed, and you may need to set "Type=forking".
IMHO it is (at least) uncommon to have a RUN_STANDALONE setting with systemd. I would expect to be able to control the service simply by enabling or disabling the systemd unit. Perhaps the old setting could be used as the initial state of the new systemd units and could then removed afterwards? Maybe even the inetd integration could be removed in favor of systemd-socket-activation?
Regards, Alex
Attachment:
OpenPGP_0x0BD13B63E2A9AF58.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature