Yes they are persistent across reboots (they're just files in a spool).
Regarding having access to them, as a regular user you won't have access to the files, but you could build a system to back them up. Maybe something like this:
MYAT=~/atjobs
/bin/rm -rf $MYAT/*
at -l >$MYAT/JOBS
for j in `cat $MYAT/JOBS | cut -f1`
do
at -c $j >$MYAT/$i
done
If you needed to reload the job later:
for j in `cat $MYAT/JOBS | cut -f1`
do
# make sure the job isn't defined
atrm $j
# reload it from the file
at -f $MYAT/$j `grep ^$j $MYAT/JOBS | awk '{ print $3, $2 }'`
done
(this is all mostly untested. The basic command are right but there's sure to be a bug in the logic in there somewhere)
Having said all that though, I'm not sure I'd use at for the task you describe. I'd probably use a preexisting calendaring system. Failing that though, I would user a cron job that ran daily that checked a file to see if there were any messages to send. Much more portable than at jobs, and much more likely to be remembered if you switch machines...
In RHEL, there's two places where these things should probably go.
For adding static routes in RHEL, you add them to /etc/sysconfig/network-scripts/route-INTERFACE where INTERFACE matches the name of the ifcfg-INTERFACE entries. The statements in the route-* files will be passed to ip route add
and ip route del
when the interface is brought up or down.
Now, for the ip rule
commands, the best place I can think of would probably be in /sbin/ifup-local
. If this file exists, it gets run after an interface is brought up. One note with this one, if /sbin/ifup-local
exists, it will get called as an executable and passed an argument of the interface name. So you'll have to write handler code to check that argument against the interfaces you want to add configs for and then take the appropriate action.
As an example:
#/bin/bash
case $1 in
eth0)
/sbin/ip rule foo
/sbin/ip rule bar
;;
eth1)
/sbin/ip rule baz
/sbin/ip rule quux
;;
*)
/usr/bin/logger -t 'ifup-local' 'Called with unknown interface: $1'
;;
esac
If you wanted to, you could include the ip route rules for each interface in ifup-local
, too. If you wanted to remove the corresponding rules when an interface is downed, you could create a similar /sbin/ifdown-local
script to handle that.
If it were me, even though RHEL provides a standardized way of handling static routes, I'd probably do everything in ifup-local
and ifdown-local
, just to keep all my interface specific bits together.
Best Answer
If it were me, I'd probably create an
/etc/sysfs.conf
, and an/etc/init.d/sysfsutils
init script. Then I could keep all of my sysfs related configs and options separate from everything else. With an init script, it could be managed and handled using the standard idioms for managing services and configurations through SysV init scripts (includingservice sysfsutils [start|stop|reload|restart|status]
on RHEL/CentOS (with a little extra work)).Even if I didn't bother with the
/etc/init.d/sysfsutils
script, I'd still put the options into/etc/sysfs.conf
and then call/process the contents of that file from a separate script (/etc/rc.local
, as a last/lazy option).Note: Debian and Debian-based distributions (Ubuntu, etc.) already do this, and ship an
/etc/sysfs.conf
config file and init script with their sysfsutils package. Grabbing those two files from a Debian/Ubuntu box (or the Debian source package for sysfsutils) would probably be a good way to start for replicating it yourself.