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 [email protected] 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
signature.asc
Description: PGP signature
