3

I am aware that adding a '&' in the end makes it run as a background but does it also mean that it runs as a daemon?

Like:

celery -A project worker -l info &

celery -A project worker -l info --detach

I am sure that the first one runs in a background however the second as stated in the document runs in the background as a daemon.

I would love to know the main difference of the commands above

Dean Christian Armada
  • 6,724
  • 9
  • 67
  • 116
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. – jww Oct 20 '17 at 04:54

3 Answers3

2

Yes the process will be ran as a daemon, or background process; they both do the same thing.

You can verify this by looking at the opt parser in the source code (if you really want to verify this):

. cmdoption:: --detach
    Detach and run in the background as a daemon.

https://github.com/celery/celery/blob/d59518f5fb68957b2d179aa572af6f58cd02de40/celery/bin/beat.py#L12

https://github.com/celery/celery/blob/d59518f5fb68957b2d179aa572af6f58cd02de40/celery/platforms.py#L365

Ultimately, the code below is what detaches it in the DaemonContext. Notice the fork and exit calls:

def _detach(self):
    if os.fork() == 0:      # first child
        os.setsid()         # create new session
        if os.fork() > 0:   # pragma: no cover
            # second child
            os._exit(0)
    else:
        os._exit(0)
    return self
Rafael
  • 7,605
  • 13
  • 31
  • 46
  • So in short, you think that the two commands that I mentioned is just the same, also on the resources that will be allocated? – Dean Christian Armada Oct 20 '17 at 03:11
  • Ultimately, yes. – Rafael Oct 20 '17 at 03:12
  • Oh great! However, the comment below says it's different. Any justifications?? – Dean Christian Armada Oct 20 '17 at 03:19
  • The answer really comes down to the environment. Take a look at [this question](https://stackoverflow.com/questions/32780706/does-linux-kill-background-processes-if-we-close-the-terminal-from-which-it-has). AFAIK forking and exiting is the same thing in both cases, the ignore hangup command was not issued in the python code, so I'd say that my answer is still correct, unless I am misunderstanding something. – Rafael Oct 20 '17 at 03:28
  • A new session is created in the python code, making the calling process a leader (not a descendant of the shell anymore). In the case of using `&` it is still a descendant of the shell and *may* close, depending on the environment setup, when the shell is closed. As far as your concerns go, pertaining to resources, there is no run-time performance difference. I will upvote them because, they are not wrong. – Rafael Oct 20 '17 at 03:33
  • OK, great! That completely answers my question! – Dean Christian Armada Oct 20 '17 at 03:34
2

They are different!

"&" version is background , but not run as daemon, daemon process will detach with terminal. in C language ,daemon can write in code :

fork()
setsid()
close(0) /* and /dev/null as fd 0, 1 and 2 */
close(1)
close(2)
fork()

This ensures that the process is no longer in the same process group as the terminal and thus won't be killed together with it. The IO redirection is to make output not appear on the terminal.(see:https://unix.stackexchange.com/questions/56495/whats-the-difference-between-running-a-program-as-a-daemon-and-forking-it-into)

a daemon make it to be in its own session, not be attached to a terminal, not have any file descriptor inherited from the parent open to anything, not have a parent caring for you (other than init) have the current directory in / so as not to prevent a umount... while "&" version do not

peter__barnes
  • 351
  • 2
  • 5
  • I get the point on the difference with just the plain background and daemon, now my question is.. WIll there be any difference in the performance? – Dean Christian Armada Oct 20 '17 at 03:15
  • if --detach is real deamon as the document said ,there will be some difference, the & version's standard output will not redirect(still print to screen), and the process is still a child of the terminal ... some of these difference are not obvious,that depend on the code and its' functions .By the way ,I made a mistake in old version, process may not killed when terminal quit. – peter__barnes Oct 20 '17 at 06:22
  • It's ok. Thanks for the answers – Dean Christian Armada Oct 20 '17 at 09:12
1

Not really. The process started with & runs in the background, but is attached to the shell that started it, and the process output goes to the terminal.

Meaning, if the shell dies or is killed (or the terminal is closed), that process will be sent a HUG signal and will die as well (if it doesn't catch it, or if its output goes to the terminal).

The command nohup detaches a process (command) from the shell and redirects its I/O, and prevents it from dying when the parent process (shell) dies.

Example:

You can see that by opening two terminals. In one run

sleep 500 &

in the other one run ps -ef to see the list of processes, and near the bottom something like

me   1234   1201   ... sleep 500
        ^      ^
process id    parent process (shell)

close the terminal in which sleep sleeps in the background, and then do a ps -ef again, the sleep process is gone.

A daemon job is usually started by the system (its owner may be changed to a regular user) by upstart or init.

Déjà vu
  • 28,223
  • 6
  • 72
  • 100
  • What about the resources that will be allocated? Will it be the same? – Dean Christian Armada Oct 20 '17 at 03:27
  • In terms of resources, the shell will do a `fork()` then an `exec...()` that replaces the forked-shell with the new process, but the process started with `&`, unlike the one started by the system, will inherit the environment of the shell - that you might not want, depending on your application. In your case (& and --detach), they're both started from the shell, so they both get the same environment. – Déjà vu Oct 20 '17 at 03:32
  • Ok, I understood it very well! – Dean Christian Armada Oct 20 '17 at 03:37