Scheduling tasks in Linux is traditionally done with the Cron Task Scheduler. There are many online resources about cron, one of which is this site, https://www.vultr.com/docs/how-to-use-the-cron-task-scheduler/. With Webmin, the task scheduling can be managed through the WebUI. Details can be found here, https://doxfer.webmin.com/Webmin/Scheduled_Cron_Jobs. Here is a simple scheduled task that reboots the Linux host daily at 1:30am.
30 1 * * * systemctl reboot -i
Scheduling this in Cron or through Webmin results in the same entry in the respective crontab file.
Some tasks are poorly designed, or implemented in a way that they weren’t intended for. In those instances, the process can do some strange things. This can result in a process hang, memory leak, or cascading processes that exhaust system resources, to name some examples. Restarting those processes is a quick and dirty workaround, but by no means a fix. This is where scheduled tasks can be leveraged.
13,28,43,58 * * * * node-red-restart
Some tasks don’t lend themselves well to automated scheduling, one of them being RTL433. This particular example, https://www.cloudacm.com/?p=3501, would run for a period of time, but then stop for one reason or another. Here is where Supervisor has been demonstrated to help keep tasks running, https://www.hagensieker.com/wordpress/2019/03/06/how-to-keep-rtl_433-alive-for-your-home-automation-using-supervisor/. Depending on the extensive use of Supervisor, some might argue that each task have its own conf file with the command parameters contained in each. Here is an example of a conf file located in this path, /etc/supervisor/conf.d/rtl443.conf.
[program:rtl433] command=/bin/sh /home/local/Tasks/RTL433-MQTT.sh autostart=true autorestart=true startretries=100 stderr_logfile=/var/log/rtl433/rtl433.err.log stdout_logfile=/var/log/rtl433/rtl433.out.log
Everyone is free to do as they see fit, whether they see it that way or not, consequence is secondary.