Shell – How to suppress stdout / stderr from a shell script output

background-processshell-scriptstderrstdout

I have a script that is suppose to stop and recover the process to run in the background:

process_id=`ps -eaf | grep -i daemon | grep -v grep | grep -v status | grep -v stop | awk '{print $2}'`
(kill -STOP $process_id) &
... # do something else 
(kill -CONT $process_id) &

This is working fine, but then in the STDOUT / STDERR this appears:

[1]  +  8545 Suspended (signal)            /etc/init.d/...

So far I tried to: 

(kill -STOP $process_id)

(kill -STOP $process_id) & > /dev/null

/etc/init.d/{name_of_the_daemon} start > /dev/null

(kill -STOP $process_id & ) 2>/dev/null 

(kill -STOP $process_id & disown;) 2>/dev/null 

set +m
(kill -STOP $process_id) & 

(kill -STOP $process_id) & 1>&2

These are the steps that I'm doing:

  1. create a file fff in /etc/init.d/
  2. paste the script from below
  3. chmod 755 fff
  4. /etc/init.d/fff start

After that, I receive the "suspended" message…

According to @sourcejedi my script is not a daemon; when a child process of the script has been suspended, the "suspended" message appears

How can I suppress the output from the shell for only that particular message?

Here is a very simple version of my script:

#!/bin/bash

pid_script=`ps -eaf | grep -i fff | grep -v grep | grep -v status | grep -v stop | awk '{print $2}'`

case "$1" in
    start)
    ( sleep 3; kill -STOP $pid_script ) &
    sleep 10;
    (sleep 1; kill -CONT $pid_script) &
    ;;
    stop)
    for p in $pid_script # kill all the other processes related with this script (if any)
        do
            kill -9 $p
        done
esac

Best Answer

When you see [1] + 7766 Suspended (signal) ..., this is a message printed by the shell, telling you that one of its child processes has been suspended.

In the fff example, there are two shell processes to consider. Your initial interactive shell, and the shell script which runs as a child process.

Your script arranges to suspend itself. The "Suspended" message is printed by the interactive shell. So this is not an option that you can toggle on or off inside the script.

Additionally, there is no option you could set in the interactive shell to toggle this specific message on or off. It is not possible to "suppress" this message individually... basically because this is never what you want to do :-).

I think the fff script does not successfully resume itself anyway. I think it might be possible to modify it to do so. However, resuming itself is a terrible idea. When you suspend the script, the interactive shell shows its command prompt again. I.e. if you didn't see the "suspended" message, it looks like your script has finished. But either way, if your script managed to resume itself, it would try to steal back control of the terminal from the user, no matter what they had started to do in the mean time. This is not good!

I think you need to understand e.g. that if you launched a process from your terminal and it is a child process of your interactive shell, then it is absolutely not a daemon process.

To start a daemon from your terminal, the program must fork() itself during startup. The original process should exit, and this allows the process which continues to be re-parented e.g. (in traditional unix) to PID 1 a.k.a. the init process. And there are more steps it must include as well, to detach from the terminal. See for example here: Daemonize a process in shell?

Additionally if your system uses systemd, you need to understand that legacy /etc/init.d/ scripts are required to be started using systemctl start. The packaged init.d scripts in Debian and elsewhere include a compatibility hack that does this for you. But you should not use that feature. It is a recipe for confusion. The script you have writen does not have this feature, so you must use systemctl start fff.

I strongly recommend not trying to use the games in the fff script in combination with systemctl start.

In reality systemctl uses a different approach to start background service processes. It sends a message to PID 1 (the systemd init process), and PID 1 starts the requested program. If you define a native systemd service, the program does not need to daemonize itself. If you use a legacy init.d script, the program still needs to daemonize itself, but the only thing it achieves is to tell systemd that the init.d script has finished starting. (This makes it possible to notice some startup failures in daemons, though unfortunately many existing programs have startup failures that can happen after the daemonization step).

You do not want to be worrying about whether and how systemd will react to the init.d script stopping and resuming itself.

Related Question