For reference, all this is a side effect of the proposed fix for #991266,
strangely not caught at the time.
On Tue, Jun 20, 2023 at 08:00:19PM +0200, Francesco P. Lovergine wrote:
Bruno, that's right
Unfortunately yes: originally the socket unit file was concepted as an example
file to keep into the documentation and the Conflicts there does not
ensure that the .socket unit is ignored when the .service is enabled.
The simplest workaroud is
systemctl disable --now proftpd.socket
systemctl enable --now proftpd.service
but the initial installation is definitively broken, because proftpd
starts as a systemd socket, which is not intended by the distributed
proftpd.conf.
Hilmar, the simplest thing to do is probably addig a mask/disable of
proftpd.socket at postinst time,
and an enable --now for the proftpd.service, when server should be run
in standalone mode (check via grepping proftpd.conf), after installing
systemd stuff in --no-enable --no-start mode.
This is of course not completely fair because ignores xinetd/inetd setup.
--
Francesco P. Lovergine
