Inform the admin in case multiple service reload is done in rapid succession
In SL7 a service reload triggers the sequence sop reconfig and start and this is asynchronous.
In production factories (~600 entries) a reconfig may take 5min or more. And factory operators may have further changes and invoke a reload before the previous is complete.
I think at the moment the second reload is ignored (the SIGHUP is not listened to during the reconfig)
1- interrupt current reconfig and restart it (and restart the service only after)
2- queue a new reconfig right after the current (before restarting the service)
3- notify that reconfig is in progress and the request is ignored
Jeff expressed a preference for option 3.
#8 Updated by Dennis Box almost 2 years ago
- Status changed from New to Feedback
- Assignee changed from Dennis Box to Marco Mambelli
Changes in branch v3/17417 branched from branch_v3_2.
Implemented preference choice 3). Output goes to /var/log/messages and is viewable with systemctl status gwms-factory or systemctl status gwms-frontend.
Easiest way to test is probably to put a sleep call in creation/reconfig_glidein or creation/reconfig_factory.