Core System Services
Regardless of distribution, network configuration, and overall system design, every Linux-based system ships with some core services. These services include systemd, init, the logging daemon, cron, and others. The functions performed by these services might seem simple, but they are very fundamental. Without them, a great deal of Linux’s power and utility would be missed.
This chapter will discuss each of the core services and their configuration, in addition to another useful system service called xinetd. You’ll find that the sections covering these simple services are not terribly long, but don’t neglect this material. Take some time to get familiar with these services. Many creative solutions have been realized through the use of these services. Hopefully, this chapter will inspire a few more.
At its core, systemd is a system and startup manager. systemd is the result of an incredibly ambitious project that has reengineered the way services and other bootup procedures have traditionally worked on GNU/Linux systems. In its early days, the project faced some resistance from the Free and Open Source Software (FOSS) community due to the usual growing pains associated with most new major applications. The backlash against systemd was significant because the project is opinionated and changes a lot of the traditional ways that folks are used to managing or administering systems. That was in the past and systemd has since matured and has been adopted by and incorporated into most of the mainstream Linux distributions. It is now the de facto system and service manager! It has effectively replaced traditional tools and subsystems such as init, telinit, inittab, SysV, upstart, and so on. In fact, you will find that most of the traditional system startup subsystems and tools are now actually just symbolic links to the systemd binary and its minions!
The systemd project’s web page (www.freedesktop.org/wiki/Software/systemd) offers the following description:
“systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit.”
The following sections take apart the official description for systemd and try to explain each component.
As is expected of a startup manager, systemd manages various system startup and shutdown functions; it also manages the startup and shutdown of services (daemons) on Linux-based operating systems. systemd goes a little further by also playing the role of a babysitter of sorts to services of which it is aware. This means that systemd can monitor the services throughout their lifetime and automatically restart them, gather statistics about them, or report on them if necessary.
Because for the longest time the traditional way of managing system services has been through the use of startup shell scripts (for example, System V init), systemd provides compatibility and support for some existing System V and Linux Standard Base (LSB) specification init scripts.
The systemd Edge
One of the advantages that systemd brings to service/system management in Linux is its so-called “aggressive parallelization” capabilities. Put simply, this means that systemd can start several system services in parallel or concurrently. It does away with the traditional approach of starting services sequentially based on the numbering of the corresponding run control (rc) script. This parallelization equates to quicker startup times for Linux systems.
systemd also no longer uses traditional shell scripts to store the configuration information for services. The often tedious-to-read shell scripts have been replaced by simpler configuration files.
In addition, systemd records the start and exit time, the PID, and the exit status of every process it spawns and supervises. This is useful for troubleshooting daemons or other services.
How systemd Works
To do its work, systemd uses various Linux concepts and subsystems. Some of these are described next.
Control Groups (cgroups)
cgroups is a kernel-provided facility that allows processes to be arranged hierarchically and labeled individually. systemd places every process that it starts in a control group named after its service, and this allows it to keep track of processes and allows systemd to have greater knowledge and control of a service throughout its life span. For example, systemd can safely end or kill a process as well as any child processes it might have spawned.
The benefits to using systemd come from its proper and inherent understanding of the interdependence among system services—that is, it knows what various system services require from each other. As it turns out, most startup services or daemons actually need only the socket(s) provided by certain services and not the high-level services themselves. Because systemd knows this, it ensures that any needed sockets are made available very early on during system startup. It thus avoids the need to start a service first that provides a service as well as a socket. (If this is still a little confusing, see the sidebar “Human Digestive System vs. systemd” for an analogy.)
TIP The two main types of Linux sockets are the file-system-related AF_UNIX and AF_LOCAL sockets and the networking-related AF_INET sockets.
The AF_UNIX or AF_LOCAL socket family is used for communicating between processes on the same machine efficiently. The AF_INET sockets, on the other hand, provide interprocess communication (IPC) between processes that run on the same machine as well as between processes that run on different machines.
The objects that systemd manages are called units, and they form the building blocks of systemd. These objects can include services or daemons, devices, file system entities such as mount points, and so on. Units are named the same as their configuration files, and the configurations files are normally stored under various directories collectively called the Unit File Load Path. Standard (package or vendor created) unit configuration files are stored under the /usr/lib/systemd/system/ directory. Any new (administrator created) unit files as well as any needed customizations to existing unit files should be copied over to the /etc/systemd/system/ folder for actual use. Transient or ephemeral units created during system runtime are stored under the /run/systemd/system/ directory, which is itself a temporary file system structure.
The following types of units exist:
• Service units These units include traditional system daemons or services. These daemons can be started, stopped, restarted, and reloaded. Here’s an example of a service unit:
• Socket units These units consist of local and network sockets that are used for interprocess communication in a system. They play a very important role in the socket-based activation feature that helps reduce interservice dependencies. Here’s an example:
• Device units These units allow systemd to see and use kernel devices. Here’s an example of a device unit:
• Mount units These units are used for mounting and unmounting file systems. An example of a mount unit is shown here:
• Target units systemd uses targets instead of runlevels. Target units are used for the logical grouping of units. They don’t actually do anything by themselves, but instead reference other units, thereby allowing the control of groups of units together. Here’s an example:
• Timer units These units are used for triggering activation of other units based on timers. Here’s an example:
• Snapshot units These units are used to save the state of the set of systemd units temporarily. Here’s an example:
TIP You can use the
systemctl command to view, list, and manage units of specific types. For example, to view all the active target units, type:
xinetd is an acronym for “extended Internet services daemon,” and it is the more modern incarnation of the older inetd. The xinetd program can be considered a daemon process itself. You probably know that daemons are special programs that, after starting, voluntarily release control of the terminal from which they started. The main mechanism by which daemons can interface with the rest of the system is via IPC channels, by sending messages to the systemwide logging facility or by appending to a file on disk.
Strictly speaking, a Linux system can run effectively without the presence xinetd, but some other daemons rely solely on the functionality it provides. So if a daemon’s author or authors decide that their daemon requires or relies on xinetd (or similar), then you need it—no two ways about it! The xinetd program helps to start other programs that provide Internet services. It’s a simple philosophy: Not all server processes (including those that accept new connections) are called upon so often that they each require an individual program to be running in memory all the time. xinetd can function as a “super-server” to other network-server-related processes, such as Telnet, FTP, TFTP, and so on. One of the main reason for the existence of a super-server is to conserve system resources. So instead of needing to maintain potentially dozens of services loaded in memory waiting to perhaps be used, xinetd listens on their behalf.
Stated another way, rather than having various programs or daemons always automatically start up during system initialization and remain unused until a connection request arrives, xinetd instead stands in the gap for those programs and listens on their normal service ports. As a result, when xinetd hears a service request meant for one of the services it manages, it starts or spins up the appropriate service.
A secondary benefit of xinetd is that it serves as a sort of network programing abstraction layer so that third-party daemon developers don’t have to explicitly code network connectivity functions into their applications. This is possible because xinetd can transparently handle the network logic aspects and pass incoming network streams onto the third-party process as its standard input (
STDIN). Likewise, any of the process’s output (
STDOUT) is also sent back to the host that has connected to the process—over the xinetd abstraction layer.
In comparison, to the older inetd daemon, xinetd uses a new configuration file format and offers a lot of additional features. For this reason, any (really old) application that relies on inetd might require some minor manual configuration adjustments to make to them work seamlessly under xinetd.
As a rule of thumb, low-volume services (such as TFTP) are usually best run through xinetd, whereas higher-volume services (such as web servers) are better run as stand-alone processes that are always in memory, ready to handle requests.
In this section, we cover the newer xinetd daemon.
NOTE Your Linux distribution might not have the xinetd software installed out of the box. The xinetd package can be installed with
yum) on a Fedora distro (or RHEL or CentOS) by running the following:
On Debian-based distros such as Ubuntu, xinetd can be installed using APT via the following:
The /etc/xinetd.conf File
The /etc/xinetd.conf file consists of a series of blocks that take the format
blockname is the name of the block that is being defined,
variable) is the name of an attribute being defined within the context of the block, and
value is the value assigned to the
attribute. Every block can have multiple attributes defined within.
One special block is called
defaults. Whatever attributes are defined within this block section will be inherited by all service configurations—unless explicitly overridden in the service configuration.
An exception to the block format is the
includedir directive, which tells xinetd to read all the files in a directory and consider them part of the /etc/xinetd.conf file. Any line that begins with a pound sign (#) is the start of a comment. The stock /etc/xinetd.conf file that ships with Fedora/CentOS/RHEL looks like this:
The first line of our sample xinetd.conf file is a comment explaining what the file is and what it does.
After the comments, you see the first block:
defaults. The first attribute that is defined in this block is
log_type, which is set to the value of
SYSLOG daemon info. Nine attributes in total are defined in this block, the last one being
umask. Since this block is titled
defaults, the variables that are set within it will apply to all future blocks that are defined. We’ll list the attributes and values and discuss their meaning in detail in the next section.
Finally, the last line of the file specifies that the /etc/xinetd.d directory must be examined for other files that contain more configuration information. This will cause xinetd to read all the files in that directory and parse them as if they were part of the /etc/xinetd.conf file.
Attributes and Their Meanings
Table 9-1 lists some of the attribute/variable names that are supported in the /etc/xinetd.conf file.
Table 9-1 xinetd Configuration File Attributes
Examples: A Simple (echo) Service Entry
Using the echo service (provided by the xinetd package) as an example, let’s take a look at one of the simplest entries possible with xinetd:
As you can see, the entry is self-explanatory. The first line that begins with the pound character (#) indicates that this is a comment field and is thus ignored. The service name is echo, and because of the
socket_type (that is,
stream), we know this is a TCP service. The
wait variable tells us that multiple echo processes can be running concurrently. Finally, the
type attribute with a value of
INTERNAL shows that this is a service provided by xinetd—in other words, it is not provided by any external package or daemon.
With our understanding of this xinetd service entry, let’s try to enable and disable a sample xinetd-based service.
Enabling/Disabling the Echo Service
If you want a secure system, chances are you will run it with only a few services—some people don’t even run xinetd at all! It takes just a few steps to enable or disable a service. For example, to enable a service, you would first enable it in the xinetd configuration file, restart the xinetd service, and finally test things out to make sure you have the behavior you expect. To disable a service, just do the opposite.
NOTE The service we will be exploring is the echo service. This service is internal to xinetd (that is, it is not provided by any external daemon).
Let’s step through enabling the echo service:
1. Use any plain-text editor to edit the file /etc/xinetd.d/echo-stream and change the variable
no, as shown in the following file excerpt:
TIP On an Ubuntu-based system, the configuration file for the echo service is /etc/xinetd.d/echo. The Ubuntu distro goes further to combine the UDP and TCP versions of the echo service in one file. Fedora, on the other hand, sorts the UDP and TCP versions of the echo service into two separate files: /etc/xinetd.d/echo-dgram and /etc/xinetd.d/echo-stream.
2. Save your changes to the file and then exit the editor.
3. Restart the xinetd service. On most Linux distros, you can type the following:
On modern systemd-enabled distros, you can alternatively restart the xinetd service using the
systemctl utility, like this:
4. Telnet to the port (port 7) of the echo service and see if the service is indeed running:
Your output should be similar to the preceding, if the echo service has been enabled.
You can type any character on your keyboard at the Telnet prompt and watch the character get echoed (repeated) back to you. We typed “Hello World” in the example. (As you can see, the echo service is one of those terribly useful and lifesaving services that users and system administrators cannot do without!)
Simultaneously, press CTRL-] on your keyboard to break the connection, and then type
quit to exit Telnet and return back a shell prompt.
This exercise walked you through enabling a service by directly editing its xinetd configuration file. It is a simple process to enable or disable a service. However, you should actually go back and make sure that the service is indeed disabled (if that is what you want) by testing it—because it is always better to be safe than sorry. An example of being sorry is “thinking” that you have disabled the insecure Telnet service when it is in fact still running!
TIP You can quickly enable or disable a service that runs under xinetd by using the
chkconfig utility, which is readily available (or installable) on older GNU/Linux distributions. For example, to disable the echo-stream service that you manually enabled, just issue the following command:
The Logging Daemon
With so much going on at any one time, especially with services that are disconnected from a terminal window, a standard mechanism by which special events and messages can be logged is required. Linux distributions have traditionally used the syslogd (sysklogd) daemon to provide this service. However, modern Linux distros have standardized on the rsyslog package as well as the logging component of systemd, referred to as systemd-journald (journald), for logging-related functions.
Regardless of the software used, the idea remains the same, and the end result (to gather system logs) is mostly the same; the main differences between the new approaches are in the additional feature sets offered. In this section, we will be concentrating on rsyslog. There will be occasional references to syslogd when appropriate. Managing and configuring rsyslog is similar to the way it is done in syslogd. The rsyslog daemon maintains backward compatibility with the traditional syslog daemon but offers a plethora of new features as well.
The rsyslog daemon provides a standardized means of performing logging. Many other platforms’ systems employ a compatible daemon, thus providing a means for cross-platform logging over the network. This is especially valuable in a large heterogeneous environment where it’s necessary to centralize the collection of log entries to gain an accurate picture of what’s going on. You could equate this system of logging facilities to the Event Viewer functionality in Windows.
rsyslogd can send its output to various destinations: straight text files (usually stored in the /var/log directory), Structured Query Language (SQL) databases, other hosts, and more. Each log entry consists of a single line containing the date, time, hostname, process name, PID, and the message from that process. A system-wide function in the standard C library provides an easy mechanism for generating log messages. If you don’t feel like writing code but want to generate entries in the logs, you have the option of using the logger command.
If you do find a need to either start rsyslogd manually or modify the script that starts it up at boot, you’ll need to be aware of rsyslogd’s command-line parameters, shown in Table 9-2.
Table 9-2 rsyslogd Command-Line Parameters
Log Message Classifications
A basic understanding of how log messages are classified in the traditional syslog daemon way is also useful in helping you understand the configuration file format for rsyslogd.
Each message has a facility and a priority. The facility tells you from which subsystem the message originated, and the priority tells you the message’s importance. These two values are separated by a period. Both values have string equivalents, making them easier to remember. The combination of the facility and priority makes up the “selector” part of a rule in the configuration file. Common log facilities and priorities are listed in Tables 9-3 and 9-4, respectively.
Table 9-3 Logging Facilities
Table 9-4 Logging Priority Levels
NOTE The priority levels are in the order of severity according to syslogd. Thus, debug is not considered severe at all, and emerg is the most crucial. For example, the combination facility-and-priority string
mail.crit indicates there is a critical error in the mail subsystem (for example, it has run out of disk space). syslogd considers this message more important than
mail.info, which may simply note the arrival of another message.
In addition to the priority levels in Table 9-4, rsyslogd understands wildcards. Thus, you can define a whole class of messages; for instance,
mail.* refers to all messages related to the mail subsystem.
rsyslogd Configuration File
The /etc/rsyslog.conf file contains the configuration information that rsyslogd needs to run. The default configuration file that ships with most systems is sufficient for most standard needs. But you may find that you have to tweak the file a little if you want to do any additional fancy things with your logs—such as sending local log messages to remote logging machines that can accept them, logging to a database, reformatting logs, indexing the logs into a SIEM engine, and so on.
Format of /etc/rsyslog.conf
rsyslogd’s configuration relies heavily on the concepts of templates. To understand the syntax of rsyslogd’s configuration file, let’s begin by explaining a few key points:
• Templates define the format of log messages. They can also be used for dynamic filename generation. Templates must be defined before they are used in rules. A template is made of several parts: the template directive, a descriptive name, the template text, and possibly other options.
• Any entry in the /etc/rsyslog.conf file that begins with a dollar (
$) sign is a directive.
• Log message properties refer to well-defined fields in any log message. Examples of common message properties are shown in Table 9-5.
Table 9-5 rsyslog’s Message Property Names
• The percentage sign (
%) is used to enclose log message properties.
• Properties can be modified by the use of property replacers.
• Any entry that begins with a pound sign
(#) is a comment and is ignored. Empty lines are also ignored.
As mentioned, rsyslogd relies on the use of templates, and the templates define the format of logged messages. The use of templates is what allows rsyslogd to produce log files that are formatted similarly to the traditional format that is produced by the older syslogd. Templates that support the syslogd log message format are hard-coded into rsyslogd and are used by default.
A sample template directive that supports the use of the traditional syslogd message format is shown here:
The various fields and options of this sample template are explained in the following list. Table 9-5 describes some commonly used message properties.
• template This directive implies that the line is a template definition.
• name This is a unique and descriptive template name. The template name in this example is
RSYSLOG_TraditionalFileFormat, and it refers to a built-in template that mimics the traditional syslog log format. Template names beginning with “RSYSLOG_” are reserved for rsyslog use.
• type This parameter is used to indicate the template type being used. Different types enable different ways to specify the template contents. The string type is used for textual content. Other possible types are list, subtree, and plugin.
• string This is the actual content of the string. It makes use of predefined properties (that is, property replacers) that are enclosed between two percentage (%) symbols. The entire string in the example is made up of the following message properties:
• %TIMESTAMP% This represents when the message was received.
• %HOSTNAME% This specifies the
• %syslogtag% This specifies the
• %msg% This is represents the actual message (MSG) part of the message.
• RANDOM TEXT This can be any random/relevant string or text appended to the message.
• \n The backslash is an escape character. Here, the \n implies a new line.
• <options> This entry is optional. It specifies options influencing the template as a whole. Example options are sql, json, and stdsql.
Rules can be created in rsyslog.conf using different filter criteria. Table 9-6 shows the currently available filter criteria.
Table 9-6 rsyslog Filter Criteria
Let’s delve into the traditional facility- and priority-based filter type rules a little more. This type of filter rule in the rsyslog.conf file is broken down into a selector field (facility.priority), an action field (or target field), and an optional template name. Specifying a template name after the last semicolon will assign the respective action to that template. Whenever a template name is missing, a hard-coded template is used instead. It is, of course, important that you make sure that the desired template is defined before referencing it.
Here is the format for each line in the configuration file:
Here’s an example:
Selector Field The selector field specifies the combination of facilities and priorities. Here’s a sample selector field entry:
info is the priority.
Action Field The action field of a rule describes the action to be performed on a message. This action can be something as simple as writing the logs to a file or slightly more complex, such as writing to a database table or forwarding to another host. Here’s a sample action field:
This action example indicates that the log messages should be written to the file named /var/log/messages.
Other common possible values for the action field are described in Table 9-7.
Table 9-7 Action Field Descriptions
Sample /etc/rsyslog.conf File
Following is an excerpt from a sample rsyslog.conf file that highlights the facility- and priority-based filter type rules. This example is interspersed with comments that explain what the rules do.
systemd-journald is a component of systemd (discussed earlier in this chapter). It runs as a system service that collects and stores logging data. Just like rsyslogd, it has the ability to receive logging data from various sources: user processes, the kernel, and the standard output (
STDOUT) and standard error (
STDERR) of other system services.
journald creates and maintains its logging data differently from the traditional method of using flat files. It natively stores logging data in structured and indexed journals, which lends itself to lots of rich new possibilities and speed improvements.
Most of the mainstream RPM- and Debian-based distributions have integrated systemd-journald for use alongside the more traditional logging daemons such as rsyslogd. It is possible to run both solutions concurrently on a system and even feed data from one solution to the other. Even though this is possible, it is generally considered good system administration practice to standardize on a single logging solution on production systems.
journalctl and journalctl Examples
The primary tool for interacting with the journal files collected and maintained by journald is called
journalctl. It serves as the native utility for querying and viewing the contents of logging data collected by systemd-journald.
We will walk through some quick
journalctl uses in the following exercise.
TIP The output for
journalctl is helpfully colored and bolded when viewed at the terminal. The output lines are colored and bolded according to priorities like this:
Lines of level ERROR (3) and higher (CRIT , ALERT , and EMERG ) are colored red.
Lines of level NOTICE (5) and higher (WARNING , CRIT , ALERT , and EMERG ) are highlighted in color and bold.
Lines of level DEBUG (7) and higher (INFO ) are displayed normally.
journalctl in its simplest form by running it without any options to view the journal logs:
Use your keyboard ARROW keys to scroll through the messages or press Q to quit the utility and stop viewing the log file.
2. Display two of the most recent journal logs by typing the following:
3. Display a much more detailed (or verbose) version of the previous command:
This will show some of the metadata collected by
4. View the log messages in real time as they are being generated and collected:
Press CTRL-C to quit viewing the live output.
5. View log messages since six days ago:
6. View journal messages generated between six days ago and four days ago:
7. It’s the year 2082, and it’s the 25th day of December on planet Walenium, where our server runs, and we want to view log messages only from five days ago:
8. Let’s narrow down the date and time range from the previous commands to show the journal entries that were created between 1 P.M. and 1:30 P.M. on the same date:
9. View all the journal entries created since 2082-12-20 at 1 P.M. with a priority warning or higher:
10. View log messages generated since 2082-12-20 at 7 A.M. that exactly match the CRITICAL (2) priority:
11. The user ID for the user master on our sample system is 1000. View all log messages that are associated with this user with UID=1000:
12. Combine the previous two commands to view messages with critical (6) priority, generated by the user with a UID of 1000 since 2082-12-20 at 7 A.M.:
13. View all system log messages generated by the systemd service unit dbus.service:
14. View log messages emitted by the NetworkManager program on your server:
15. Check to see if there are any messages caused by the /dev/sda or /dev/vda hard disk device installed on your server:
16. Finally, view all the log messages of priority ERROR (3) and higher (that is, worse) from the current boot session of the server:
The cron Program
The cron program allows any user in the system to schedule a program to run on any date, at any time, or on a particular day of the week, down to the minute. Using cron is an extremely efficient way to automate tasks on your system, generate reports on a regular basis, and perform other periodic chores such as backups and e-mail reminders. (A not-so-nice use of cron is to have it invoke a system to have you paged when you want to get out of a meeting!)
Like the other services we’ve discussed in this chapter, cron is automatically started by the boot scripts and is most likely already configured for you. A quick check of the process listing should show it quietly running in the background:
The cron service works by waking up once a minute and checking each user’s crontab file. This file contains the user’s list of events that they want executed at a particular date and time. Any events that match the current date and time are executed.
The crontab File
The tool that allows you to edit entries to be executed by
crontab. Essentially, all it does is verify your permission to modify your
cron settings and then invoke a text editor so you can make your changes. Once you’re done,
crontab places the file in the right location and brings you back to a prompt.
Whether or not you have appropriate permission is determined by
crontab by checking the /etc/cron.allow and /etc/cron.deny files. If either of these files exists, you must be explicitly listed there for your actions to be affected. For example, if the /etc/cron.allow file exists, your username must be listed in that file in order for you to be able to edit your cron entries. On the other hand, if the only file that exists is /etc/cron.deny, unless your username is listed there, you are implicitly allowed to edit your cron settings.
The file listing your cron jobs (often referred to as the crontab file) is formatted as follows (all values must be listed as integers):
If you want to have multiple entries for a particular column (for instance, you want a program to run at 4:00 A.M., 12:00 P.M., and 5:00 P.M.), then you need to include each of these time values in a comma-separated list. Be sure not to type any spaces in the list. For the program running at 4:00 A.M., 12:00 P.M., and 5:00 P.M., the Hour values list would read 4,12,17. Newer versions of cron allow you to use a shorter notation for the fields. For example, if you want to run a process every two minutes, you just need to put /2 as the first entry. Notice that cron uses military time format.
For the Day_Of_Week field, 0 represents Sunday, 1 represents Monday, and so on, all the way up to 6, representing Saturday.
Any entry that has a single asterisk (*) wildcard will match any minute, hour, day, month, or day of the week when used in the corresponding column.
When the dates and times in the file match the current date and time, the command is run as the user who set the
crontab. Any output generated is e-mailed back to the user. Obviously, this can result in a mailbox full of messages, so it is important to be thrifty with your reporting. A good way to keep a handle on volume is to output only error conditions and have any unavoidable output sent to /dev/null.
Let’s look at some examples. The following entry runs the ping program (/bin/ping) with the command-line argument -c 5 server-B every four hours:
Here’s the same command using the shorthand method:
Here is an entry that runs the custom program /usr/local/scripts/backup_level_0 at 10:00 P.M. every Friday night:
And finally, here’s a script to send out an e-mail at 4:01 A.M. on April 1 (whatever day that might be):
crond executes commands, it does so with the sh shell. Thus, some environment variables that you might be accustomed to might not work within cron. This is why you should always test your cron jobs before putting them into production.
Editing the crontab File
Editing or creating a cron job is as easy as editing a regular text file. But you should be aware of the fact that the program will, by default, use an editor specified by the
VISUAL environment variable. On most Linux systems, the default editor is
vi. But you can always change this default to any editor you are comfortable with by setting the
VISUAL environment variable.
Now that you know the format of the crontab configuration file, you need to edit the file. You don’t do this by editing the file directly; instead, you use the
crontab command to edit your crontab file:
To list what is in your current crontab file, just give
-l argument, like so:
According to this output, the user yyang does not currently have anything in cron.
TIP In it’s true Jack-of-all-trades fashion, systemd provides an almost functional replacement to the venerable cron service. This is done via the systemd.timer unit object. This object stores information about a timer construct, which is controlled and managed by systemd.
So, for example, to create an ad-hoc .timer unit job that will execute a sample ping command in 45 seconds, you would type the following:
And to create another sample transient .timer unit job that will start an existing service unit called carpald.service in 11 hours and 24 minutes, you could run this:
View the status of the timer for the carpald.service unit that was created as follows:
In this chapter, we discussed some important system services (init, upstart, systemd, inetd, xinetd, rsyslog, systemd-journald [journald], and cron) that come with most Linux systems. These services contribute to maintaining and monitoring the overall health of servers. They are relevant and useful on a server running in stand-alone mode, single-user mode, multiuser mode, networked mode, and so on. Their implementation can vary slightly from host to host or from distro to distro, but the core objectives and the problem they aim to solve remain the same.
In each section of this chapter, we discussed how to configure some core system services. Try poking around these services and familiarize yourself with what you can accomplish with them. Many powerful automation, data collection, and analysis tools have been built around these basic services—as well as many wonderfully silly and useless things. Have fun with them!