Task Scheduler


Recommended Posts

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

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment
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

Link to comment

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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.