Это можно выполнить двумя способами - остановить и повторно запустить сервер или послать сигнал SIGHUP основному процессу proftpd. Скрипты, имеющиеся как в оригинальной поставке, так и в различных пакетах, позволяют делать и то, и другое. Есть небольшая ошибка в обработке сигнала SIGHUP, которую пока не удалось локализовать [возможно, уже устранена - прим. перев.]. Заключается она в том, что при перезапуске сервера с большим числом виртуальных хостов примерно в 30% случаев это завершается ошибкой, "заваливающей" все процессы.
[Бывают.. Хотя не совсем по теме.. Позже доперевожу, пока же пошёл
на аутентификацию ;)]
problem with non-existant names killing the daemon
Part of being a decent system administrator is solving the problem -- at the core. Apache lets you "pretend the problem doesn't exist" (yes, it spits out crap to stdout on runtime, but that doesn't necessarily mean you're going to be there to see it), allowing people to slack off and avoid doing their job in it's entirety. I care about the technicalities, as well as the principle behind the above situation. If my webserver (or FTP server) "skips" a host, it's more than likely going to cause a cust- omer or client to throw a fit.
It isn't absurd when you are running for than a few virtual hosts. Software isn't supposed to die at the first sign of trouble. If you had a few hundred virtual hosts, you wouldn't want apache to completely die because one of them wouldn't resolve, or wasn't aliased, etc.
Wait...does it not make sense that you shouldn't have users logged in when you refresh the daemon?I'm no expert, but I've never seen something that will allow you to bind an application to a port that's already in use. It doesn't make sense to be able to do that. If you in effect kill the proftpd daemon and restart it...and orphan it's children, when it restarts it will attempt to bind to IPs and Ports. If a child process is still running on one of those IPs or Ports, how should proftpd handle it? Kill the process holding the port and then start? If it can't bind to the port or IP, I don't see how it will be able to recover.
Since no one else is responding to my message, I'm writing my own follow-up. The problem is worse than I thought: if you send a HUP to the master process (again, in standalone mode) to get it to recognize configuration changes, and someone is connected to one of the VirtualHosts, the whole process fails because it can't bind to that address. This is another case that I don't think should cause the entire server to fail. Am I the only one having these problems? Is anyone else running standalone? Thanks for any feedback.
I don't like the idea of kicking off all our connected users just to add a VirtualHost, and less, having all the servers die if it can't bind to 1 of 60 addresses. I understand that it can't bind to a port that is in use, but the bound process could understand that the configuration has changed and NOT stop/restart; I thought that was part of the benefit of sending a HUP rather than killing the whole thing and restarting (sort of like rebooting Windows for every little change you make)...
I just connected to one of the Virtual Hosts (running close to 200) on my FTP server (running ProFTPD in standalone) then HUP'd it while still connected which did not cause any fatal errors for me. It didn't cause my connection to drop either. HUP should only cause the process to reread the config not stop and restart as far as I know. So there is no logical reason why a HUP doesn't work, unless you attempt to use a domain name/IP that is not yet aliased to the NIC on that system. DNS shouldn't have anything to do with it as long as the IP/domain is aliased to the NIC, usually with ifconfig. But hey, I could be wrong, it has happened before :)