If there is a startup item that you need to add to the boot process, you can make use of the fact that system5 subsystems still work in RH7 - they are just not recommended. You can thus use the same technique as in RH6.5.

The better way to proceed is to create a systemd service unit to perform your task. How you proceed is dependent on the type of your startup item. Your unit file should be placed in /etc/systemd/system rather than /usr/lib/systemd/system. The /etc location is where local units go.

• if it is a standard daemon process, simply create a systemd unit that starts your daemon using ExecStart. The Type should be forking - that is how a daemon works. You will have to add whatever dependencies you need to other units. In this case you must tell systemd how to determine the process PID. You have two choices: if the daemon creates a PID file, use the PIDFile= option to tell systemd where it is. Otherwise systemd will try to guess the PID of the main process.

• if it is a unit that starts a program that continues to run, but does not fork itself, set the Type to simple.

• if it is a unit that simply executes some code then exits, set the Type to either simple (if it can be run in parallel with other units) or oneshot (if the code should be run sequentially at some point in the startup sequence. In this case you probably need to specify where in the boot sequence the commands should be run using Before= or After=). For all units that execute some code, you probably want to set RemainAfterExit to yes. This will mark your unit as active even after it exits, keeping it from being started a second time.

• If your unit uses dbus, sockets or notify, you have other configuration to do that is beyond our discussion here.

You will have to configure your unit's dependencies and, probably, link it to start automatically. The most common link is to be started when the system goes to multi-user mode, which requires a WantedBy=multi-user.target line in the Install section. (Unlike system5 init, systemd goes through multi-user mode to get to graphical mode, i.e.,  graphical.target has a Requires and a Before dependency on multi-user.target.) The Before= and After= dependencies require the most customization. Find a service unit that is similar and examine its dependencies. If you just want the service to be started by hand, no WantedBy dependency should be added.

Once you have the service unit file, you should do a test start and stop to make sure systemd is starting and stopping it correctly. When the service unit seems to work correctly, you must enable it if you want it to be started automatically. (This assumes you have configured a WantedBy dependency to make your unit start with the unit that wants it.)

Example:

Here's a simple script that just generates some simple statistics to a log file:

Notice that this program writes its single message to stdout, which has been redirected (using append) to $LOGFILE. LOGFILE is given a default location.

Here is a service unit that runs our program. The service file is in /etc/systemd/system and is named trackusers.service:

Notice that the service is set to restart every 5 minutes so long as its last execution succeeds. It runs our shell script. It has an environment variable set for somecmds via an Environment= line. This sets the LOGFILE path (avoiding the default assignment in somecmds). We have enabled it using systemctl enable trackusers.service, so that it will be started by multi-user.target.

When we reboot the system, we waited for its log file to have at least two lines so that we could see it is working. Here is the result:

and here is its status