0

When using Upstart, controlling subprocesses (child process) is quite important. But what confused me is as following, which has gone beyond upstart itself:

scenario 1:

root@ubuntu-jstorm:~/Desktop# su cr -c 'sleep 20 > /tmp/a.out'

I got 3 processes by: cr@ubuntu-jstorm:~$ ps -ef | grep -v grep | grep sleep

root       8026   6544  0 11:11 pts/2    00:00:00 su cr -c sleep 20 > /tmp/a.out
cr         8027   8026  0 11:11 ?        00:00:00 bash -c sleep 20 > /tmp/a.out
cr         8028   8027  0 11:11 ?        00:00:00 sleep 20

scenario 2:

root@ubuntu-jstorm:~/Desktop# su cr -c 'sleep 20'

I got 2 processes by: cr@ubuntu-jstorm:~$ ps -ef | grep -v grep | grep sleep

root       7975   6544  0 10:03 pts/2    00:00:00 su cr -c sleep 20
cr         7976   7975  0 10:03 ?        00:00:00 sleep 20

The process of sleep 20 is the one I care, especially in Upstart, the process managed by Upstart should be this while not bash -c sleep 20 > /tmp/a.out is managed by Upstart, while not the sleep 20.

In scenario 1, upstart will not work correctly, above is the reason.

Therefore, why scenario 1 got 3 process, this doesn't make sense for me. Even though I know I can use command 'exec' to fix it, I just want to get the procedure what happened when the two command committed.

Cross
  • 700
  • 1
  • 8
  • 22
  • it looks like [XY problem](http://meta.stackexchange.com/a/66378/137096). What is your actual issue? Forget about `su`, what command do you want to run using `upstart`? Describe what do you expect to happen and what happens instead. – jfs Jan 07 '16 at 06:56

2 Answers2

0
command > file

This is not atomic action, and actually done in 2 process.

One is execute the command; the other do the output redirection.

Above two action can not done in one process.

Am I right?

Cross
  • 700
  • 1
  • 8
  • 22
  • don't post a question as an answer. If it is relevant for the current question then [edit your question instead](http://stackoverflow.com/posts/34646851/edit). Otherwise, ask a new question. – jfs Jan 07 '16 at 06:54
0

su -c starts the shell and passes it the command via its -c option. The shell may spawn as many processes as it likes (it depends on the given command).

It appears the shell executes the command directly without forking in some cases e.g., if you run su -c '/bin/sleep $$' then the apparent behaviour as if:

  1. su starts a shell process (e.g., /bin/sh)
  2. the shell gets its own process id (PID) and substitute $$ with it
  3. the shell exec() /bin/sleep.

You should see in ps output that sleep's argument is equal to its pid in this case.

If you run su -c '/bin/sleep $$ >/tmp/sleep' then /bin/sleep argument is different from its PID (it is equal to the ancestor's PID) i.e.:

  1. su starts a shell process (e.g., /bin/sh)
  2. the shell gets its own process id (PID) and substitute $$ with it
  3. the shell double forks and exec() /bin/sleep.

The double fork indicates that the actual sequence of events might be different e.g., su could orchestrate the forking or not forking, not the shell (I don't know). It seems the double fork is there to make sure that the command won't get a controlling terminal.

Community
  • 1
  • 1
jfs
  • 399,953
  • 195
  • 994
  • 1,670
  • Really smart for using $$ as the args for sleep!!! thanks! And also, bring "double forks" to me, which is so........expert level and glad to learn it. – Cross Jan 08 '16 at 01:53
  • @Cross: it is less about double fork and more [about `setsid()` and making sure the process is not a session leader (and therefore it can't get controlling terminal)](http://stackoverflow.com/questions/881388/what-is-the-reason-for-performing-a-double-fork-when-creating-a-daemon/881415#comment23366466_881408). Beware, even [established commands such as `sudo` may change their behavior related to sessions/process groups/controlling terminals](http://stackoverflow.com/q/34337840/4279) – jfs Jan 08 '16 at 05:54