Closed m0rph03nix closed 2 years ago
It looks like this is a normal situation. My instance has 77 restarts for 8 days working. And every time it's "ExitCode: 0". No one error. Just try to add "--restart always".
Thanks, it works.
@delfer Thanks for your great docker image.
I have forked this as I wanted to implement ssl in it.
This issue happened for me as well, but unfortunately some clients didn't reconnect on multiple restarts, therefore I have fixed this by adding a sleep infinity
at the exec
command in start_vsftpd.sh
like this:
https://github.com/aminvakil/docker-alpine-ftp-server-tls/blob/288d9dcc30a96874a33596183c64a1997923754d/start_vsftpd.sh#L57
Also --restart unless-stopped
is more suitable in this case imho.
I have forked and I'm having the same problem too, but I don't want the container to restart. I'm trying to understand why this is happening. It looks like vsftpd is not working as it's daemonized, but as it would under inetd. When the FTP connection closes, the vsftpd process closes down, then the container shuts down. I think this is not what should happen when listen=YES.
When the FTP connection closes, the vsftpd process closes down, then the container shuts down. I think this is not what should happen when listen=YES.
I looked into it and I'm afraid that this is vsftpd
's intended behaviour when you have background=NO
in the daemon's config.
When background=YES
the daemon does not close down after a connection, but the process is backgrounded as soon as it is launched.
Too bad this violates docker's logic - by design, the monitored process must stay in the foreground else the container closes down. So you have to keep the container up with a trick, like @aminvakil suggested with sleep infinity
, which keeps the monitored shell script alive.
It actually works, but it's not good practice, since now the container status does not reflect the daemon's status - vsftpd can crash and the container will merrily still be up because the sleep
process keeps it up.
But if I am not mistaken, given vsftpd's (I'd say flawed) design, the only way around this is designing a watchdog script - maybe just a one-liner while
that loops as long as it finds vsftpd running:
while [ "$(ps ax | grep /usr/sbin/vsftpd | grep -v grep)" ]; do sleep 30s; done
(maybe this will need procps)
Also
--restart unless-stopped
is more suitable in this case imho.
I think I can see where this comes from, but again, the container's restart policy should have nothing to do with keeping it up when it's working.
Too bad this violates docker's logic - by design, the monitored process must stay in the foreground else the container closes down. So you have to keep the container up with a trick, like @aminvakil suggested with
sleep infinity
, which keeps the monitored shell script alive. It actually works, but it's not good practice, since now the container status does not reflect the daemon's status - vsftpd can crash and the container will merrily still be up because thesleep
process keeps it up. But if I am not mistaken, given vsftpd's (I'd say flawed) design, the only way around this is designing a watchdog script - maybe just a one-linerwhile
that loops as long as it finds vsftpd running:
while [ "$(ps ax | grep /usr/sbin/vsftpd | grep -v grep)" ]; do sleep 30s; done
(maybe this will need procps)
This does not help too much as well as it does not check various problems which may be caused rather than process getting killed completely.
Also
--restart unless-stopped
is more suitable in this case imho.I think I can see where this comes from, but again, the container's restart policy should have nothing to do with keeping it up when it's working.
You're right, this is irrelevant to this issue, just wanted to mention it.
Sorry, talking about Docker (I'm usign this image ASIS, I don't want to edit the config or the entrypoint script) how can I set the --restart option? EDIT: nvm, thanks @aminvakil for pointing to your fork, it works really fine
while [ "$(ps ax | grep /usr/sbin/vsftpd | grep -v grep)" ]; do sleep 30s; done
(maybe this will need procps)This does not help too much as well as it does not check various problems which may be caused rather than process getting killed completely.
That was admittedly a quick fix, but then again, its purpose is to keep the container up just as long as the main vsftpd
process is running, just like a foreground process would behave. We're not talking health checks here, there is HEALTHCHECK for that.
Hi @m0rph03nix where you able to solve this? Thanks.