Cronjob + unwanted reboot

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=10
G_DIETPI_VERSION_RC=0
G_GITBRANCH=‘beta’
G_GITOWNER=‘MichaIng’

Additional Information (if applicable)

Raspi 5 // installed on Pimoroni NVMe Base 512 GB
Dietpi updated

Expected behaviour

shutdown -h now and power cut of by Shelly Smart plug S 5 mins later

Actual behaviour

Actually I have no idea from where the command comes for immediatly reboot. Is there anything within nextcloud ?

Tks for a hint :slight_smile:
Henning

@reboot means that that these cron jobs are execute at reboot. It’s not a command to reboot. crontab(5) - Linux manual page

1 Like

Tks, I did not know this :grinning:

Hi,
something is still not ok with the cronjob for shutdown.
The idea is to shutdown the system @01:00 Hrs and 15 mins later power is cut off by a shelly plug S

As you can see the system changes the time and continues to do something until the power is switched off. With that I could life but when the system is started next morning the internet connection is not working. Not internally or externally. Quick solution in the morning is “power off & power on” and bingo everything works as planned.

Any idea ? Or more info’s needed ?

Tks

Is the system started together with your internet router?

The Cablebox/ Router runs 24/7

I forgot to mention that I have also a Raspi 4 which is setup more or less identical ( dietpi up to date , shutdown same time , power off with a shelly Plug ) and but
no problems

once system is up, check the log why network was not established

Hi, strangely enough the Lan scanner can see the Raspi in question, ping works also. But no connection to the Raspi via ssh. In dietpi-config I can check the connection and it responds with no connection. Setting ist for static IP.
Reboot again and it works. :thinking:

best to check ip a to see assinged IP’s. As well you can try to ping your gateway from DietPi device.

This morning the system started normal. But I found that the onboard wifi was still switched on, even so no connection was setup before. Now it’s switched off andd maybe that was the reason. Wait nd see what happens tomo.
If I try to reboot now it usually works.

Good morning, finally I was able to check with “ip a” and ping the router dirct from the said raspi. Since normally no Monitor attached it took a bit of time to find something suitable

after reboot Network is reachable again.

On a side note : can I disable the fake hwclock or at least set her to our local time ?

Tks

can you ping the local IP/adapter itself?

ping 192.168.1.25

and after reboot it has the very same IP address 192.168.1.25 ??

what did you expect from this? hwclock will reload the last saved timestamp during a reboot so that the system at least has a time when booting. Normally this is the time at which the system was regularly switched off with poweroff. Or in the case of an unexpected shutdown due to power loss, it is the time of the hourly cron job that saves a timestamp regularly. Normally the 17th minute of an hour. As soon as a network connection is established, the system time is updated via NTP.

Tks, but the hardware clock defaults to GMT and this mostlikely confuses the system.


So as you can see the shutdown was initiated but a few seconds later it looks like a restart. The HWClock issue is basically history because I received today a RTC Battery /Akku for the PI5. Wait and see what happens.

Tks

Yes, this is how it should be. The system uses the timestamp when the system was stopped until it can update the system time via NTP or similar. What other time should it use when booting? The system does not know what time it is.

How could that confuse the system?

Today I powered on a system that was offline for weeks. It used the timestamp which was saved when it stopped

root@dietpi5:~# journalctl
Feb 17 12:54:57 DietPi5 kernel: Booting Linux on physical CPU 0x0000000000 [0x414fd0b1]
Feb 17 12:54:57 DietPi5 kernel: Linux version 6.6.74+rpt-rpi-2712 (serge@raspberrypi.com) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27)

As soon as a network connection was available, the system time was updated. The DHCP request also works without the correct system time.

Feb 17 12:55:03 DietPi5 kernel: macb 1f00100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Feb 17 12:55:03 DietPi5 systemd[1]: systemd-rfkill.service: Deactivated successfully.
Feb 17 12:55:07 DietPi5 dhclient[398]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Feb 17 12:55:07 DietPi5 ifup[398]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Feb 17 12:55:07 DietPi5 dhclient[398]: DHCPOFFER of 192.168.0.24 from 192.168.0.11
Feb 17 12:55:07 DietPi5 ifup[398]: DHCPOFFER of 192.168.0.24 from 192.168.0.11
Feb 17 12:55:07 DietPi5 ifup[398]: DHCPREQUEST for 192.168.0.24 on eth0 to 255.255.255.255 port 67
Feb 17 12:55:07 DietPi5 dhclient[398]: DHCPREQUEST for 192.168.0.24 on eth0 to 255.255.255.255 port 67
Feb 17 12:55:07 DietPi5 dhclient[398]: DHCPACK of 192.168.0.24 from 192.168.0.11
Feb 17 12:55:07 DietPi5 ifup[398]: DHCPACK of 192.168.0.24 from 192.168.0.11
Feb 17 12:55:07 dietpi5 systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
Feb 17 12:55:07 dietpi5 systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Feb 17 12:55:07 dietpi5 systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
Feb 17 12:55:07 dietpi5 systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
Feb 17 12:55:07 dietpi5 systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
Mar 19 16:59:50 dietpi5 systemd-timesyncd[475]: Contacted time server 192.168.0.11:123 (192.168.0.11).
Mar 19 16:59:50 dietpi5 systemd-timesyncd[475]: Initial clock synchronization to Wed 2025-03-19 16:59:50.295430 CET.
Mar 19 16:59:50 dietpi5 dhclient[398]: bound to 192.168.0.24 -- renewal in -2570679 seconds.
Mar 19 16:59:50 dietpi5 ifup[398]: bound to 192.168.0.24 -- renewal in -2570679 seconds.

Hi,
tks for yr reply. With confusing I meant that after shutting down at night the network connection was not working next morning until the system was rebooted again.
Since I installed the backup battery it seems to be ok.


23:58 Shutdwon intiated and completed. This morning normal start.
So case closed :grin: