[7.860][BUG][FIXED] Time change causes high cpu usage.

This probably has been the default behavior of all astaro 7s but it should be fixed if possible. In webadmin -->management-->time settings, change the time to something and hit apply and within a few seconds change the date and hit apply again. Both changes are sent to the backend system instantly which causes system instability and high cpu usage. 

In a regular scenario it is very possible for an admin to change time and hit apply and then notice the date being wrong and hit apply again within a few seconds. Screenshot attached of the system log when the system is in this high cpu stage.
Parents
  • Astaro Beta Report
    --------------------------------
    Version: 7.860
    Type: BUG
    State: MERGED/FIXED
    Reporter: Billybob
    Contributor:  
    MantisID: 12375
    Target version: 7.865
    Fixed in version: 7.865
    --------------------------------

  • I am not going to argue the NTP awesomeness since this has nothing to do with NTP. An enterprise firewall specially one running linux should not have its load average sky rocket just because of a couple of random clicks ultimately resulting in a terminated webadmin session.

    I think you guys are on the right track changing the message when the time settings are applied. Maybe a little filter that queues the multiple clicks and submits as one single command at the end would be optimal.

    But thanks for looking into this. As I have noted elsewhere, you guys have done an extremely impressive job with this build considering we are still in alpha stages.

    Best Regards
    Bill.
Reply
  • I am not going to argue the NTP awesomeness since this has nothing to do with NTP. An enterprise firewall specially one running linux should not have its load average sky rocket just because of a couple of random clicks ultimately resulting in a terminated webadmin session.

    I think you guys are on the right track changing the message when the time settings are applied. Maybe a little filter that queues the multiple clicks and submits as one single command at the end would be optimal.

    But thanks for looking into this. As I have noted elsewhere, you guys have done an extremely impressive job with this build considering we are still in alpha stages.

    Best Regards
    Bill.
Children
No Data