Comware

Hi everyone,

I have a trouble with a scheduled task on HPE switches (HP 1920-24G JG924A).

I use SSH to schedule a reboot. When I set :

"schedule reboot at 10:15" : it works (reboot ok)

"schedule reboot at 23:00" : it doesn't work (no reboot) 

is there a limitation about the datetime format ?

Thanks

Is the system time properly/correctly set on the Switch?

<HP1920-8G_A>schedule reboot at ?
  STRING  Exact time(hh:mm)
<HP1920-8G_A>display time-range all
Current time is 12:03:28 6/23/2016 Thursday

Which Firmware version are you running on your HPE OfficeConnect 1920-24G (mine is at R1112)?

<HP1920-8G_A>display ntp-service status
 Clock status: synchronized
 Clock stratum: 3
 Reference clock ID: 193.234.225.237
 Nominal frequency: 100.0000 Hz
 Actual frequency: 100.0000 Hz
 Clock precision: 2^18
 Clock offset: -3.7511 ms
 Root delay: 32.03 ms
 Root dispersion: 4.65 ms
 Peer dispersion: 2.67 ms
 Reference time: 10:06:49.979 UTC Jun 23 2016(DB163339.FACC2D6A)

<HP1920-8G_A>display ntp-service sessions
 source reference stra reach poll now offset delay disper
********************************************************************************
[12345]193.234.225.237 193.204.114.233 2 63 64 39 -4.4  28.5 1.2
  [245]94.23.66.89     193.204.114.233 2 63 64 30 -13.2 44.9 2.0
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
Total associations : 2

<HP1920-8G_A>display ntp-service trace
 server 127.0.0.1,stratum 3, offset -0.006649, synch distance 0.02237
 server 193.234.225.237,stratum 2, offset 0.007407, synch distance 0.00273
 server 193.204.114.233,stratum 1, offset -0.014117, synch distance 0.00015
 refid CTD

<HP1920-8G_A>schedule reboot at 23:30
Reboot system at 23:30 06/23/2016(in 11 hour(s) and 23 minute(s)). confirm? [Y/N]:Y
<HP1920-8G_A>display schedule reboot 
System will reboot at 23:30 06/23/2016 (in 11 hours and 23 minutes).

Are the settings above similar to your ones (NTP apart)?

The schedule reboot at 23:30 command generated this log line:

%Jun 23 12:06:10:969 2016 HP1920-8G_A CMD/5/CMD_REBOOT_SCHEDULED: vty0(192.168.0.10) set schedule reboot parameters at 12:06:10 06/23/2016, and system will reboot at 23:30 06/23/2016.

Indeed it rebooted at scheduled time (23:30):

<HP1920-8G_A>display schedule reboot
System will reboot at 23:30 06/23/2016 (in 0 hours and 6 minutes).
<HP1920-8G_A>display schedule reboot
System will reboot at 23:30 06/23/2016 (in 0 hours and 3 minutes).
<HP1920-8G_A>
%Jun 23 23:29:28:030 2016 HP1920-8G_A CMD/4/CMD_REBOOT_SOONAFTER:
***
*** --- REBOOT IN ONE MINUTE ---
***
#Jun 23 23:30:28:048 2016 HP1920-8G_A DEVM/1/REBOOT:
 Reboot device by command.

%Jun 23 23:30:28:139 2016 HP1920-8G_A DEVM/5/SYSTEM_REBOOT: System is rebooting now.
System is starting...

But now I've a doubt: when I first issued the schedule reboot at 23:30 command during yesterday afternoon I saved the system configuration (safely) via CLI and finally closed the Telnet session leaving the Switch turned on.

Once I logged again yesterday late night (just few minutes before the scheduled reboot time and after few hours since the command was executed) I suddenly issued a display schedule reboot command to check the status of the scheduled reboot and noticed the Switch reported nothing (no scheduled reboot at all): I re-issued the very exactly schedule reboot at 23:30 command (the Switch accepted the command as it was the very first time it was committed) and verified that the schedule reboot was correctly displayed/reported *again* (as happened in the afternoon), then I waited to see what happens.

The Switch rebooted (see above).

I also checked that the Switch didn't reboot *before* the scheduled reboot time.

The question is:

Does interrupting Telnet session impact (erase) the committed command (schedule reboot) or was it only a glitch on the Switch?

In other words:

Do we need to keep the session constantly open to permit the command to be executed (at scheduled time) or that isn't relevant at all?

Hi parnassus,

Thanks for your answer,

Is the system time properly/correctly set on the Switch?

-> Yes it is.

<HP 1920G Switch>schedule reboot at ?
  STRING  Exact time(hh:mm)
<HP 1920G Switch>display time-range all
Current time is 08:26:40 6/27/2016 Monday

Which Firmware version are you running on your HPE OfficeConnect 1920-24G (mine is at R1112)?

It depends on the switch. I've about 70 switches in R1111 and R1112 the problem is for both.

In fact my goal is to upgrade the switch from R1111 to R1112 that's why I want to schedule a reboot.

<HP 1920G Switch>display ntp-service status
 Clock status: synchronized
 Clock stratum: 2
 Reference clock ID: X.X.X.X
 Nominal frequency: 100.0000 Hz
 Actual frequency: 100.0000 Hz
 Clock precision: 2^18
 Clock offset: 3.5307 ms
 Root delay: 10.86 ms
 Root dispersion: 10.39 ms
 Peer dispersion: 10487.70 ms
 Reference time: 07:29:48.433 UTC Jun 27 2016(DB1B546C.6EFDEB52)

<HP 1920G Switch>display ntp-service sessions
       source          reference       stra reach poll  now offset  delay disper
********************************************************************************
[12345]X.X.X.X        LOCL               1   255   64   39    0.0   10.9   17.0
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
Total associations :  1

<HP 1920G Switch>display ntp-service trace
 server 127.0.0.1,stratum 2, offset -0.009980, synch distance 10.53795
 server X.X.X.X,stratum 1, offset -0.052444, synch distance 10.48975
 refid LOCL

<HP 1920G Switch>schedule reboot at 23:30
Reboot system at 23:30 06/27/2016(in 14 hour(s) and 56 minute(s)). confirm? [Y/N]:Y

<HP 1920G Switch>display schedule reboot
System will reboot at 23:30 06/27/2016 (in 14 hours and 56 minutes).

This is the generated command :

%@10419%Jun 27 08:33:30:625 2016 HP 1920G Switch CMD/5/CMD_REBOOT_SCHEDULED: vty0(X.X.X.X) set schedule reboot parameters at 08:33:30 06/27/2016, and system will reboot at 23:30 06/27/2016.

The question is:

Does interrupting Telnet session impact (erase) the committed command (schedule reboot) or was it only a glitch on the Switch?

In other words:

Do we need to keep the session constantly open to permit the command to be executed (at scheduled time) or that isn't relevant at all?

I use SSH and not Telnet. For SSH, i tested a schedule reboot in 10min. I closed the SSH connexion and the switch correctly rebooted. But the same thing for 23:00 (in 10 hours for example) didn't work. I haven't tried to leave the SSH connexion open. I'll try it tonight.

Does interrupting Telnet session impact (erase) the committed command (schedule reboot) or was it only a glitch on the Switch?

I have a preference for the glitch. Because if I close the SSH connexion and reboot is scheduled in 10-20min it's ok. But if the reboot is scheduled in 8-9-10 hours it doesn't work.

Could it be that the NTP synchronization, once happened (in a time range of few hours it probably happens more frequently than in a time range of only 10/20 minutes), is able to disrupt the (scheduled reboot) countdown?

Will be interesting to make a test with NTP Synchronization disabled at all. In both cases it looks like a Bug.

It's a good question...

I've disabled the NTP and scheduled a reboot at 23:00. I tell you tomorrow what happens.

It works !

The trouble is due to NTP ...

Where can I contact HP Team to feedback (bug report) about it ?

My Network -> My Support -> Select a (registered?) Product -> Web Case Support (support by E-mail) -> Case Submission.

I'm curious how support will handle this.  You're using CLI, which officially isn't supported.

My Network -> My Support -> Select a (registered?) Product -> Web Case Support (support by E-mail) -> Case Submission.

Thank you. 

I'm curious how support will handle this.  You're using CLI, which officially isn't supported.

Yes, officially isn't supported but I don't require a correction. It is just for knowledge then they will do as they like :)

It will be interesting to see.

The day (maybe never if nobody issue a Feature Request) the HPE OfficeConnect 1920 Switch Series will let to schedule a reboot through its Web GUI with NTP enabled...well...that day this issue will become officially relevant!

Until that day, as it was pointed out, it's just additional specific knowledge we gained by trials and errors.

Thanks for your analysis. You guys are awesome and just saved me a lot of hassle.
I guess for reboots/upgrades outside of business hours I'll have to revert to using an
old-fashioned alarm clock and logging into my office from home.

<sarcasm>How could anyone possibly make better use of his free time?</sarcasm>

Yeah!

My take: we all will start to have real free time the day devices will auto-manage themself in total autonomous way (so any actual implemented auto-xxx feature will be interesting if useful and robust enough to not cause unnecessary unwanted disruptions on running devices if compared to the same without that auto-xxx feature enabled)...at present time we have just two options regarding correctly working devices: (a) forget them until they break and (b) manage them to avoid they break.