0

When checking status of a service running on Linux (Ubuntu) machine, I am used to the following output:

service status nginx
* nginx is running

After recent nginx upgrade, the output of the same command changed to:

nginx start/running, process XXXX

where XXXX is the process number.

I have never seen such format for service status response and I'd like to know whether that's normal? Is that another standard or maybe it means that the service wasn't installed properly?

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Eugene S
  • 3,484

1 Answers1

3

There is no standard.

Whatever comes out depends from your particular implementation of the service command and what service manager you are using and even what service definitions are supplied for the service in question.

systemd

If you are running systemd as a service manager, the output will be the output of systemd's systemctl status, which is what the (new Debian/Ubuntu-supplied) service command invokes under the covers:

% systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2015-08-12 20:16:25 CEST; 23s ago
  Process: 24221 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
 Main PID: 17425 (code=exited, status=0/SUCCESS)
%

This will be the case on systemd operating systems (that have not been switched to something else), such as Ubuntu 15 and later and Debian 8 and later.

A minor variant is that sometimes there is not a true systemd service unit file, in which case systemd invents one (that wraps a van Smoorenburg rc file), and the Loaded: line will appear slightly differently (because systemd's generator for such units hides the name of the wrapper unit file in favour of the wrapped van Smoorenburg rc file name).

You are clearly using not using a systemd operating system, and the new Debian/Ubuntu service command.

Further reading

nosh

If you are using the nosh toolset, the output will be the output of system-control status, which is what the nosh toolset's service command invokes under the covers:

% service appcafe-nginx status
/var/sv/appcafe-nginx: 
    State   : running since 2019-01-12 17:58:09 +0000; 16h 33m 42s ago
    Main PID: 980
     Started: exit 0 at 2019-01-12 17:58:06 +0000; 16h 33m 45s ago
         Ran: exit 0 at 2019-01-12 17:58:09 +0000; 16h 33m 42s ago
    Config  : enabled
%

Further reading

  • Jonathan de Boyne Pollard (2019). service. nosh Guide. Softwares.
  • Jonathan de Boyne Pollard (2019). system-control. nosh Guide. Softwares.

Upstart

If you are running Upstart as a service manager, the output will be the output of Upstart's initctl status command, which is what the (Debian/Ubuntu-supplied, old) service command invokes under the covers, as you saw:

% initctl status nginx
nginx start/running, process 2543
%

This will be the case on Upstart operating systems, such as Ubuntu 6 to Ubuntu 14 and Fedora 9 to Fedora 14.

A wrinkle is that on Ubuntu if there is no Upstart job definition for the service, the (old Debian/Ubuntu-supplied) service command falls back from invoking initctl status to behaving as the van Smoorenburg toolset behaves.

That is what was happening on your system until you upgraded the nginx package to a newer one that now included an Upstart job definition for nginx. Before, the fallback was being invoked; now, it is not. The Upstart job file was added in nginx version 1.9.

Further reading

OpenRC

If you are using OpenRC, the output will be the output of OpenRC's rc-service status, which is what service is simply an alias for:

% rc-service nginx status
 * status: started
%

Further reading

van Smoorenburg rc

If you are using the van Smoorenburg toolset, the output will be whatever the rc script itself prints when given the status subcommand. In most cases, especially from Debian 9 onwards, this will be the output of a common helper command that handles status printing for most rc scripts. But it could be anything, and is dependent entirely from how the script decides to handle the subcommand.

The van Smoorenburg rc script shipped in the Debian nginx package uses Debian's status_of_proc helper from its /lib/lsb/init-functions library of shell script functions:

% status_of_proc -p /var/run/nginx.pid /usr/sbin/nginx nginx
* nginx is running
%

Ubuntu has not used van Smoorenburg init+rc since 2006, so any appearance of van Smoorenburg rc behaviour with the (Debian/Ubuntu-supplied) service command will be down to the aforementioned wrinkle of Upstart. The (old) service command will have failed to detect an Upstart job and will have fallen back to treating things as van Smoorenburg rc. (Note that there is no such fallback with systemd or nosh, and you will never see the van Smoorenburg rc behaviour on Ubuntu with either of those, which will always behave as for their native services, which everything runs as.)

Further reading

JdeBP
  • 68,745