How do you ensure that a web server stays online when a user visits your site, or that a database restarts after a crash without you having to type commands every minute? Service management and system administration solve this problem by giving you a set of tools to control, monitor, and maintain the software services that run on a Linux server, as well as manage who can access them. For the EX294 exam, you need to master how to start, stop, and enable services, create and manage users and groups, and schedule routine tasks, because these are the fundamental skills a Red Hat Certified Engineer uses every day.
Jump to a section
A simple way to picture Service Management and System Administration
When you move into a new office building, the facilities manager ensures the heating, electricity, and water are all running before you arrive. This setup leads to a building where you can work productively without worrying about the infrastructure.
In the same way, a system administrator manages the services that run on a server, like a web server or a database, so that applications can work reliably.
Now, imagine you are the building manager. You have a list of all the appliances (the services) in the building. A boiler runs the heating, a water pump runs the plumbing, and an elevator moves people between floors. If the boiler breaks, you need to check its status, decide whether to restart it or call for a repair, and schedule maintenance so it doesn't fail again. You also have keys for each room (user access) and a log book for who entered when (audit logs). Just as you wouldn't let anyone wander into the electrical room, you control which users can stop or start the boiler. You also group users into teams: the cleaning crew can enter every office, but the IT team can only access the server room.
This is exactly what service management means on a Linux system. You check the status of services (like sshd or httpd), start and stop them, enable them to start at boot, and control who has permission to perform those actions. You also manage user accounts and groups to ensure the right people have the right access, and you schedule regular tasks (like backups) using system tools.
Service management is the art of controlling the programs that run in the background on a Linux system. These programs are called services or daemons. A daemon is a process that runs continuously, waiting for something to happen, like a web server (httpd) waiting for a browser request, or a SSH server (sshd) waiting for a remote login. Before modern service managers, system administrators had to manage services by hand, running scripts manually, which was error-prone and time-consuming.
Today, Red Hat Enterprise Linux (RHEL) uses a system called systemd to manage services. Systemd is the init system — the very first process that runs when the computer boots, with PID 1. Its job is to start, stop, and monitor all services. You interact with systemd using the systemctl command. This is your main tool for service management.
Here are the core actions you will use with systemctl:
systemctl start [service-name]: This runs the service's start script, making the service active immediately. For example, systemctl start httpd makes the web server start serving pages right away.
systemctl stop [service-name]: This sends a signal to the service telling it to shut down gracefully.
systemctl restart [service-name]: This stops and then starts the service, which is useful after changing a configuration file.
systemctl reload [service-name]: This tells the service to re-read its configuration without stopping entirely, avoiding downtime.
systemctl status [service-name]: This shows whether the service is running (active), stopped (inactive), or has failed. It also shows recent log entries, which helps in troubleshooting.
systemctl enable [service-name]: This configures the service to start automatically when the system boots. Without enable, the service will only start when you manually tell it to.
systemctl disable [service-name]: This prevents the service from starting at boot.
systemctl is-enabled [service-name]: This checks the current start-up state.
systemctl is-active [service-name]: This checks if the service is currently running.
Now, why does this matter for system administration? In a business environment, you do not want to manually log in and start the web server after every reboot. An unplanned power outage could take your company's website down until you notice and restart it. By enabling the httpd service, you ensure it starts automatically every time the server boots, so your website is always available.
Alongside services, you need to manage users and groups. A user is an individual account that can log into the system. Each user has a unique user ID (UID) and a home directory. A group is a collection of users that share permissions for files or commands. For example, you might have a group called developers that can access a shared folder, while a group called admins has sudo privileges. The key commands here are:
useradd [username]: Creates a new user.
usermod [options] [username]: Modifies an existing user, like changing their group membership.
userdel [username]: Deletes a user.
groupadd [groupname]: Creates a new group.
groupmod [options] [groupname]: Modifies a group.
groupdel [groupname]: Deletes a group.
passwd [username]: Sets or changes the user's password.
id [username]: Shows the user's UID and group memberships.
System administration also involves scheduling tasks. On RHEL, you use cron and systemd timers to run commands at specific times. The cron command reads a crontab file, where you list what to run and when. For instance, you might schedule a backup script to run every night at 2 AM. The crontab format has five time fields: minute, hour, day of month, month, day of week, followed by the command. A cron job of * 2 * * * /backup-script.sh would run at 2:00 AM daily.
In summary, service management gives you control over background processes, user management controls who can do what, and task scheduling automates repetitive jobs. Together, they form the bedrock of a stable, secure, and efficient Linux system. For the EX294 exam, you must know the exact syntax for systemctl commands, the differences between enable and start, and how to create and modify users and groups.
Check the status of a service
Run systemctl status [service-name]. This shows if the service is active, inactive, or failed, along with recent log entries. It is the first step in troubleshooting because it gives you a clear picture of whether the service is running, stopped, or broken.
Start or stop a service immediately
Use systemctl start [service-name] to activate the service right now, or systemctl stop [service-name] to deactivate it. This is for immediate changes — it does not affect whether the service starts on boot.
Enable or disable a service at boot
Run systemctl enable [service-name] to create a symlink that makes the service start automatically during system boot. Use systemctl disable to remove that symlink. This step ensures the service behaves predictably after a reboot.
Create a user and set a password
First run useradd [username] to create the account. Then run passwd [username] and enter the password twice. Without the second command, the user cannot log in. Always verify with id [username] to check the UID and groups.
Create a group and add a user to it
Run groupadd [groupname] to create the group. Then run usermod -aG [groupname] [username] to add the user. The -a (append) flag is critical — without it, you will replace all existing group memberships. Verify with groups [username].
Schedule a task using cron
Edit your crontab with crontab -e. Add a line in the format: minute hour day-of-month month day-of-week /full/path/to/command. For example, 0 2 * * 1 /usr/local/bin/weekly-report.sh runs every Monday at 2:00 AM. Save and exit — cron will automatically load the new schedule.
Imagine you work as a junior system administrator for a small e-commerce company that sells customised T-shirts. The company runs a web server (httpd) on a RHEL server, a database server (mariadb) for product inventory, and a print server for shipping labels. The company has three departments: Web Development (webdev), Warehouse (warehouse), and Customer Service (cs). Each team needs different access to the servers.
One Monday morning, you receive a call from the customer service manager. He says the website is down. Your first step is to check the web server service. You SSH into the server and run: systemctl status httpd. The output shows the service as 'inactive (dead)' — it has stopped. You read the recent logs using journalctl -u httpd (which shows logs for that specific service) and see a segmentation fault error. The service crashed. To get the site back online immediately, you run: systemctl start httpd. The website starts working again.
But you cannot leave it there. A crash that requires manual restart is a bad sign. You need to investigate the root cause. You check the web server configuration files in /etc/httpd/conf/ and find a syntax error in the virtual host configuration. You use apachectl configtest to check for errors, then fix the file. After fixing, you run: systemctl restart httpd to apply the changes cleanly. You also check if the service is enabled to start at boot: systemctl is-enabled httpd. If it is not enabled, you run: systemctl enable httpd. This ensures that if the server itself reboots, the web server comes back up automatically.
Next, you need to manage user access. The Web Development team needs to edit the web server configuration files, but the Warehouse team should only be able to access the print server. You create groups:
groupadd webdev
groupadd warehouse
groupadd cs
Then you create users for each employee, adding them to the appropriate group:
useradd -G webdev alice
useradd -G warehouse bob
useradd -G cs carol
You then set permissions on the /var/www/html directory (the web root) so that only the webdev group can write to it: chown root:webdev /var/www/html and chmod 775 /var/www/html. The Warehouse team's user cannot modify the web files.
Finally, you set up a cron job to run a nightly backup of the database. You edit the crontab for root (crontab -e) and add the line: 0 2 * * * /usr/local/bin/backup-mariadb.sh. This script will run at 2:00 AM every day, backing up the inventory data to an external drive.
This scenario shows the daily reality of an IT professional: you troubleshoot and restart services, configure users and groups to enforce security, and automate maintenance tasks to prevent future problems. In a real company, you would also use monitoring tools (like Nagios or Prometheus) to alert you when services go down, but the core service management commands are the same.
The EX294 exam (Red Hat Certified Engineer) tests your ability to manage services, users, groups, and system administration tasks through hands-on, performance-based tasks. You will not get multiple-choice questions — you must actually perform the tasks on a live RHEL system. The exam expects you to be efficient and precise with commands.
Exam objectives include:
Starting, stopping, and restarting services using systemctl. You need to know the exact command syntax. A common trap: the exam might ask you to 'stop' a service but then check if it remains disabled after reboot. If you only stop it but do not disable it, it will start again on next boot. Conversely, if you disable a service that is running, it stays running until you explicitly stop it.
Enabling and disabling services at boot. The exam often asks you to configure a service to start automatically. You must use systemctl enable, not just systemctl start.
Checking service status and interpreting the output. The exam may present a scenario where a service is listed as 'active (exited)'. This means the service ran and finished successfully but is not a long-running daemon. You need to recognise this is normal for one-shot services (like a log cleaner script).
Creating and managing user accounts. You will be asked to create a user with a specific UID, a comment field (using -c), and a specific home directory. For example: useradd -u 2001 -c 'John Doe' -d /home/jdoe jdoe. A frequent trap: forgetting to set the password with passwd after creating the user. Without a password, the user cannot log in.
Managing groups. The exam tests creating groups and adding users to secondary groups using the -G flag with useradd or usermod. A common mistake: using -g (primary group) instead of -G (supplementary group). The primary group is created automatically with the same name as the user; you usually want to add users to additional groups.
Modifying existing users and groups. The usermod and groupmod commands are tested. For example, usermod -aG wheel jdoe adds the user to the wheel group for sudo access. The -a (append) flag is crucial — without it, you would replace all existing group memberships.
Deleting users and groups. The exam might ask you to delete a user while preserving their home directory (userdel) or removing the home directory as well (userdel -r).
Scheduling tasks with cron. You need to write a crontab entry with the correct five-field format. The exam often asks you to schedule a script to run at a specific time, like every Tuesday at 3 AM. The correct entry would be: 0 3 * * 2 /path/to/script. A common trap: forgetting that cron does not use the same time format as systemd timers, or confusing day of week (0 and 7 both represent Sunday) fields.
Key definitions to memorise: - systemd: the init system and service manager. - unit: a resource that systemd knows how to manage. Services, sockets, timers are all units. - service unit: a file with a .service extension that defines a daemon. - daemon: a background process. - enable: creates a symlink in /etc/systemd/system/multi-user.target.wants/ to start the unit at boot. - disable: removes that symlink. - mask: prevents a service from being started manually or automatically (by linking it to /dev/null).
The exam also tests your understanding of the difference between start and enable, and between stop and disable. A question might ask: 'Ensure that the bluetooth service does not run at any time.' The correct answer would be systemctl mask bluetooth, not just disable or stop.
Use systemctl start, stop, restart, and status to manage services in the current session.
Use systemctl enable to make a service start automatically at boot; use disable to prevent it.
Use systemctl mask to completely prevent a service from being started by any command.
The useradd command creates an account but does not set a password; always run passwd afterwards.
The usermod -aG command adds a user to a supplementary group without removing existing group memberships.
Cron job entries use a five-field time format: minute, hour, day of month, month, day of week.
The journalctl -u command shows logs for a specific systemd service unit.
Always verify service status after a change using systemctl status or systemctl is-active.
These come up on the exam all the time. Here's how to tell them apart.
systemctl start
Affects the current session only
Runs the service immediately
Does not change boot behaviour
systemctl enable
Affects future boots only
Creates a symlink for automatic start
Does not start the service right now
useradd
Creates a new user account
Requires only a username
Automatically creates a home directory and primary group
usermod
Modifies an existing user account
Changes properties like group membership
Does not create a home directory
Primary group
Created automatically for each user
Named the same as the user
Files created by user inherit this group
Supplementary group
Added manually by administrator
Can have any name
Grants additional permissions beyond the primary group
cron
Uses a five-field time format
Relies on crontab files
Simpler syntax for basic scheduling
systemd timers
Uses calendar event syntax
Relies on timer unit files
More complex but offers finer control and logging
Mistake
If I stop a service with systemctl stop, it will not start again after a reboot.
Correct
Stopping a service only affects the current session. To prevent it from starting at boot, you must use systemctl disable. To prevent both manual and automatic starts, use systemctl mask.
Beginners often confuse the immediate effect of stopping with the persistent behaviour of disabling, because in daily language 'stopping' something implies it stays stopped.
Mistake
Creating a user with useradd automatically sets a password for them.
Correct
The useradd command creates the account but does not set a password. You must run passwd username separately to assign a password. Without this, the account is locked.
Many people assume account creation includes credential setup, because other systems (like Windows) often prompt for a password during creation.
Mistake
systemctl restart and systemctl reload do the same thing.
Correct
systemctl restart stops and starts the service completely, causing a brief outage. systemctl reload tells the service to re-read its configuration without stopping, resulting in no downtime. Not all services support reload.
The terms 'restart' and 'reload' sound similar, and in casual conversation people use them interchangeably, but in systemd they have distinct technical meanings.
Mistake
If I delete a user with userdel, their home directory and mail spool are automatically removed.
Correct
By default, userdel removes the user account but leaves the home directory and mail spool intact. To remove them, you must use userdel -r.
This misconception stems from a desire for 'cleanup' — beginners expect the system to remove everything related to the user. However, RHEL is conservative to prevent accidental data loss.
Mistake
All services are daemons that run continuously.
Correct
Some services are one-shot or transient — they run once and exit. For example, a systemd unit that runs a clean-up script and then exits is a valid service. The status 'active (exited)' is normal for these.
The word 'service' evokes the idea of a continuous waiter at a restaurant, so beginners expect every service to be always running in the background.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
systemctl start starts a service right now. systemctl enable configures it to start automatically at boot. You often need both: start to run it now, and enable to keep it running after a reboot.
Use journalctl -u [service-name]. For example, journalctl -u httpd shows all log entries related to the Apache web server. Add -f to follow new log entries in real time (like tail -f).
It means the service ran and completed its task successfully, but it is not a continuously running daemon. This is normal for one-shot services like a cleanup script or a one-time configuration tool.
Use systemctl mask [service-name]. This links the service unit file to /dev/null, making it impossible to start, even manually. To undo it, use systemctl unmask.
Every user has a primary group (default, same name as the user) and zero or more supplementary groups. Files created by the user inherit the primary group. Supplementary groups grant additional permissions, like access to shared directories.
Use userdel -r [username]. The -r flag removes the user's home directory, mail spool, and any other files owned by the user. Without -r, the home directory remains on the system.
You've finished Service Management and System Administration. Continue through the EX294 study guide to build a complete picture of the exam.
Done with this chapter?