lcfg-autoreboot - Automates the rebooting of machines
This documentation refers to version 1.0.14 of autoreboot
This component allows system administrators to automate the rebooting of machines in response to requests from other LCFG components, such as updaterpms.
The component provides the option to either just nag users or both nag and enforce an automated reboot policy after a number of nagging messages. it has the flexibility to be adapted to the needs of different groups of users and types of computer installations. The component does not run continuously itself but rather it is designed to be called from cron, or similar, via the component's run method as often as you see fit for your system. Typically it would be expected to be called once daily at some point during the night but given the flexibility of configuring the at command you could run the component at any time and explicitly specify the time of reboot to suit the users.
This boolean value indicates whether the automatic reboot system is active at all. The component can be in the situation of being started but not active, this means that it will neither send the user nagging messages or enforce an automated reboot requirement. This defaults to true.
This boolean value indicates whether the automatic reboot system should enforce a policy of rebooting the system once the leeway has been exceeded. This defaults to false, only nag messages will be sent.
This is an integer and it indicates the leeway the system will give to a user when in enforcing mode. It is the maximum number of nag messages sent out that is indicated, not a measure of time. The default value is 5 nags allowed in enforcing mode. The number of nags carried out is stored between runs of the component in the countfile file. You can reset the number of nags counted back to zero by restarting this component.
This is the list of components which should be watched for reboot requests. By default no components are watched. You probably want to watch updaterpms, other possibilities are network, hardware, kernel and fstab but some times you probably really want to do those reboots by hand.
This is the nag message that is sent to the users when a reboot is required. It defaults to Reboot required, it can contain Perl Template Toolkit syntax and the resources of the component are available for inspection. An example is [% leeway.VALUE %], another is:
[% IF enforcing.VALUE %]automated reboot will occur[% END %]You can also embed newlines \n and tabs \t but you may need to escape them to avoid problems with the LCFG parser. They will be automatically unescaped before being passed to the template processor.
If this is set to a value then when a nag message needs to be sent out it will be mailed to the address in the resource as well as being sent to any users on the console.
If the mailto option is set then this is the mailer that will be used when sending nag messages. See Mail::Mailer for details of which mailers are supported. The default mailer is sendmail.
The 'at' command is used to initiate the final shutdown sequence. This defaults to /usr/bin/at, which is the location on Redhat-based systems. The time at which the final shutdown sequence is initiated is configured in the shutdown_time resource. Prior to the start of the final shutdown sequence the command passed to at for scheduling will not actually call the shutdown command if the request for a reboot has been cleared (e.g. the user has done the reboot themselves, or the component has been restarted).
This is the time at which the at command will initiate the final shutdown sequence by calling the shutdown command. It can be any string that the at command recognises, see the at man page for full details. The default value is now + 2 hours.
The 'shutdown' command is used for the final shutdown sequence. This defaults to /sbin/shutdown, which is the location on Redhat-based systems. The message sent to the user upon starting the shutdown (and at regular intervals thereafter) is configured in the shutdown_message resource. The time argument is configured in the shutdown_delay resource.
Please note that once the final shutdown sequence has begun the ONLY way to stop it is, as the root user, via the shutdown command "cancel" option.
This is the message which will be passed to the shutdown command when the final shutdown sequence is started. It should be a simple text string, no template processing will be carried out. This resource defaults to Automatic reboot now in progress.
This is the time, in seconds, that the shutdown command will wait before shutting down the machine. During this period it is not possible for a user to cancel the shutdown procedure (see shutdown_command for further details). The default value is 3600 seconds
The file containing the nagging message if a reboot is required . The message comes from the message resource and is passed through a Perl Template Toolkit processor to allow substitution of values for any resources in this component. You should never need to alter this file path, the resource is provided mainly so it can be inserted into resources in other components, such as gdm.infomsgfile. This resource defaults to /var/lcfg/conf/autoreboot/nagfile
The 'wall' command is used to warn users that are logged into the system that a reboot is required. It defaults to /usr/bin/wall, which is the location on Redhat-based systems. The message sent is configured in the message resource.
This is the path to a state file which is used when the component is in enforcing mode to keep track of how many warnings have been issued. You should never need to alter this file path. This resource defaults to /var/lcfg/conf/autoreboot/count
This resource is only used internally and setting it will have no effect. It is used to track the number of nag messages which have been sent out and the current value is available to the templated message resource, e.g.
Remaining nags: [% leeway.VALUE - count.VALUE %]at(1), crontab(5), shutdown(8), wall(1), Perl Template Toolkit - Template(3), Mail::Mailer(3)
Fedora13, ScientificLinux5, ScientificLinux6
Stephen Quinney <squinney@inf.ed.ac.uk>