-1

I'm currently trying to run a python script on a remote server. Of course, if I close the terminal the script terminates.

I've tried to use nohup with the following command: sudo nohup python3 scriptName.py & which returns process and id [1] 1279.

However, on exit command I get:

exit
logout
There are stopped jobs.

[1]+  Stopped                 sudo nohup python3 scriptName.py

With the process terminating.

I'm not too sure what I'm missing, but would be grateful for any help!

tripleee
  • 175,061
  • 34
  • 275
  • 318
TheEpicBlob
  • 38
  • 7
  • The job id is for _sudo_, not nohup. Mind, sudo should typically have detached like then, unless it's busy doing something like prompting for a password (password prompts don't work so well when the program doing the prompting has been put in the background). – Charles Duffy Mar 17 '22 at 13:20
  • ...but arguably the question should be over at [unix.se] or [Ask Ubuntu](https://askubuntu.com/) rather than Stack Overflow at all; it's a usage question, not a software development one. – Charles Duffy Mar 17 '22 at 13:21
  • Related: [Getting sudo and nohup to work together](https://stackoverflow.com/questions/17475098/getting-sudo-and-nohup-to-work-together). See the (incorrect) answer https://stackoverflow.com/a/29099604/14122 making the same mistake you do here. – Charles Duffy Mar 17 '22 at 13:25

1 Answers1

1

Telling Sudo To Start nohup In The Background

The & puts sudo itself in the background, so it can't reliably prompt for a password; if it can't prompt for a password, it won't get to the point where it ever starts nohup at all.

Take off the &, and use -b to tell sudo to put the thing that it starts (in this case nohup) in the background.

sudo -b nohup python3 scriptName.py

Not Using nohup At All

Better than this is to just not use nohup at all. nohup is not a very useful tool; it only does three things:

  1. Redirect stdin to come from /dev/null if it's attached to a TTY.
  2. Redirect any of stdout and stderr that are attached to the TTY to go to nohup.out instead.
  3. Decline to forward HUP signals to its children.

Bash can do all those things itself; there's never a reason to use nohup from bash. Doing this under sudo might look like:

sudo bash -c '"$@" </dev/null >/dev/null 2>&1 & disown -h $!' _ \
  python3 scriptName.py

Explaining how the above works:

  • The </dev/null >/dev/null 2>&1 does the same thing nohup's built-in redirections do (except using /dev/null for output instead of a nohup.out file).
  • The _ fills in $0, so later arguments go into $1 and onward, becoming part of the "$@" array which the inner shell invokes to kick off your actual command.
  • disown -h tells bash not to forward HUP signals (not strictly necessary here since this is a noninteractive shell and that forwarding is only on-by-default in shells with job control enabled in the first place).
Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
  • Thanks, tried both, and still not getting the expected outcome, so must be major PEBKAC. I'll have a tinker. – TheEpicBlob Mar 17 '22 at 13:51
  • One thing that can help is instead of redirecting to `/dev/null`, to direct to a log file and then inspect that file. (I'm not a big fan of nohup hardcoding a `nohup.out` default name, but the general approach is sound; reattaching to anything that's not a TTY should work). – Charles Duffy Mar 17 '22 at 13:53
  • Another thing you can look at is whether there are other file descriptors open on the TTY even with stdin, stdout and stderr taken care of. If you know the PID of your Python process, you can use `sudo lsof -p ${the_pid}` or just `sudo ls -l /proc/${the_pid}/fd` to look for handles on the terminal; any of those will cause problems when the terminal goes away. – Charles Duffy Mar 17 '22 at 13:54
  • ...and if none of that helps, think about using `sudo strace -o somefile.strace -f bash -c ...` -- it's important to start strace _after_ sudo, as it disrupts things if put first (the setuid bit isn't honored when ptrace is active), but that'll leave `somefile.strace` with a full log of what happened at execution. – Charles Duffy Mar 17 '22 at 13:58
  • (one possibility is that shutdown is happening not through a HUP signal but a cgroup-wide kill; I do vaguely recall systemd having some options for whether user sessions should be allowed to leave behind processes on logout -- but then, if you're only trying to support a modern systemd-based Linux distro, why not just set up a user service instead of messing with any of this at all? -- that way you could also do things like set it up to start again on-boot unattended, and could collect logs from the system journal). – Charles Duffy Mar 17 '22 at 14:01