Tags:
create new tag
view all tags

Running Daily Tasks

System administrators often need to run tasks on a daily basis. Rather than adding a crontab entry for each individual task it is often better to run them as a set of sequential tasks which can be scheduled for a time when the machine is likely to be "quiet".

Prior to EL7 this is done using the LCFG boot component. With EL7 the init system was switched to Systemd so the boot component no longer exists, instead this is now done with a specialist runner component.

When tasks are run

The time at which the daily tasks are run is usually specified in the _DAILY_UPDATE_TIME macro, this is intended to hold the time parts of the associated crontab entry. The default value is AUTO 5 * * *, the AUTO field tells the LCFG cron component to randomly select the minutes, that's very useful to avoid all machines attempting to install package updates simultaneously which might overwhelm your package servers. See the LCFG cron component documentation for more details on the extra features it supports.

Using the boot component

Note that the LCFG boot component is not available for EL7 onwards

When using the boot component tasks are added to the boot.run resource. For each task there are 3 sub-resources which can be specified: runmethod_<task>, user_<task> and reboot_<task>.

The type of the task is encoded in the LCFG tag name and is the prefix prior to the first underscore (e.g. the type for lcfg_updaterpms is lcfg). There are two supported types: lcfg (for LCFG components) and direct (any other script).

For LCFG components the component name is taken from the second part of the tag name (e.g. the name for lcfg_updaterpms is updaterpms) and the component method comes from the runmethod resource, by default the value of the runmethod_<task> resource is run. The task is executed using om (e.g om updaterpms run). If the verbose flag for the boot component has not been set this will be executed with the quiet (-q) flag to minimise the output.

For other (direct) scripts the command to be executed is taken from the runmethod_<task> resource.

For both LCFG components and direct scripts it is possible to run as an alternative user by setting the user_<task> resource. Note that for LCFG components this should not normally be necessary and there are typically better ways to change the effective user.

The tasks are run according to the sequence in which the tags appear in the boot.run resource. This means the order of execution is predictable, this is particularly useful when you need to run some components to clean up after package updates have been applied using updaterpms.

Examples

In most cases adding a component to the task list will be as simple as:

!boot.run                      mADD(lcfg_updaterpms)

To change the component method which is called or modify the command line arguments, do something like this:

!boot.run                       mADD(dns)
!boot.runmethod_lcfg_dns        mSET(fixperms -q)

A direct script might be added like this:

!boot.run                                       mADD(direct_creport)
!boot.runmethod_direct_creport                  mSET(/usr/lib/orders/bin/clientreport >/var/lcfg/tmp/clientreport.log 2>&1)

The tasks are run by the LCFG boot component run method which is called by cron. If necessary the time at which this cron job is run can be modified by altering the cron.run_boot resource. For example:

!cron.run_boot   mSETQ("AUTO(0..59) AUTO(0..6,19..23) * * *")

Which would restrict the permitted times to between 19:00 to 06:59 thus spreading the running of daily updates across a much wider time range.

Using the runner component

When using the LCFG runner component, tasks are added to the runner.tasks resource. For each task there are 7 sub-resources which can be specified:

type_<task>
This can be one of lcfg, service or direct. If it is set to lcfg (the default) the task will be considered to be an LCFG component method call (e.g. updaterpms run). If it is set to service the task will be considered to be a service method call (e.g. apache reload). If it is set to direct then it is considered to be an arbitrary command.
cpt_<task>
If the type is lcfg then this is the name of the LCFG component (e.g. "updaterpms"). If the type is service then this is the name of the service (e.g. "apache"). If not specified then the task tag name will be used. This field is ignored when the type of the task is direct.
method_<task>
If the type is lcfg then this is the name of the LCFG component method (e.g. "run"). If the type is service then this is the name of the service method (e.g. "reload"). If the task type is direct this is the name of the arbitrary command which should be executed. For LCFG components the default value is "run".
args_<task>
This is a string resource which can be used to specify any arguments that should be passed to the command.
user_<task>
The effective user to run as for this task. This is only likely to be useful for direct tasks, for LCFG components this should not normally be necessary and there are typically better ways to change the effective user.
timeout_<task>
This is the number of seconds after which the command should be killed if it is still running. If the resource is not specified or the value is zero then this means no timeout will be applied. The default timeout is 7200 (2 hours).
mailto_<task>
This resource can be used to specify email address to which any output should be sent. If it is not specified then output will be sent to the current user (typically root). This is intended to give better control of the output destination than can be achieved by setting the MAILTO environment variable in the crontab.

Examples

In most cases adding a component to the task list will be as simple as:

!runner.tasks                      mADD(updaterpms)

To change the component method which is called, do something like this:

!runner.tasks                            mADD(dns)
!runner.method_dns                       mSET(fixperms)

Alternatively there is a CPP macro which can be used like this:

LCFG_RUNNER_ADD_COMPONENT(dns,fixperms)

A direct script might be added like this:

!runner.tasks                           mADD(creport)
!runner.type_creport                    mSET(direct)
!runner.method_creport                  mSET(/usr/lib/orders/bin/clientreport)

Alternatively there is a CPP macro which can be used like this:

LCFG_RUNNER_ADD_DIRECT(creport,/usr/lib/orders/bin/clientreport)

The first argument there is an LCFG tag which must be specified since many script names are not safe for use as LCFG tags (e.g. they contain forward-slashes and hyphens). Note that due to the way the runner component executes commands it is NOT possible to redirect output when running direct scripts.

The service type is only supported by the runner component, it can be used like this:

!runner.tasks                          mADD(apache)
!runner.type_apache                    mSET(service)
!runner.method_apache                  mSET(reload)

Alternatively there is a CPP macro which can be used like this:

LCFG_RUNNER_ADD_SERVICE(apache,apache,reload)

The first argument there is an LCFG tag which must be specified since many service names are not safe for use as LCFG tags (e.g. they contain hyphens). That example would reload apache on a daily basis.

The tasks are run by the LCFG runner component run method which is called by cron. If necessary the time at which this cron job is run can be modified by altering the cron.run_runner resource. For example:

!cron.run_runner   mSETQ("AUTO(0..59) AUTO(0..6,19..23) * * *")

-- Main.squinney - 2015-04-01

Topic revision: r1 - 2015-04-01 - squinney
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback