Auto running two commands at boot

edit

/etc/rc.d/rc.local is the place for the commands but you have to ensure the rc-local service is enabled and running.

If you have a /etc/rc.d/rc.local before you upgrade to F18, fedup will enable the service. If you do not have one, getting F18 to start the service can be done as root:

# systemctl start rc-local
# systemctl status rc-local
rc-local.service - /etc/rc.d/rc.local Compatibility
          Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
          Active: active (exited) since Fri 2013-01-25 13:33:28 GMT; 9min ago

Jan 25 13:33:27 peters.localdomain systemd[1]: Starting /etc/rc.d/rc.local C....
Jan 25 13:33:28 peters.localdomain systemd[1]: Started /etc/rc.d/rc.local Co....
Jan 25 13:42:35 peters.localdomain systemd[1]: Started /etc/rc.d/rc.local Co....
#

Here is a "hello world" /etc/rc.d/rc.local:

#!/bin/sh
set &>> /home/ioncube/debug
exit 0

It shows the environment in which the script runs. (You might need full path names on the commands your final versions of /etc/rc.d/rc.local calls.)

Postscript @randomuser: I thought enable was needed too but it gave an error:

# systemctl enable rc-local.service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
#

BTW: system-config-services would not start the service. This might be because it reacted wrongly to the error message when I tried to enable the service.

Postscript @kynde: I don't think the link makes any difference. I have two f18s, one with the link and one without; they both run my rc.local.