• The APS Catalog has been deprecated and removed from all Plesk Obsidian versions.
    Applications already installed from the APS Catalog will continue working. However, Plesk will no longer provide support for APS applications.
  • Please be aware: with the Plesk Obsidian 18.0.78 release, the support for the ngx_pagespeed.so module will be deprecated and removed from the sw-nginx package.

Issue After plesk upgrade to 18.0.78, ProFTPD terminating (signal 11)

theunknownstuntman

Basic Pleskian
Server operating system version
22.04.5 LTS (Jammy Jellyfish)
Plesk version and microupdate number
Plesk Obsidian 18.0.78.0
Hi all,

yesterday I updated several servers to Plesk Obsidian 18.0.78.0. During this update ProFTPD was updated to version 1.3.9a.

Most of the affected servers are running the same Ubuntu version / Plesk version (see above). Two are running Ubuntu 20.04.6 LTS together with Plesk Obsidian 18.0.78.0 and ProFTPD 1.3.9a.

Today I see, that on all afffected Plesk servers, ProFTPD is crashing. Here is a sample from /var/log/syslog:

May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - -----BEGIN STACK TRACE-----
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [0] /lib/x86_64-linux-gnu/libssl.so.3(SSL_get_session+0x4) [0x7f6a3f11be24]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [1] /lib/x86_64-linux-gnu/libssl.so.3(SSL_get_session+0x4) [0x7f6a3f11be24]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [2] proftpd: 31.14.254.109:7178: AUTH TLS(+0xe2a1f) [0x56233ff06a1f]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [3] proftpd: 31.14.254.109:7178: AUTH TLS(+0xd12bf) [0x56233fef52bf]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [4] proftpd: 31.14.254.109:7178: AUTH TLS(+0xd6315) [0x56233fefa315]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [5] proftpd: 31.14.254.109:7178: AUTH TLS(pr_module_call+0x49) [0x56233fe7ddf9]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [6] proftpd: 31.14.254.109:7178: AUTH TLS(+0x32928) [0x56233fe56928]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [7] proftpd: 31.14.254.109:7178: AUTH TLS(pr_cmd_dispatch_phase+0x47c) [0x56233fe5715c]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [8] proftpd: 31.14.254.109:7178: AUTH TLS(+0x33b65) [0x56233fe57b65]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [9] proftpd: 31.14.254.109:7178: AUTH TLS(+0x3429c) [0x56233fe5829c]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [10] proftpd: 31.14.254.109:7178: AUTH TLS(main+0x788) [0x56233fe4e128]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [11] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f6a3ea88d90]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [12] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f6a3ea88e40]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - [13] proftpd: 31.14.254.109:7178: AUTH TLS(_start+0x25) [0x56233fe4e645]
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - -----END STACK TRACE-----
May 12 21:03:49 xyz proftpd[1139701]: 0.0.0.0 (31.14.254.109[31.14.254.109]) - ProFTPD terminating (signal 11)

ProFTPD can be restarted via "service xinetd restart" successfully, so I assume, that the crashes are triggered by an external event.
As I haven't seen any crashes regarding ProFTPD before, I assume that they might have to do with the Plesk / ProFTPD update.

Has anyone seen similar errors? Is this a bug in ProFTPD or Plesk related? I am grateful for any advice.
 
Hello @theunknownstuntman !
Just checked with the same configuration:
# proftpd -V
Compile-time Settings:
Version: 1.3.9a (maint)
Platform: LINUX [Linux 5.4.0-216-generic x86_64]
OS/Release:
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
. . .

On Plesk Obsidian 18.0.78.0

Nothing similar with your case. I suggest the following:

1. Check if anything suspicious in
  • /var/log/plesk/xferlog
  • /var/log/plesk/ftp_tls.log
logfiles.

2. Check service itself
systemctl status xinetd

3. Make sure that configuration files are in order:
# proftpd -t

# grep -Rin 'TLS' /etc/proftpd* 2>/dev/null


For deeper investigation "in place" submit a ticket to Plesk support
 
@alapshin , thank your for your answer!

Here are my findings:
  • /var/log/plesk/xferlog is empty
  • /var/log/plesk/ftp_tls.log shows this, when ProFTPD crashed again
2026-05-13 14:02:42,768 mod_tls/2.9.2[231459]: added 1 certs from '/opt/psa/admin/conf/httpsd.pem' to SSL_CTX certificate chain
2026-05-13 14:02:46,075 mod_tls/2.9.2[231462]: added 1 certs from '/opt/psa/admin/conf/httpsd.pem' to SSL_CTX certificate chain
2026-05-13 14:02:46,101 mod_tls/2.9.2[231462]: TLS/TLS-C requested, starting TLS handshake
2026-05-13 14:02:46,126 mod_tls/2.9.2[231462]: unable to accept TLS connection: system call error: [104] Connection reset by peer

xinetd only shows the entries I see in syslog, when ProFTPD crashed.

systemctl status xinetd

● xinetd.service - LSB: Starts or stops the xinetd daemon.
Loaded: loaded (/etc/init.d/xinetd; generated)
Active: active (running) since Wed 2026-05-13 13:17:47 CEST; 1h 14min ago
Docs: man:systemd-sysv-generator(8)
Process: 223452 ExecStart=/etc/init.d/xinetd start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 38368)
Memory: 508.0K
CPU: 234ms
CGroup: /system.slice/xinetd.service
└─223462 /usr/sbin/xinetd -pidfile /run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6

May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [6] proftpd: 31.14.254.69:5330: AUTH TLS(+0x32928) [0x55c1729ac928]
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [7] proftpd: 31.14.254.69:5330: AUTH TLS(pr_cmd_dispatch_phase+0x47c) [>
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [8] proftpd: 31.14.254.69:5330: AUTH TLS(+0x33b65) [0x55c1729adb65]
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [9] proftpd: 31.14.254.69:5330: AUTH TLS(+0x3429c) [0x55c1729ae29c]
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [10] proftpd: 31.14.254.69:5330: AUTH TLS(main+0x788) [0x55c1729a4128]
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [11] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fa48843dd90]
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [12] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fa4884>
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - [13] proftpd: 31.14.254.69:5330: AUTH TLS(_start+0x25) [0x55c1729a4645]
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - -----END STACK TRACE-----
May 13 14:02:46 xyz proftpd[231462]: 0.0.0.0 (31.14.254.69[31.14.254.69]) - ProFTPD terminating (signal 11)

Configuration files are fine.

grep -Rin 'TLS' /etc/proftpd* 2>/dev/null
/etc/proftpd.conf:45:<IfModule mod_tls.c>
/etc/proftpd.conf:47: TLSEngine on
/etc/proftpd.conf:48: TLSRequired off
/etc/proftpd.conf:50: TLSLog /var/log/plesk/ftp_tls.log
/etc/proftpd.conf:52: TLSRSACertificateFile /opt/psa/admin/conf/httpsd.pem
/etc/proftpd.conf:53: TLSRSACertificateKeyFile /opt/psa/admin/conf/httpsd.pem
/etc/proftpd.conf:54: TLSCertificateChainFile /opt/psa/admin/conf/httpsd.pem
/etc/proftpd.conf:56: # Authenticate clients that want to use FTP over TLS?
/etc/proftpd.conf:57: TLSVerifyClient off
/etc/proftpd.conf:59: # Allow SSL/TLS renegotiations when the client requests them, but
/etc/proftpd.conf:61: # SSL/TLS renegotiations; when mod_tls forces a renegotiation, these
/etc/proftpd.conf:64: TLSRenegotiate none
/etc/proftpd.conf:66: # As of ProFTPD 1.3.3rc1, mod_tls only accepts SSL/TLS data connections
/etc/proftpd.conf:69: TLSOptions NoSessionReuseRequired
/etc/proftpd.d/ssl.conf:2:<IfModule mod_tls.c>
/etc/proftpd.d/ssl.conf:3:TLSDHParamFile /opt/psa/etc/dhparams2048.pem
/etc/proftpd.d/ssl.conf:7:<IfModule mod_tls.c>
/etc/proftpd.d/ssl.conf:8:TLSProtocol TLSv1.2 TLSv1.3
/etc/proftpd.d/ssl.conf:9:TLSCipherSuite EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EECDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH:!EDH
/etc/proftpd.d/ssl.conf:10:TLSServerCipherPreference on
/etc/proftpd.d/50-plesk.conf:10:<IfModule mod_tls.c>
/etc/proftpd.d/50-plesk.conf:11: TLSEngine on
/etc/proftpd.d/50-plesk.conf:12: TLSRequired on
 
Thank yuo for the provided data.
As I see
TLSRequired on in /etc/proftpd.d/50-plesk.conf
This is differ from my test set.

I suggest the following actions for investigation:
1.
in /etc/proftpd.d/50-plesk.conf set TLSRequired off

2.
restart the service service xinetd restart

3.
Check that service is up and running and port 21 is listening by it:
# systemctl status xinetd
# ss -ltnp | grep ':21'
LISTEN 0 64 *:21 *:* users: (("xinetd",pid=6400,fd=5))


4.
from he server with the issue check handshake by:

# openssl s_client -connect 127.0.0.1:21 -starttls ftp
(it is okay if you face "Verification error: self signed certificate")

5.
from the another server

# openssl s_client -connect YOUR_SERVER_IP:21 -starttls ftp
check handshake.

6.
Check logfiles again.

  • /var/log/plesk/xferlog
  • /var/log/plesk/ftp_tls.log
  • /var/log/syslog
 
Back
Top