Talk:Run as a daemon or service: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎Bad definition?: to Dkf: thanks, but i think in casual discussion such formalities are not needed. i am trying to write properly in tasks and i am happy to be called out if i slip there.)
Line 19: Line 19:
}</lang>
}</lang>
:: Run it as <code>./a.out & disown</code> in bash, and it will keep printing to the terminal. It qualifies as a daemon in most senses because it will keep going (verify by the outlog file) even if you log out and kill the terminal. It ''can'' run without a tty, doesn't mean "without a tty" is a necessary condition. --[[User:Ledrug|Ledrug]] 09:56, 17 November 2011 (UTC)
:: Run it as <code>./a.out & disown</code> in bash, and it will keep printing to the terminal. It qualifies as a daemon in most senses because it will keep going (verify by the outlog file) even if you log out and kill the terminal. It ''can'' run without a tty, doesn't mean "without a tty" is a necessary condition. --[[User:Ledrug|Ledrug]] 09:56, 17 November 2011 (UTC)
::: fair enough. however i would not consider that a clean way to write a daemon. the goal here is to write the daemon in such a way that the administrator does not have to jump through hoops to make sure that the process doesn't die if the terminal goes away and to capture all output from the daemon.--[[User:EMBee|eMBee]] 13:14, 17 November 2011 (UTC)
Also, why do you want a daemon process to both detach from stdout ''and'' print to stdout? Wouldn't it be saner to have it directly write to a file to begin with? --[[User:Ledrug|Ledrug]] 08:23, 17 November 2011 (UTC)
Also, why do you want a daemon process to both detach from stdout ''and'' print to stdout? Wouldn't it be saner to have it directly write to a file to begin with? --[[User:Ledrug|Ledrug]] 08:23, 17 November 2011 (UTC)
: I want it to detach from the stdout that is connected to the users terminal, and write to a file as if it were stdout. Redirecting stdout is the sanest way to achieve that because the internals of the program and the libraries used can continue to write to what looks like stdout. If I open a file in the daemon itself and use that, I have to go out of my way to make sure that everywhere I have output the file is used. I have to make that file globally accessible or pass it around as a variable. There may be languages/situations where this is the better option, but I would not say that it is always better or saner.--[[User:EMBee|eMBee]] 08:56, 17 November 2011 (UTC)
: I want it to detach from the stdout that is connected to the users terminal, and write to a file as if it were stdout. Redirecting stdout is the sanest way to achieve that because the internals of the program and the libraries used can continue to write to what looks like stdout. If I open a file in the daemon itself and use that, I have to go out of my way to make sure that everywhere I have output the file is used. I have to make that file globally accessible or pass it around as a variable. There may be languages/situations where this is the better option, but I would not say that it is always better or saner.--[[User:EMBee|eMBee]] 08:56, 17 November 2011 (UTC)

Revision as of 13:14, 17 November 2011

Bad definition?

It's probably better to describe a daemon as a process that runs in the background and independent of a user's login session, if anything.

True, I'll try to integrate that into the description.--eMBee 08:56, 17 November 2011 (UTC)

"Not connected to a terminal" isn't quite it, a daemon could print to a tty all day if it wants to.

Yes, but only if it opens the tty manually. It should otherwise be able to run without a tty being present.--eMBee 08:56, 17 November 2011 (UTC)
Not really. <lang c>#include <stdio.h>
  1. include <stdlib.h>

int main(void) {

       FILE *fp = fopen("/tmp/outlog", "w");
       while (1) {
               printf("yes\n");
               fprintf(fp, "out\n");
               fflush(fp);
               sleep(1);
       }

}</lang>

Run it as ./a.out & disown in bash, and it will keep printing to the terminal. It qualifies as a daemon in most senses because it will keep going (verify by the outlog file) even if you log out and kill the terminal. It can run without a tty, doesn't mean "without a tty" is a necessary condition. --Ledrug 09:56, 17 November 2011 (UTC)
fair enough. however i would not consider that a clean way to write a daemon. the goal here is to write the daemon in such a way that the administrator does not have to jump through hoops to make sure that the process doesn't die if the terminal goes away and to capture all output from the daemon.--eMBee 13:14, 17 November 2011 (UTC)

Also, why do you want a daemon process to both detach from stdout and print to stdout? Wouldn't it be saner to have it directly write to a file to begin with? --Ledrug 08:23, 17 November 2011 (UTC)

I want it to detach from the stdout that is connected to the users terminal, and write to a file as if it were stdout. Redirecting stdout is the sanest way to achieve that because the internals of the program and the libraries used can continue to write to what looks like stdout. If I open a file in the daemon itself and use that, I have to go out of my way to make sure that everywhere I have output the file is used. I have to make that file globally accessible or pass it around as a variable. There may be languages/situations where this is the better option, but I would not say that it is always better or saner.--eMBee 08:56, 17 November 2011 (UTC)