Hi, On 11/09/2017 01:08 PM, Stefan Priebe - Profihost AG wrote: > yes that's what i'm talking about. The logfile rotation script DOES a > restart not a reload. >
No it doesn't do a systemd restart, it's a bit confusing - I know. > See here: > https://git.proxmox.com/?p=pve-manager.git;a=blob_plain;f=debian/pve.logrotate;hb=HEAD > It does a `pveproxy restart`, which _is_ a real graceful "fast" restart, not to be confused with `systemctl restart pveproxy` which does a full stop first, and then a full new startup again. `systemctl reload pveproxy` does the exact same as the logrotation, see: https://git.proxmox.com/?p=pve-manager.git;a=blob_plain;f=bin/init.d/pveproxy.service Thus the problem is not this but the one I described in the last paragraph from my last answer: On 11/09/2017 11:03 AM, Thomas Lamprecht wrote: > > We do a re-exec on "ourself" (from the daemons POV), and the intend is to > leave non-idle child workers untouched, but the logic doing this is a bit > flawed as all current worker child always receive a TERM signal. > Here the HTTP server worker wait at least for active connection to end, > but new ones do not get accepted. We directly restart after that, but yes, > depending on load there can be a time window where no one is there to > accept connections. > I'd rather not send the TERM signal in the case where the > "leave_children_open_on_reload" option is set and we're restarting but > just restart, passing the current worker PIDs over to our new self > (this gets already done). There on startup then start new workers and > message the old ones to not accept new connections and terminate > gracefully as soon as possible. Now there is never a time where no active > listening worker would there. I try to give it a look. > cheers, Thomas _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
