Creating a bug report/issue
 I have searched the existing open and closed issues
Required Information
- DietPi version | 8.24.1
 
- Distro version | bookworm
 
- Kernel version | 6.1.0-13-amd64
 
- Architecture | amd64
 
- SBC model | Intel Nuc
 
Additional Information (if applicable)
- Software title | crontab / shutdown
 
- Was the software title installed freshly or updated/migrated? freshly installed
 
- Can this issue be replicated on a fresh installation of DietPi? Yes
 
Steps to reproduce
- sudo crontab -e
 
- add: 30 22 * * * /usr/sbin/shutdown -h 0
or 30 22 * * * bash /root/shutdown.sh
or 30 22 * * * /bin/bash /root/shutdown.sh 
Content of /root/shutdown.sh:
#!/bin/bash
/usr/sbin/shutdown -h 0
Expected behaviour
- PC should shutdown every day at 22:30.
 
Actual behaviour
- On the first day after the crontab was changed, the cronjob works normally. On the following days, the PC doesn’t shut down.
 
- After manual execution of the /root/shutdown.sh script, DietPi shuts down normally.
 
Extra details
- Dietpi starts with LXDE Desktop
 
- In crontab of root user this line was added: @reboot startx
 
- After the boot process has finished, the software feh starts a Slideshow on the connected monitor
 
             
            
              
              
              
            
            
           
          
            
            
              did you already checked system log on the day cron was not executed?
journalctl -u cron
             
            
              
              
              
            
            
           
          
            
            
              Actually no. I can check this in the evening.
Here are the first lines of the logs right now:
Dec 07 08:42:27 Collin systemd[1]: Started cron.service - Regular background program processing daemon.
Dec 07 08:42:27 Collin cron[527]: (CRON) INFO (pidfile fd = 3)
Dec 07 08:42:27 Collin cron[527]: (CRON) INFO (Running @reboot jobs)
Dec 07 08:42:27 Collin CRON[529]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec 07 08:42:27 Collin CRON[534]: (root) CMD (startx)
Dec 07 08:45:01 Collin CRON[1195]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec 07 08:45:01 Collin CRON[1196]: (root) CMD (bash /root/heif-convert.sh)
Dec 07 08:45:01 Collin CRON[1195]: (CRON) info (No MTA installed, discarding output)
Dec 07 08:45:01 Collin CRON[1195]: pam_unix(cron:session): session closed for user root
Entries 6-9 repeat every five minutes. This is because the script /root/heif-convert.sh is executed every five minutes, so this would make sense.
Actually I don’t know, why the cron.service is started at 8:42, when the Nuc starts at 7:30 via wake on lan.  Date and time are correct (checked via “date” command).
The entries above are the first ones in the log, so adding “-n 100” to the journalctl command does not show more / earlier entries.
             
            
              
              
              
            
            
           
          
            
            
              you could check whole log running journalctl to see what happen around 8:42
             
            
              
              
              
            
            
           
          
            
            
              Ok there I tested a small change to the /root/shutdown.sh script. So the time stamp seems reasonable.
But the problem with the non-working cronjob at 22:30 persists.
             
            
              
              
              
            
            
           
          
            
            
              
just check log once cron has not triggered the shutdown
             
            
              
              
              
            
            
           
          
            
            
              So this is the actual crontab:
*/5 * * * * bash /root/heif-convert.sh
30 22 * * * /usr/sbin/shutdown -h 0
@reboot startx
In the logs I can see, that the Nuc restarted at 22:30 instead of shutting down. Do you have any idea, why the nuc restarts instead of staying off? Do you think wake on lan might be a problem?
             
            
              
              
              
            
            
           
          
            
            
              You could try power off instead of shutdown command. But maybe there is a client within the network who forced the reboot.
             
            
              
              
              
            
            
           
          
            
            
              I also tried the /usr/sbin/poweroff command, but that didn’t work either.
I have a proxmox host in the same network, but this sends only one magic package at 7:30. But I will search for other hosts.
             
            
              
              
              
            
            
           
          
            
            
              Ok, so I found the problem.
In the BIOS I had activated, that the Nuc should start at 7:30 am. Since this did not work, I switched to the WOL solution. When I switched off the BIOS setting, the Nuc shuts down perfectly at 22:30 and stays off.
             
            
              
              
              1 Like