12

I am trying to run a detached screen under a specific user in rc.local on boot. The code below is what I have so far, but it is not working for me. The su part seems to be giving me an error.

su - username -c /usr/bin/screen -dmS test bash -c '/var/www/path/to/script/script.sh; exec bash'
muru
  • 197,895
  • 55
  • 485
  • 740
ATLChris
  • 395
  • 1
  • 6
  • 13

4 Answers4

14

I think both -c parameters (su and bash) will have to be quoted at a minimum.

su - username -c "/usr/bin/screen -dmS test bash -c '/var/www/path/to/script/script.sh; exec bash'"

Also - is expected to be last and may not be desirable here (see man su).

A few more remarks. sudo could be a better choice for a one-shot command like yours, but not necessarily:

sudo -iu username /usr/bin/screen -dmS test bash -c '/var/www/path/to/script/script.sh; exec bash'

In particular, you can use one less level of quoting with sudo.

Another thing you want to be careful with is executing commands without absolute path in a privileged context. This holds for su (or sudo) but also for the path to bash in your command. You are doing it right with screen.

Just tested the following and it works nicely. I think the - is the main issue in your original line:

/bin/su username -c "/usr/bin/screen -dmS test bash -c '/home/username/test.sh; exec bash'"

Evil remark: why don't you give tmux a try? I have recently switched and never looked back. The only thing I needed to change immediately was the prefix key combination which in tmux defaults to Ctrl + B - back to GNU screen's Ctrl + A.

It allows splitting your window into an almost arbitrary number of panes (vertically and horizontally) and its configuration file format (including the one for the status par) is actually intelligible to humans. Of course tmux is as good as screen when you simply want to run some program/script not originally written as daemon in background. If you intend to interact with the terminal multiplexer, however, I warmly recommend tmux.

muru
  • 197,895
  • 55
  • 485
  • 740
0xC0000022L
  • 5,720
  • I will give this a try in a few. The script I am running uses absolute paths, so would you recommend su or sudo? – ATLChris Feb 27 '13 at 13:03
  • 1
    sudo is not a good choice if run from rc.local where you already are root, since you will miss a login shell. On a side note, have a look at /etc/init/tty1.conf - replace [a]getty with screen here. – aquaherd Feb 27 '13 at 13:12
  • @aquaherd: it's what I had in mind when I wrote but not necessarily. The clue, really, is in the usual sudo su - ... sudo (superuser do), su (switch user) ... good idea about the .conf – 0xC0000022L Feb 27 '13 at 14:10
  • 1
    I have to say, I'm +1ing this post just because of your evil remark. I love it! It's a great replacement to screen, since one can force it to start a new session. – The Quantum Physicist Apr 08 '15 at 10:13
  • @aquaherd sudo can start a login shell just fine using -i. – muru Jan 08 '16 at 21:23
2

Here is what I used I found it to be the cleanest and simplest (tested working myself):

Replace "user" with the user to run it as. Replace "nameyouchoose" as the name of the screen session Replace "/script/start.bash" to the path of your script.

/usr/bin/sudo -u user /usr/bin/screen -dmS nameyouchoose /script/start.bash

Source: http://realtechtalk.com/How_to_start_screen_in_bash_script_or_from_etcrclocal_on_startup_as_a_specific_user-1980-articles

Areeb Soo Yasir
  • 171
  • 3
2

Starting a script in a new detached screen as current user (rc.local = root):

screen -dmS <session name> <command>, example:

screen -dmS screenName bash /home/user/run.sh

Starting a script from rc.local as user:

runuser -l user -c 'screen -dmS screenName bash /home/user/run.sh'

DaWe
  • 130
  • 3
1

Try sudo -u username instead of su - username

prophecy201
  • 2,690
  • 16
  • 21