Restart vsftpd --> Stopping ftp server...failed

[SaschaBr]

Ich bekomme, wenn ich den vsftpd über das Freetz-WebIF neustarte, gelegentlich die Meldung "Stopping ftp server...failed", obwohl das Stoppen erfolgreich war. Danach wird vsftp natürlich nicht automatisch neu gestartet.
Die meiste Zeit klappt der "Restart" aber (ich bekam also nur ab und zu diese Meldung), weswegen ich diesen Mini-Bug ignoriert habe.
Heute ist mir dann aber durch einen dummen Zufall aufgallen, wann das Stoppen des vsftpd angeblich fehlschlägt: Und zwar passiert das immer genau dann, wenn entweder ein Client erbunden ist, oder ein Verbindungsversuch stattfindet (zum Beispiel die mit den chinesischen Ip's).

 

[RalfFriedl]

Dann sollte man mal das Stoppen überarbeiten.
Unterstützt vsftpd keine Pid-Datei?

 

[olistudent]

Vsftpd unterstützt keine pid-Datei. In Debian wird das von start-stop-daemon erledigt. Den haben wir standardmäßig in der bb nicht aktiviert. Der würde 4kB kosten.

MfG Oliver

 

[SaschaBr]

Für diesen Mini-Bug (wenn man das denn überhaupt so nennen darf) 4kB zu verschwenden, erachte ich auch als Schwachsinn. Schließlich bekommt man ja eine Fehlermeldung (wenn auch die Falsche). Dann weiß man eh, dass da was "schief" gegangen ist.

 

[RalfFriedl]

Ich habe mir die stop-Aktion nochmal angeschaut. Die sollte keine Fehler melden, auch wenn eine Verbindung aktiv ist.

Kannst Du mal 'sh -x /etc/init.d/rc.vsftpd stop' ausführen, währen eine Verbindung aktiv ist?

 

[SaschaBr]

Ausgabe auf der Konsole:

/var/mod/root # sh -x /etc/init.d/rc.vsftpd stop
+ DAEMON=vsftpd
+ LOGLINK=/var/log/mod_vsftpd.log
+ . /etc/init.d/modlibrc
+ export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin
+ export LD_LIBRARY_PATH=/mod/lib:/mod/usr/lib
+ [ -n vsftpd ]
+ stop
+ echo -n Stopping ftp server...
Stopping ftp server...+ killall vsftpd
+ exitval=0
+ remove_status_log
+ modunreg status vsftpd vsftpd/vsftpd_log
+ rm -f /var/log/mod_vsftpd.log
+ rm -f /mod/etc/vsftpd.conf
+ [ 0 -eq 0 ]
+ echo done.
done.
+ exit 0
/var/mod/root #

... und das bei ....

/var/mod/root # sh -x /etc/init.d/rc.vsftpd restart
+ DAEMON=vsftpd
+ LOGLINK=/var/log/mod_vsftpd.log
+ . /etc/init.d/modlibrc
+ export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin
+ export LD_LIBRARY_PATH=/mod/lib:/mod/usr/lib
+ [ -n vsftpd ]
+ [ ! -r /mod/etc/conf/vsftpd.cfg ]
+ modlib_loadconfig
+ local CONF_FILE=/mod/etc/conf/vsftpd.cfg
+ [ -r /mod/etc/conf/vsftpd.cfg ]
+ . /mod/etc/conf/vsftpd.cfg
+ export VSFTPD_ADD_SETTINGS=user_config_dir=/var/media/ftp/LOGS/vsftp_user_conf
userlist_file=/var/media/ftp/LOGS/vsftp_user_conf/vsftpd.user_list
userlist_deny=NO
require_ssl_reuse=NO
banner_file=/var/media/ftp/LOGS/motd
+ export VSFTPD_ALLOW_FTPUSER=no
+ export VSFTPD_ALLOW_ROOT=no
+ export VSFTPD_ANONYMOUS=no
+ export VSFTPD_ANON_ROOT=/mod/home/ftp
+ export VSFTPD_CHROOT=yes
+ export VSFTPD_CHROOT_JAIL_LIST=
+ export VSFTPD_DELAY_FAILED_LOGIN=15
+ export VSFTPD_ENABLED=yes
+ export VSFTPD_ENABLE_RELOAD_SCRIPT=yes
+ export VSFTPD_ENABLE_SSL=yes
+ export VSFTPD_ENABLE_SSLV2=yes
+ export VSFTPD_ENABLE_SSLV3=yes
+ export VSFTPD_ENABLE_TLSV1=yes
+ export VSFTPD_FORCE_DATA_SSL=yes
+ export VSFTPD_FORCE_LOGIN_SSL=yes
+ export VSFTPD_LOG_ENABLE=yes
+ export VSFTPD_LOG_FILE=/var/media/ftp/LOGS/vsftpd/vsftpd.fbt
+ export VSFTPD_LOG_PROTOC=no
+ export VSFTPD_LOG_SYSLOG=no
+ export VSFTPD_MAX_CLIENTS=12
+ export VSFTPD_MAX_PER_IP=3
+ export VSFTPD_PASV_ADDRESS=yes
+ export VSFTPD_PASV_MAX=21262
+ export VSFTPD_PASV_MIN=21212
+ export VSFTPD_PORT=21
+ export VSFTPD_PROMISCUOUS=yes
+ export VSFTPD_USERS_ENABLED=yes
+ stop
+ echo -n Stopping ftp server...
Stopping ftp server...+ killall vsftpd
+ exitval=3
+ remove_status_log
+ modunreg status vsftpd vsftpd/vsftpd_log
+ rm -f /var/log/mod_vsftpd.log
+ rm -f /mod/etc/vsftpd.conf
+ [ 3 -eq 0 ]
+ echo failed.
failed.
+ exit 3
/var/mod/root #

 

[RalfFriedl]

Im oberen Fall kommt kein Fehler.
Kannst Du mal statt dessen nochmal starten, Verbindung halten, und 'killall vsftpd' ausführen?
exitval=3 bedeutet wohl, daß 3 Prozesse existieren, diesen aber kein Signal gesendet werden konnte. Das sollte für root nicht passieren. Daher wäre die Fehlermeldung interessant.

Übrigens ist das ein Fehler in der Busybox. Wenn aus irgendeinem Grund gerade 256 Fehler auftreten würden, wäre der Rückgabewert 0. Das normale killall Kommando gibt immer 1 bei einem Fehler zurück

 

[cuma]

Das könnte dann evtl durch Ticket 595 gelöst werden

 

[SaschaBr]

... nochmal starten, Verbindung halten, und 'killall vsftpd' ausführen ...

/var/mod/root # killall vsftpd
killall: cannot kill pid 16440: No such process
killall: cannot kill pid 16441: No such process
killall: cannot kill pid 16442: No such process
/var/mod/root #

Wenn eine Verbindung steht, gibt es laut "ps" vier Prozesse:

/var/mod/root # ps
  PID USER       VSZ STAT COMMAND
....
 2297 root      1428 S    /sbin/chronyd -f /var/tmp/chrony.conf
16455 root      1444 S    -sh
16945 root      2688 S    vsftpd
17210 root      2692 S    vsftpd
17211 root      2852 S    vsftpd
17212 ftpuser   2716 S    vsftpd
17221 root      1428 R    ps
/var/mod/root #

 

[RalfFriedl]

Wenn der Prozeß nicht mehr existiert, heißt das, daß er sich selbst beendet hat, zwischen der Zeit, in der killall festgestellt hat, daß er existiert, bis zu der Zeit, wo er das Signal bekommt.

Das ist nochmal ein Unterschied zum normalen killall. In dessen man-page steht:

killall returns a zero return code if at least one process has been killed for each listed command. killall returns non-zero otherwise.

Busybox killall liefert dagegen einen Fehler, wenn nur ein kill nicht erfolgreich war.

Wir könnten einen Patch machen, daß vsftpd ein Pidfile erstellt, bei Busybox die Änderung von killall vorschlagen, oder den Rückgabewert ignorieren.

 

[olistudent]

Wir haben das auch in anderen Skripten schon, dass die pid-Datei im Startskript angelegt wird, weil der Daemon das nicht unterstützt.

MfG Oliver