When you see
 + 7766 Suspended (signal) ..., this is a message printed by the shell, telling you that one of its child processes has been suspended.
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 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.