11

I am trying to get systemd to do what init.d scripts would do, showing the status of a service automatically after being manually given a command to start or stop. Is this somehow possible?

systemd unfortunately pops right back since it runs in the background and then you have to do a second command to show the status, the start or stop may or may not have worked, systemd will not tell you unless you ask and leave you blissfully ignorant.

ie. I am trying to get

service nginx status

to run automatically after I do a

service nginx start

or

service nginx restart

(or in brain damaged systemd, systemctl start nginx.service )

ck_
  • 459
  • 1
  • 7
  • 20
  • 2
    I use the "brain damaged" commands (I like them!). They actually says nothing when everything is fine but will let you know when something fails. At least that's how it is on openSUSE 13.1. Are you sure they are "silent" when they fail? Did you try `systemctl start nginx.service && echo SUCCESS || echo failure`? – Huygens Jul 29 '14 at 20:29
  • 2
    @Huygens do not count on systemd being able to detect all fails, there can most definitely be silent fails or warnings. Processes are started in the background and systemd exits control, it is not at all like init.d I can see that happen consistently with PID file creation fails. Getting a status after a manual start or restart is an absolute must with systemd (and point of my question). – ck_ Jul 30 '14 at 00:14
  • thanks for the clarification, I learned something here! I'm looking forward for an answer to this question then! – Huygens Jul 30 '14 at 07:23
  • The braindead syntax is service one because unlike much better systemd syntax it does not allow you to operate on multiple services at once: systemctl stop service1 service2 service3 – god Jun 19 '16 at 23:56
  • Correction: the default `systemctl` behaviour is to wait until the service starts. If you want to start the service in the background and get control back in the shell immediately, you need to `systemctl start nginx.service --no-block`. – Amir Jan 17 '19 at 08:35
  • 1
    If you still see the same inconsistency when checking the exit status of `systemctl` as @Huygens had suggested, then the problem may be that `nginx.service` starts successfully but crashes afterwards. Try checking the journal or in Nginx logs. – Amir Jan 17 '19 at 08:38

4 Answers4

2

I also needed it, so I made it a shell script function.

# Usage
#   sc start nginx
#   sc start nginx php74-php-fpm

function sc {
  name="${@:(2)}";
  echo "COMMAND: ${1}, NAME: ${name}";
  systemctl "${1}" ${name};
  systemctl status ${name};
}

Reduces the command entry process as follows.

#systemctl start nginx; systemctl status nginx
sc start nginx

This is the command added to /root/.basrc in CentOS 7.

echo 'function sc { name="${@:(2)}"; echo "COMMAND: ${1}, NAME: ${name}"; systemctl "${1}" ${name}; systemctl status ${name}; }' >> ~/.bashrc && source ~/.bashrc

Run sc start nginx

COMMAND: start, NAME: nginx
● nginx.service - nginx - high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since 토 2020-11-21 11:36:11 KST; 49s ago
     Docs: http://nginx.org/en/docs/
  Process: 31713 ExecStop=/bin/sh -c /bin/kill -s TERM $(/bin/cat /var/run/nginx.pid) (code=exited, status=0/SUCCESS)
  Process: 31718 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
 Main PID: 31719 (nginx)
   CGroup: /system.slice/nginx.service
           ├─31719 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
           ├─31720 nginx: worker process
           ├─31721 nginx: worker process
           ├─31722 nginx: worker process
           ├─31723 nginx: worker process
           ├─31724 nginx: worker process
           └─31725 nginx: worker process

11월 21 11:36:11 dev5.php79.com systemd[1]: Starting nginx - high performance web server...
11월 21 11:36:11 dev5.php79.com systemd[1]: Started nginx - high performance web server.

Gist - https://gist.github.com/ibin79/4d1d0b5c48ebbc70730292a96ae367d9

Been Kyung-yoon
  • 121
  • 3
1

There's no built-in command for your use-case so you'll have to make an alias for your favorite shell or a trivial script wrapper.

god
  • 232
  • 3
  • 10
0

One solution is to increase SYSTEMD_LOG_LEVEL to debug and then filter the output like e.g.:

$ SERVICES="smartmontools cron xxxxx"
$ SYSTEMD_LOG_LEVEL=debug systemctl restart $SERVICES 2>&1|egrep "Got result|Failed"
Failed to restart xxxxx.service: Unit xxxxx.service not found.
Got result done/Success for job cron.service
Got result done/Success for job smartmontools.service

You can also add a prefix like e.g.

$ SYSTEMD_LOG_LEVEL=debug systemctl restart $SERVICES 2>&1|egrep -i "Got result|Failed"|sed 's,^,restart: ,'
restart: Failed to restart xxxxx.service: Unit xxxxx.service not found.
restart: Got result done/Success for job cron.service
restart: Got result done/Success for job smartmontools.service

SYSTEMD_LOG_LEVEL might not be available on all systems.

reichhart
  • 360
  • 2
  • 7
0

To make systemd more "verbose", add/uncomment the following lines in your /etc/systemd/journald.conf and then reboot:

ForwardToConsole=yes
MaxLevelConsole=debug
Anubioz
  • 3,677
  • 18
  • 23