Okey this was a long time request for myself, but since it was not made by somebody else, I took the callenge up by myself, with the help of some AI…
The plugin is called ‘ScheduledRestart’ and is awaiting approval from Volumio.
This is a screenshot:
Nice. I created a new topic for you, so everything is in one place.
[Mod=Wheaten]
Korniman is refering to:
Dear Sina, thank you for the great effort.
One request, Instead of using Cron, was there an issue not to take over the still robust working method described above and to connect it with a GUI like created by you? What was the intension to trigger the function with a Cronjob instead?
Cheers Korniman
@Korniman-the-Rooky I was just no able to get it to work with a system-reboot.timer. I tried to make an install script for a system-reboot.timer but I could not get the permissions right to do a reboot. Then I changed my approach to the system-reboot.timer firing a reboot script in the plugin directory, but it would stick in a reboot loop, no matter what I tried.
The method I’m now using is a very simple, but very effective one, so for now I’m sticking to node-cron.
Dear Simania, maybe someone get this to work with system-reboot.timer. How ever for time beeing this will work for sure. Thank you!
Just a little more background information about ‘node-cron’ versus ‘reboot.service’.
Node-cron writes it schedule and command to the memory, here is the line of code in scheduledrestart:
var job = cron.schedule(cronTime, function() {
self.logger.info('Rebooting system as per schedule...');
exec('sudo reboot', (error, stdout, stderr) => {
if (error) {
self.logger.error(`Error executing reboot: ${error}`);
This causes the schedule to only stay persistent if Volumio is restarted correctly and the plugin with the schedule is reloaded into the memory. If you would power down unexpectedly or volumio would crash, you still could reboot and ‘ssh’ or get into the Volumio UI’. Also if the plugin is corrupt the system just keeps working.
The reboot service is handled by the systemctl-daemon and works outside of Volumio. This means that if the service has a problem, your system could become unusable and you can’t ‘ssh’ or get into the Volumio UI. The pro’s are it is working regardless of Volumio, but that’s also a risk, if the uninstall is not working as expected the deamon just keeps loading the service, untill you manually can stop it.
When I wrote the code and tried to use the service, I ended up with a system which kept on rebooting, I know this is due to my lack of knowledge, and had to reflash and reinstall Volumio multiple times, but when I used ‘node-cron’ and something was not correct, nothing happend.
In the end I could rewrite to use the reboot.service but I don’t see any advantage over using ‘node-cron’. Please let me know if you think that there are other pros or cons.
Hi!
Have you considered Use systemd timers instead of cronjobs | Opensource.com ?
@balbuze yes I did, but I could not get it to work, which caused system reboot loops. That problem is being tackled by node-cron via the plugin.
Just to clarify ‘node-cron’ stores its action and schedule in the memory, cron on the other hand needs a cronjob file with the action and schedule. I could see why you would port cronjobs to system.d timers, but since I use ‘node-cron’, I don’t see any pros for this plugin. The fact that it is written to the memory is just a very good safeguard.