Description of problem: We are facing some issue with rhn_check / computer restarting. We are using action chains in order to appy stuff like: * execute something * restart node * execute something The problem occurs when restarting the node. The shutdown command is: "shutdown -r +3", but the delay of the restarting task is less than 3 minutes, and this is confirmed by the fact that the node never restart. Version-Release number of selected component (if applicable): Server is in 2.5 rhn_check 2.5.16-1 How reproducible: I would be able to reproduce, but this seems to happen randomly, on different nodes. Actually we are not able to say that it happens in a specific case. Steps to Reproduce: 1. 2. 3. Actual results: Sorry for french: Redémarrage du système programmé par SomeUser Cette action sera exécutée après 23/07/17 10:00:00 CEST Le statut de cette action est : Terminé. Le client a détecté cette action sur 23/07/17 10:07 Le client a terminé cette action sur 23/07/17 10:07 This typically says: restart shceduled this action will run after 23/07/17 10:00:00 CEST status is ended The client has detected this action at 23/07/17 10:07 The client has ended this action at 23/07/17 10:07 So above, you can see that the delay between start and end is 0. Expected results: Redémarrage du système programmé par SomeUser Cette action sera exécutée après 23/07/17 10:00:00 CEST Le statut de cette action est : Terminé. Le client a détecté cette action sur 23/07/17 10:07 Le client a terminé cette action sur 23/07/17 10:10 (or more) Additional info: NA
Hello, what OS is your client using?
Hello, The bug has been fixed. It's due to the fact that we are using a cron job to call rhn_check. What happens is: * Cron call rhn_check -> ActionChain is executed until the reboot +3 * A new cron call rhn_check before the reboot is done -> The postreboot action is executed => If you want my advice, this is a design problem But it's easy to fix by checking that a shutdown process is not running before calling rhn_check. Regards
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.