Understanding the Key Differences Between service and systemctl Commands in Linux Service Management


3 views

In traditional SysVinit systems, the service command was the primary interface for managing services. This legacy command still exists on modern systems for backward compatibility, but it's essentially a wrapper that calls the appropriate native command - either systemctl for systemd systems or the original init scripts.

Modern Linux distributions (RHEL 7+, Ubuntu 16.04+, Debian 8+) have adopted systemd as their default init system, making systemctl the native and recommended command for service management.

The fundamental differences between these commands include:

# Service (legacy)
service nginx status
# Equivalent to:
/etc/init.d/nginx status

# Systemctl (modern)
systemctl status nginx
  • Dependency Management: systemctl understands service dependencies while service does not
  • Configuration: systemd uses unit files (*.service) instead of init scripts
  • Features: systemctl offers more advanced features like socket activation, timers, and cgroups integration

Here's how common operations differ between the two approaches:

# Starting a service
service nginx start
systemctl start nginx

# Enabling at boot
chkconfig nginx on
systemctl enable nginx

# Viewing logs
tail -f /var/log/nginx/error.log
journalctl -u nginx -f

When converting from legacy init scripts to systemd unit files:

[Unit]
Description=Example Service
After=network.target

[Service]
ExecStart=/usr/sbin/nginx
Restart=always

[Install]
WantedBy=multi-user.target

Save this as /etc/systemd/system/example.service, then:

systemctl daemon-reload
systemctl enable example.service

For modern systems:

  • Always prefer systemctl for new deployments
  • Use journalctl for centralized logging
  • Leverage systemd's advanced features like socket activation
  • Convert legacy init scripts to native unit files when possible

For backward compatibility:

  • The service command will continue working on systemd systems
  • Init scripts in /etc/init.d/ are still processed by systemd
  • Some distributions provide automatic translation between the two

In the Linux ecosystem, both service and systemctl are commands used for managing system services, but they represent different generations of init systems:

  • service is part of the legacy System V init system
  • systemctl belongs to the modern systemd init system

Here's a detailed comparison of their operation:

Feature service systemctl
Init System System V systemd
Configuration Files /etc/init.d/ scripts Unit files (.service)
Dependency Management Basic Advanced
Logging Separate log files Journald integration

Common operations comparison:

# Starting a service
service nginx start
systemctl start nginx

# Checking status
service nginx status
systemctl status nginx

# Enabling at boot
chkconfig nginx on
systemctl enable nginx

For new systems, always prefer systemctl:

# Example service unit file (/etc/systemd/system/myapp.service)
[Unit]
Description=My Custom Application
After=network.target

[Service]
ExecStart=/usr/bin/myapp
User=appuser
Group=appgroup
Restart=always

[Install]
WantedBy=multi-user.target

When moving from System V to systemd:

  1. Convert init scripts to unit files
  2. Update monitoring scripts
  3. Adjust log parsing for journald

For mixed environments:

# Check what init system is running:
ps -p 1 -o comm=

# View service mapping:
ls -l /etc/init.d/ | grep -v '^total'

systemd offers significant advantages:

  • Parallel service startup
  • Better resource management
  • More detailed status reporting