1

Solved: I solved this problem by introducing a delay before executing the script: @reboot sleep 60; /root/start_server.sh

On Ubuntu 14.04, I have a crontab entry set to run on reboot:

@reboot /root/start_server.sh

And here's start_server.sh:

screen -dmS server bash -c "cd server ; ./run.sh"

When the system starts up, run.sh is indeed executed, and the server remains up, but there are no sessions when I type screen -ls. Because of this, I can't access my server process after boot.

What's happening to the session I named "server"? If it's being terminated somehow, how do I prevent that?

I've tried adding exec bash to start_server.sh as per the answer here, but it had no effect.

Community
  • 1
Macroeel
  • 11
  • Does ps -A show that screen is still running? Also, are you running screen -ls as the same user that screen originally starts as? – wingedsubmariner Sep 25 '14 at 19:25
  • No, ps -A does not list screen. As for your second question, I'm unsure. I'm running screen -ls as root, and the job was assigned to root's crontab entry. That means screen starts under root, right? – Macroeel Sep 25 '14 at 20:45
  • Yes, I believe it will be running as root. The only possibility I can think of is that run.sh terminates, ending the screen session. If the server detaches from the starting terminal and goes into the background, then run.sh will terminate, even though the server keeps running. – wingedsubmariner Sep 26 '14 at 00:39
  • Have you patched Bash for the shellshock vulnerability? That patch removes some of bash's ability to execute commands fed to it on stdin as the screen may be doing. Try it with the old, unpatched version of bash that was on your system. That would be the quickest way to rule that out. – DocSalvager Oct 08 '14 at 08:55
  • try run sudo screen -ls it appeared that screen is shown only for user by whom it was created – Sergiy Kozachenko Oct 27 '17 at 11:03

0 Answers0