GHunter Posted December 5, 2014 Share Posted December 5, 2014 I would like to see the task scheduler expanded to be more configurable. We already have a few items that can be scheduled in unRAID, like a parity check and the cache mover, plus there other scripts or functions that people add manually to cron like smart drive tests, backup or sync, and array status emails. A central place to schedule pre-defined functions and add additional ones would be cool. Could be something as simple as a script or .xml or .plg file that performs some function, we select it from a list (list box) or add a new one (similar to installing a plugin), and then we can schedule it by time, day, week, etc. Even better would be to add the ability to add shutdown and startup tasks in the same way as the other tasks. As far as displaying scheduled tasks to the user, they could be displayed with a calendar or a queue list sorted by time and date. I’m sure others have some good ideas about this too. This is probably something to add later on or in stages. Not really a short term or easy request to accommodate. Gary Quote Link to comment
jonp Posted December 7, 2014 Share Posted December 7, 2014 We have discussed this internally as well. I personally feel the moved tab from global share settings should actually belong on the scheduler page as well as additional functions. Brainstorm away on what sort of things you'd like to see! Quote Link to comment
WeeboTech Posted December 7, 2014 Share Posted December 7, 2014 I'm not sure how many people are aware of this but any crontab style file placed in /etc/cron.d can be used to schedule tasks. Thus I would love to see a tool display a list of files in /etc/cron.d (The browser code already exists in emhttp). When you click on a file (or elect to add a new one) Display a list of entries or template for changing. This could be in two phases. 1st phase would be a simple text area box for editing cron entries with some displayed help 2nd phase would be a more formal form field screen that would compartmentalize the fields for changing. I.E. a generic crontable style editing tool. This would help the novices. I'm going to paste an example This is my /etc/cron.d/md_write_method crontable. root@unRAID1:/etc/cron.d# more md_write_method 30 08 * * * /root/mdcmd set md_write_method 1 30 23 * * * /root/mdcmd set md_write_method 0 # # * * * * * <command to be executed> # | | | | | # | | | | | # | | | | +---- Day of the Week (range: 1-7, 1 standing for Monday) # | | | +------ Month of the Year (range: 1-12) # | | +-------- Day of the Month (range: 1-31) # | +---------- Hour (range: 0-23) # +------------ Minute (range: 0-59) In this file I turn on turbo write when I'm actively working on the array and turn it off when 'should' be going to bed. Here is my crontable called parity_check in the same directory. root@unRAID1:/etc/cron.d# more parity_check 00 00 27 * * /root/mdcmd check NOCORRECT # # * * * * * <command to be executed> # | | | | | # | | | | | # | | | | +---- Day of the Week (range: 1-7, 1 standing for Monday) # | | | +------ Month of the Year (range: 1-12) # | | +-------- Day of the Month (range: 1-31) # | +---------- Hour (range: 0-23) # +------------ Minute (range: 0-59) Point here is, it's easy to compartmentalize like tasks and provide drop in / remove out functionality i.e. badblocks tests per disks, smartd batch onetime monitors. md5 calc/store/checks. etc. etc instead of all the magic in crontab command pipes i.e. crontab -l | grep >> tmpfile sed -i tmpfile crontab < $tmpfile By rsyncing the files into a config/cron.d directory you can back them up and restore them with a few commands. so 4 modes are needed. browse list of tables. add (new table) which adds the template. click on a table to view it click on edit to edit it click on delete to delete what you are viewing. other examples of my current configuration. root@unRAID1:/etc/cron.d# find /etc/cron.d -ls drwxrwxrwx 2 root root 0 Dec 6 22:08 /etc/cron.d -rwxrwxrwx 1 root root 366 Sep 16 15:24 /etc/cron.d/parity_check -rwxrwxrwx 1 root root 73 Feb 27 2014 /etc/cron.d/notice -rwxrwxrwx 1 root root 419 Oct 26 18:28 /etc/cron.d/md_write_method -rwxrwxrwx 1 root root 730 Oct 26 18:28 /etc/cron.d/filelist -rwxrwxrwx 1 root root 130 Oct 26 18:28 /etc/cron.d/badblocks -rwxrwxrwx 1 root root 130 Oct 26 18:28 /etc/cron.d/smartmon -rwxrwxrwx 1 root root 130 Oct 26 18:28 /etc/cron.d/hash -rwxrwxrwx 1 root root 130 Oct 26 18:28 /etc/cron.d/rsync_backup To expand on this further. By using the browse functionality via basic list/add/view/edit/delete and editable textarea, now you can scan all of the cron directories and provide access to the cron.d cron.daily cron.monthly cron.hourly files. I.E. root@unRAID1:/etc/cron.d# find /etc/cron* -type d /etc/cron.d (This directory contains supplementary drop in / remove out crontables, but /etc/cron.daily (These directories contain scripts that run 1 behind the other at specifically scheduled times) /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly Quote Link to comment
GHunter Posted December 7, 2014 Author Share Posted December 7, 2014 Yeah, this was the direction I was thinking. I have a few scripts that are setup this way. But we need a webGUI page to manage and display them. Most users aren't able to do this sort of thing manually. Like a dressed up CPanel interface to cron jobs. There would be built-in tasks to select, like the mover or parity check, and users could add a script of their own to schedule and run. Email or log the results (or both). A lot of people have asked for startup and shutdown tasks too, so I thought this would be a good place to implement that too. Rather than chosing a date/time, you would choose an event, before or after array stop, or before or after array start. Security might be difficult though. I don't know anything about Linux security except what I read here. You'd have to protect users from screwing up stuff with scripts they found on the internet. Quote Link to comment
WeeboTech Posted December 7, 2014 Share Posted December 7, 2014 Yeah, this was the direction I was thinking. I have a few scripts that are setup this way. But we need a webGUI page to manage and display them. Most users aren't able to do this sort of thing manually. Like a dressed up CPanel interface to cron jobs. There would be built-in tasks to select, like the mover or parity check, and users could add a script of their own to schedule and run. Email or log the results (or both). A lot of people have asked for startup and shutdown tasks too, so I thought this would be a good place to implement that too. Rather than chosing a date/time, you would choose an event, before or after array stop, or before or after array start. Security might be difficult though. I don't know anything about Linux security except what I read here. You'd have to protect users from screwing up stuff with scripts they found on the internet. I wasn't thinking about events. And in that case, it becomes more difficult and a larger project. I'm not even sure that it should be that easy then. It's one thing to provide people access to list/modify a library/directory of configurations. But then the added. "You'd have to protect users from screwing up stuff with scripts they found on the internet." which means it needs to be canned and confined to only events that are known and programmed by limetech or a plugin author. You can' t have users adding in calls to scripts or programs and expect to protect them from themselves. Quote Link to comment
WeeboTech Posted December 7, 2014 Share Posted December 7, 2014 It's weird about mentioning of the startup/shutdown. Today I was working on a scriptlet for /boot/config/go and /boot/config/stop that would execute all scripts in /etc/rc.d/go.d and /etc/rc.d/stop.d respectively. Logging all to syslog. It was my first attempt to create a separate syslog_archive tool and drop it into the /etc/rc.d/stop.d directory. My goal was also a modification to add the syslog_archive to the /etc/logrotate.d/syslog file so it was archived before being rotated out. Quote Link to comment
GHunter Posted December 9, 2014 Author Share Posted December 9, 2014 Today I was working on a scriptlet for /boot/config/go and /boot/config/stop that would execute all scripts in /etc/rc.d/go.d and /etc/rc.d/stop.d respectively. Interesting. I have not yet found a need to use this yet. I have kill scripts for shutting down VM's which the apcupsd plugin handles for me. It was my first attempt to create a separate syslog_archive tool and drop it into the /etc/rc.d/stop.d directory. My goal was also a modification to add the syslog_archive to the /etc/logrotate.d/syslog file so it was archived before being rotated out. This is actually a good idea. Should be implemented in unRAID as default behavior. The powerdown plugin rotates logs but doesn't archive them. I might have to do this myself! Gary Quote Link to comment
WeeboTech Posted December 9, 2014 Share Posted December 9, 2014 It was my first attempt to create a separate syslog_archive tool and drop it into the /etc/rc.d/stop.d directory. My goal was also a modification to add the syslog_archive to the /etc/logrotate.d/syslog file so it was archived before being rotated out. This is actually a good idea. Should be implemented in unRAID as default behavior. The powerdown plugin rotates logs but doesn't archive them. I might have to do this myself! As far as I know, powerdown 'used' to prune the log archive directory for more then 10 logs, then archive the current syslog before shutting down. What's missing from unraid, is the archiving of the current syslog before rotating it out. Hence the reason I created a separate syslog_archive script. To be inserted to logrotate.d/syslog and also in the shutdown sequence. With a generic task scheduler script, you could schedule the syslog_archive when you wanted in the /etc/cron.daily directories or via some other cron schedule. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.