Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1038416: proftpd-basic: proftpd service fails to start on next server reboot

155 views
Skip to first unread message

Predrag Damnjanovic

unread,
Jun 17, 2023, 7:41:23 PM6/17/23
to
Package: proftpd-basic
Version: 1.3.8+dfsg-4
Severity: normal

Dear Maintainer,

* What led up to the situation?
Even on clean Debian12, with just proftpd installed, proftpd service will not start om next server reboot.

* What exactly did you do (or not do) that was effective (or ineffective)?
Service is installed this way:
# apt install proftpd
Note, selecting 'proftpd-core' instead of 'proftpd'
The following additional packages will be installed:
libhashkit2 libhiredis0.14 libmemcached11 libmemcachedutil2 libpcre2-posix3
The following NEW packages will be installed:
libhashkit2 libhiredis0.14 libmemcached11 libmemcachedutil2 libpcre2-posix3 proftpd-core

I also did:
# systemctl enable proftpd
Output is:
Synchronizing state of proftpd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable proftpd

...but on next reboot proftpd service will not be automatically started.

So, after reboot, if I do:
# systemctl status proftpd
Output is:
○ proftpd.service - ProFTPD FTP Server
Loaded: loaded (/lib/systemd/system/proftpd.service; enabled; preset: enabled)
Active: inactive (dead)

It's clearly not started.

If I do:
# grep 'proftpd' /var/log/syslog
Output is only this line:
2023-06-17T21:34:40.157071+00:00 vesna systemd[1]: Listening on proftpd.socket - ProFTPD FTP Server Activation Socket.

Also:
# ps -Af | grep 'proftp'
gives nothing.

But if I run:
# cat /var/log/proftpd/proftpd.log
I get:
2023-06-17 21:34:19,440 vesna proftpd[35867] xxx.xxx.xxx.xxx: ProFTPD killed (signal 15)
2023-06-17 21:34:19,440 vesna proftpd[35867] xxx.xxx.xxx.xxx: ProFTPD 1.3.8 standalone mode SHUTDOWN
2023-06-17 21:40:21,401 vesna proftpd[2593] xxx.xxx.xxx.xxx: Failed binding to ::, port 21: Address already in use
2023-06-17 21:40:21,402 vesna proftpd[2593] xxx.xxx.xxx.xxx: Check the ServerType directive to ensure you are configured correctly
2023-06-17 21:40:21,402 vesna proftpd[2593] xxx.xxx.xxx.xxx: Check to see if inetd/xinetd, or another proftpd instance, is already using ::, port 21
2023-06-17 21:40:21,402 vesna proftpd[2593] xxx.xxx.xxx.xxx: Unable to start proftpd; check logs for more details

Looks like it is killed by something (inetd?), but when incoming connection comes, it says port 21 is in use.

Then, when I check netstat:
# netstat -tuapen | grep ':21'
I get:
tcp6 0 0 :::21 :::* LISTEN 0 15323 1/init

Now if I start proftpd manually:
# systemctl start proftpd

# netstat -tuapen | grep ':21'
gives:
tcp6 0 0 :::21 :::* LISTEN 109 31548 6990/proftpd: (acce

# ps -Af | grep 'proftp'
gives:
proftpd 6990 1 0 22:25 ? 00:00:00 proftpd: (accepting connections)

... and proftpd service perfectly works...

On next reboot the situation is the same as on the beginning of this report.

My /etc/proftpd/proftpd.conf is default one, I didn't changed anything after proftpd is installed.


-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages proftpd-basic depends on:
ii proftpd-core 1.3.8+dfsg-4
ii proftpd-mod-crypto 1.3.8+dfsg-4
ii proftpd-mod-wrap 1.3.8+dfsg-4

proftpd-basic recommends no packages.

proftpd-basic suggests no packages.

-- no debconf information

Bruno

unread,
Jun 20, 2023, 10:50:05 AM6/20/23
to

I guess that the systemd unit protfpd.socket should be disabled


$ systemctl is-enabled proftpd.socket  
disabled



May be the Debian package postinst script wrongly enabled it

 

 



Francesco P. Lovergine

unread,
Jun 20, 2023, 2:10:06 PM6/20/23
to
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.

On Tue, Jun 20, 2023 at 04:21:41PM +0200, Bruno wrote:
>I guess that the systemd unit protfpd.socket should be disabled
>
>$ systemctl is-enabled proftpd.sockets
>disabled
>
>
>May be the Debian package postinst script wrongly enabled it
>
>
>
>
>
>_______________________________________________
>Pkg-proftpd-maintainers mailing list
>Pkg-proftpd...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers
>

--
Francesco P. Lovergine

Francesco P. Lovergine

unread,
Jun 20, 2023, 2:50:04 PM6/20/23
to
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

Francesco P. Lovergine

unread,
Jun 21, 2023, 4:10:04 AM6/21/23
to
severity 1038416 serious
tags 1038416 + patch bookworm
thanks


Hi all,

Here we go, there is a better solution.

It is possible to install and enable a third unit file such as:

+++ /etc/systemd/system/proftpd-run.service:

[Unit]
Description=ProFTPD FTP Server in standalone/socket mode
OnFailure=proftpd.socket
OnSuccess=proftpd.service

[Service]
Type=oneshot
Environment=CONFIG_FILE=/etc/proftpd/proftpd.conf
EnvironmentFile=-/etc/default/proftpd
ExecStart=/usr/bin/grep -iqE '^[[:space:]]*ServerType[[:space:]]+standalone$' $CONFIG_FILE
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Here one can enable only this service and install only the other ones.

systemctl disable proftpd.service
systemctl disable proftpd.socket
systemctl enable --now proftpd-run.service

do the task.

I would add this solution to git and prepare an ad hoc p-u for bookworm, but
I'd prefer having a go from the release team, before that.

- cheers
0 new messages