Comment 1 for bug 1792400

This is "just one more" case of the common old init scripts didn't consider there could be more (=containers).

Interesting is that the stop already runs with the --pidfile so the stop will not kill it.

But the start will be blocked, as the existance of such a process will make --start be a no-op.

Man page:
Note: unless --pid or --pidfile are specified, start-stop-daemon behaves similar to killall(1). start-stop-daemon will scan the process table looking for any processes which match the process name, parent pid, uid, and/or gid (if specified). Any matching process will prevent --start from starting the daemon. All matching processes will be sent the TERM signal (or the one specified via --signal or --retry) if --stop is specified. For daemons which have long-lived children which need to live through a --stop, you must specify a pidfile.

-S, --start [--] arguments
Check for the existence of a specified process. If such a process exists, start-stop-daemon does nothing, and exits with error status 1 (0 if --oknodo is specified). If such a process does not exist, it starts an instance, using either the executable specified by --exec or, if specified, by --startas. Any arguments given after -- on the command line are passed unmodified to the program being started.

The --oknodo will make it a silent non fatal exit int hat case - as it is fine to run "start" if it is running already.

I'd recommend "--pidfile $SMBDPID" instead of the suggested path, but otherwise would agree to the fix.

It should be safe as that is essentially how later versions (Bionic) do it (via MAINPID tracking in systemd).