© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Robie / Chris,
Can you review comment #6 for the proposed patch and upgrade issue/strategy?
The upstart config for freeradius is bad; reload(8) or restart(8) will lose track of the process. A reload won't send SIGHUP to the right process and a restart(8) will not stop the existing freeradius process; in either case upstart loses track of the process and thinks the service has stopped, further attempts to start the service will fail because of the existing process holding the port open. The patch fixes this for new, clean starts of the service but on a running system I don't think we have a way to make things better without manual intervention ('pkill freeradius' when the user can afford to take the process down) or a reboot.
I might be missing something clever, but I doubt there is a good way to fix this for the different states we might find things in during upgrade.
Scenarios:
1 - freeradius is not running. Upgrading the package is great.
2 - freeradius is runing and 'reload/restart' has been called previously (i.e. upstart can't manage the freeradius process). Upgrading will not regress the system because upstart could not manage the service prior to package upgrade.
3 - freeradius is running and 'reload/restart' has never been called (i.e. upstart can still stop the process properly). Upgrading will fix logrotate and the next rotation will call 'reload freeradius' causing upstart to lose track of the process. It can no longer be stopped by upstart.
The only issue is scenario #3 which regresses the user's ability to stop freeradius *if* they have not tried to reload or restart the service. I don't think that we can take the action to restart the service on package upgrade if upstart can still manage the service due to service interruption. The next logrotation attempt will ensure that the user can not manage freeradius from upstart.