Learn › RHCSA (EX200) › Operate Running Systems
rsyslogd - a hands-on Linux lab on a real virtual machine.
Route system logs with rsyslog. The three files that matter (/var/log/messages, /var/log/secure, /var/log/cron), the facility.priority selector, adding a custom rule as a drop-in under /etc/rsyslog.d, restarting the service, and testing with logger -p. Serves EX200 operating-systems task 17: send a facility.priority to a custom log file.
A service on your machine is misbehaving, and its author was kind enough to log a warning every time it stumbles. You go looking for that warning. It is not in /var/log/messages, it is not in the journal you can browse, it is nowhere you know to look. The message was emitted. It just never landed in a file, because nothing was ever told to catch it and write it down.
That catch-and-write job belongs to rsyslog, the daemon that turns a flood of log messages into the plain-text files under /var/log. This lesson is EX200 operating-systems task 17: add a rule that steers one category of messages, a facility at a chosen priority, into a log file you name. By the end you will drop that rule in place, restart rsyslog, and prove it works with a test message you send yourself.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs shown are from a real RHEL 10 machine (AlmaLinux 10.2). The exact log lines on your machine will differ, and log entries carry live timestamps, so where a drill sends a message and reads it back, you are graded on the command you type, not on a fixed output line.
rsyslog is the traditional system logging daemon. Services and the kernel hand it messages, and it sorts each one into a file under /var/log according to rules you can read and edit. The running program is rsyslogd; the service that starts it is rsyslog.
RHEL runs it alongside the journal you met last lesson. journald keeps everything in one binary journal you query with journalctl. rsyslog writes plain-text files you can open with cat, grep, and tail. Two systems, same messages, different homes. The exam wants you fluent in both, and this half is about the files.
Most of what you hunt for on the exam lives in three files. Learn which message goes where, because searching the wrong file wastes minutes you do not have.
Prove they are really there. Ask ls for exactly those three paths and let it confirm each one exists. Run it:
ls /var/log/cron /var/log/messages /var/log/secure
prompt: student@servera:~$ answer: ls /var/log/cron /var/log/messages /var/log/secure output: /var/log/cron /var/log/messages /var/log/secure hint: Hand ls the three full paths, space-separated, and it prints back the ones that exist: ls /var/log/cron /var/log/messages /var/log/secure
cron, messages, secure. All three are present, exactly the files the exam expects you to reach for. When an SSH login fails, the record is in secure. When a service crashes, it is in messages. When a scheduled job fires, it is in cron. Knowing the file before you type grep is half the speed on exam day.
You often need sudo to READ these files, because they are owned by root: sudo tail /var/log/secure. Listing the directory works as any user, which is why the drill above needs no sudo. On your machine the files hold different lines, but the names and their jobs are the same everywhere.
Every rsyslog rule is two halves: a selector that matches messages, then an action that says where to put them. The selector is written facility.priority, and the usual action is the path to a file.
The facility names the source of the message. The priority names how severe it is. Here are the ones you will meet:
The priorities run from least to most severe: debug, info, notice, warning, err, crit, alert, emerg. Naming a priority in a rule means that level and every level more severe. So local0.info catches info and everything above it. A * means all: authpriv.* is every priority from the authpriv facility, which is exactly the stock rule that fills /var/log/secure.
The local0 through local7 facilities exist for one reason: they belong to nobody, so they are the safe choice when the exam asks you to route your OWN application's messages. Reach for local0 and route it wherever the task names.
You could edit the main file /etc/rsyslog.conf, but there is a cleaner, exam-safe way. rsyslog reads every .conf file in a drop-in directory and merges them with the main config. You add a rule by dropping a small new file in that directory, leaving the shipped config untouched.
Confirm the drop-in directory is there:
ls -d /etc/rsyslog.d
prompt: student@servera:~$ answer: ls -d /etc/rsyslog.d output: /etc/rsyslog.d hint: List just the directory itself with the -d flag so ls prints the path, not its contents: ls -d /etc/rsyslog.d
/etc/rsyslog.d. That is home for custom rules. A file you create here, say /etc/rsyslog.d/myapp.conf, holding a single line like local0.* /var/log/myapp.log, is picked up the next time rsyslog reads its config. You never touch the main /etc/rsyslog.conf, which is the tidy habit the exam rewards.
Dropping the file in place is not enough. rsyslog read its config once at startup, so it will not see your new rule until you tell it to reload. The reliable way is to restart the service with systemctl.
The command that rereads the config and starts routing by your new rule:
sudo systemctl restart rsyslog
prompt: student@servera:~$ answer: sudo systemctl restart rsyslog output: hint: Use systemctl to restart the service by name, with sudo because it is a system service: sudo systemctl restart rsyslog
A clean restart prints nothing and returns you to the prompt, which is systemctl telling you it succeeded. rsyslog has now reread /etc/rsyslog.conf and every file in /etc/rsyslog.d, so your drop-in rule is live. If a restart ever fails, systemctl status rsyslog shows why, usually a typo in the selector. Silence here means the rule is armed and waiting for its first matching message.
You need a way to fire a test message on demand rather than waiting for a real event. That tool is logger. Plain logger "text" sends the text into rsyslog as a normal message, and it lands in /var/log/messages.
To aim a message at a specific rule, add -p facility.priority. So logger -p local0.info "..." sends the message as facility local0 at priority info, which is exactly what a local0.* rule catches. Send one now:
logger -p local0.info "rhcsa test message"
prompt: student@servera:~$ answer: logger -p local0.info "rhcsa test message" output: hint: Call logger with -p and a facility.priority selector, then the quoted text: logger -p local0.info "rhcsa test message"
logger prints nothing and hands the message to rsyslog, which matches it against your rules and writes it to the file your rule named. To read it back you tail that file, for example sudo tail /var/log/myapp.log, and there sits your line. One honest wrinkle worth knowing: every log line is stamped with the live date and time it arrived, so the exact text you see back varies by the second. That is why this drill grades the logger command you send, not a fixed line: the shape is the skill, the timestamp is just the clock.
This is the whole loop of task 17 in four moves: write the rule into a file under /etc/rsyslog.d, restart rsyslog, send a matching message with logger -p, then tail the target file to confirm it arrived. Practice the loop and you can route any facility to any file the exam asks for.
Scaffolding off. No command is printed this time. You have every piece you need.
A task wants you to generate one test message that behaves like an authentication event, so you can confirm your logging is catching auth traffic. Send a message tagged with the authentication facility, authpriv, at priority warning, carrying the text auth test. Think about which flag on logger sets the facility and priority, and how the selector is written.
prompt: student@servera:~$ answer: logger -p authpriv.warning "auth test" output: hint: Same logger shape as before, but change the selector to the auth facility at warning: logger -p authpriv.warning, then the quoted text.
logger -p authpriv.warning "auth test". The -p flag set the selector, authpriv picked the authentication facility, and warning set the priority. Because stock RHEL routes authpriv.* to /var/log/secure, this message lands there next to the real login and sudo records, and sudo tail /var/log/secure would show it. You just steered a message to a named file by choosing its facility and priority, which is task 17 stripped to its core.
You earned this cheat sheet. Every row is a file or command you just used:
The one workflow to burn in for the exam: write the rule under /etc/rsyslog.d, restart rsyslog, send a logger -p message, and tail the target file to confirm. Selector chooses, action places, restart arms, logger proves.
A priority in a rule means that level and everything more severe. So local0.warning catches warning, err, crit, alert, and emerg, but not info or debug. If a task asks for one exact priority and nothing above it, that is a different selector form, but for EX200 the plain facility.priority rule is what task 17 expects.
The practice terminal has shown you the shape of system logging: the three files that matter, messages, secure, and cron; the facility.priority selector; the /etc/rsyslog.d drop-in directory where a custom rule lives; the systemctl restart rsyslog that arms it; and logger -p to fire a test message and prove the route. Every one of those you typed yourself.
The operating-systems module mission is where you run this against a real RHEL 10 machine. A full VM boots for you, with its own live logs. The mission hands you objectives that use exactly what you practiced here: add a rule that sends a facility.priority to a custom log file, restart the daemon, and test it with logger. One difference from this lesson: the mission shows no commands. You read the objective, recall the drop-in file and the restart, and type it. That recall is what makes it stick on exam day.
Finish the other operating-systems lessons, then go make a real machine log exactly where you tell it.
Practice rsyslog and /var/log in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.