Ytdyklly

I run to run a command using the su -s command to start a process. Since I do not want the root user to own the process.

I try to do this by issuing the command

su -s "$CATALINA_HOME/bin/catalina.sh run" tomcat

which returns su: /opt/apache-tomcat/bin/catalina.sh run: No such file or directory

How can I run the su -s command along with arguments to not generate this error?

If you're running su as root, you can use -s to specify a different shell (running as root is necessary here since your tomcat user doesn't have a valid shell), and -c to specify the command to run:

su -s /bin/sh -c "$CATALINA_HOME/bin/catalina.sh run" tomcat

You might find start-stop-daemon useful; it has a whole slew of options to specify the user and group to use, how to start the daemon etc. The tomcat8 initscript used in Debian might provide useful inspiration. Or you could look at writing a systemd unit or whatever is appropriate for your system's init.

The -s switch for su command is to change the shell of the specified user. The command you want to run must be preceded by -c switch.

So the command you are looking for is something like this:

su -s /bin/bash -c "$CATALINA_HOME/bin/catalina.sh run" tomcat

Your other questions at https://stackoverflow.com/questions/37753783/ and Is there any way to tell if a shell script was killed with signal 9 indicate that what's missing from your question is that you are trying to run Tomcat under upstart.

In such a case:

• 
  start-stop-daemon is not appropriate.


• Nor is su.


• Nor are Poor Man's Daemon Supervisor gyrations to do PID file management in shell script.

All of those are attempting to duplicate stuff that upstart does directly. The use of su is particularly bad, because it isn't a tool for dropping privileges. It is a tool for adding privileges, in a login session. It nowadays has involvement under the covers with various login session management subsystems that makes it particularly inappropriate for the (much simpler) task of dropping superuser privileges in a dæmon. start-stop-daemon is just supererogatory. And upstart knows the process IDs of its children.

In the upstart job file, use the setuid and (if appropriate) setgid stanzas to drop privileges to an unprivileged user:

setuid tomcat

And if you do invoke catalina.sh via sh -c, which isn't really necessary, don't wander into systemd House of Horror territory. (It's only marginally less horrendous when these sorts of things are done with upstart.) Do things the daemontools way and have the shell chain to the script, invoking it via the shell's exec command so that upstart sees the dæmon as its direct child process. (And make sure that upstart knows this with the correct expect stanza, too.)

An explicit shell isn't necessary in the first place, though, because upstart can invoke catalina.sh directly itself, just as systemd and other service management tools can. You furthermore thus don't have the worry of ensuring that /bin/bash is actually the right interpreter for that script.

exec $CATALINA_HOME/bin/catalina.sh run

Further reading

• James Hunt and Clint Byrum (2014). "setuid". Upstart Cookbook.


• James Hunt and Clint Byrum (2014). "setgid". Upstart Cookbook.


• James Hunt and Clint Byrum (2014). "console log". Upstart Cookbook.


• Jonathan de Boyne Pollard (2014). Don't abuse su for dropping user privileges. Frequently Given Answers.


• Jonathan de Boyne Pollard (2015). Wrapping Apache Tomcat in many pointless extra layers The systemd House of Horror.


• Jonathan de Boyne Pollard (2015). The systemd House of Horror. Frequently Given Answers.


• https://superuser.com/a/723333/38062


• https://superuser.com/questions/683855/