Bash – start-stop-daemon works at command line but doesn’t work in /etc/init.d script

The problem seems to reside in your regex. can you show us what you are trying to match?

if you are trying to match constructs like this :

this.contentOfVar
  contentOfVar

try it with the following :

grep -cP "(this\.|\s)$VARIABLE_NAME" $FILE_PATH

This works in GNU grep. You don't have to specify {1}, since the default will be 1. With the -P flag on, \( and \) will match literal parenthesis in the string, since this is the perl behavior.

In systemd (and other modern init systems), service startup is strictly separated into two steps:

1. User tools (e.g. systemctl) remotely ask init (pid 1) to start a particular service.
2. Init reads the service's configuration, sets up environment (including switching to the desired user account), and runs the executable.

Due to this indirection, services are guaranteed to always have the same environment regardless of who and how started them. (Previously, user environment like locale, path, or SELinux contexts leaking into services used to be a common problem.)

(For init.d scripts, the distro's lsb-functions file contains the magic redirects to 'systemctl start', so they also receive the same indirection.)

This also means that you cannot start a service "as the same user" – you must configure a specific username in the relevant systemd .service file (and if there is none, you really should write one).

The 'start service' call is normally privileged, but you can write a polkit rule allowing it per-user or per-service (if the systemd version is recent enough):

/* /etc/polkit-1/rules.d/allow-whatever.rules */

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units") {
        var verb = action.lookup("verb");
        var unit = action.lookup("unit");
        if (subject.user == "manager"
            && unit == "app.service"
            && (verb == "start" || verb == "stop" || verb == "restart"))
        {
            return polkit.Result.YES;
        }
    }
});

Alternatively, it might be possible to opt out of indirection in the init.d script, but then you would also lose systemd's service tracking entirely – your daemon will look like a regular user process.