Hi Emmanuel, On Tue, Aug 19, 2025 at 05:44:58PM +0200, Alexander Sulfrian wrote: > 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. In postinst, if systemctl is-active --quiet popa6d; then Looks like a typo for the service name. > > 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. The systemctl invocations in the maintscripts fail package installation on a system not running systemd, which is quite a bad failure mode. You're probably meant to use deb-systemd-helper(1p) like the debhelper does, although if it's possible to achieve everything with the debhelpers that would be ideal! > 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". Also in this case it would be necessary to add CAP_NET_BIND_SERVICE. Note CAP_SETUID is misspelled, missing the final 'D' and CAP_SETGID has been written with a hyphen (don't know if that works). > 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? Agreed and sounds like a good transition solution. Shadow service control via config variable is disrecommended for all init systems, per Debian policy 9.3.3.1 [1]. > Maybe even the inetd integration could be removed in favor of > systemd-socket-activation? I notice the initscript was removed - this does not need to be done when adding a systemd unit and makes things harder for other users. I've proposed a simplified and improved initscript in a merge request [2] on the salvage repo, which I have tested - I hope you can include that! Hope this helps, Andrew [1] https://www.debian.org/doc/debian-policy/ch-opersys.html#managing-the-links [2] https://salsa.debian.org/salvage-team/popa3d/-/merge_requests/1
Attachment:
signature.asc
Description: PGP signature