Bugzilla – Bug 665
script running under sudo can't recursively call itself in background
Last modified: 2018-01-16 14:25:51 MST
Created attachment 429 [details] screen output from test script When a script is run via sudo it can't recursively call itself in the background. For example, test.ksh takes 1 arguement (start), should echo start start2 and touch file in /var/tmp. but the "$0 start2 &" doesn't appear to get run (there are no errors): #!/bin/ksh if [[ $1 == "start" ]] then echo $1 $0 start2 & else echo $1 touch /var/tmp/start2 fi Running it without sudo works ok, as does removing the "&" from line 5 and running with sudo. We have just upgraded from SMCsudo to TCMsudo and the script has worked previously on SMCsudo. The server is a Sun/Oracle T4-4 (sparc) running Solaris 10, TMCsudo1.8.11.
This sounds like a race condition between the parent script and the child. The script works fine for me on a single-CPU instance in a VM either normally or in a pseudo-tty (use_pty or log_output in sudoers). However, if I add a sleep that guarantees that the foreground process exits before the background one is done I see what you describe when the command runs in a pty. What happens is that the pty that the command was using goes away after the foreground command has exited. Any child of the command receives SIGHUP from the kernel when this happens which is why you don't see the background job finish. You can use nohup to prevent the background job from being killed by SIGHUP. It will also store the output in the file nohup.out since the command doesn't have access to a tty after the parent exits. If you don't have use_pty or one of the log_* options set in sudoers then something else may be going on.
This works as expected with sudo 1.8.22 both with and without log_output. sol10 [~] % ls -l /var/tmp/start2 /var/tmp/start2: No such file or directory sol10 [~] % sudo /var/tmp/sudotest start start start2 sol10 [~] % ls -l /var/tmp/start2 -rw-r--r-- 1 root root 0 Jan 16 14:24 /var/tmp/start2 If the problem still occurs with sudo 1.8.22, please re-open the bug.