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

Line 22:
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)
:: This strikes me as bad modularity. If you want the program detached from the shell's stdio context you can and should do that in the shell. You should not replicate that shell-specific code in every program. It's an unnecessary complication for programs running from inittab, for example. For example, from bourne shell:
::: i do not understand this point. every daemon would need its own shellscript because they all have different files their output needs to go to. there is nothing that shellscripts would avoid from being replicated.
 
::: also, depending on the language, the code to detach the daemon may be no more complex than the shellscript.--[[User:EMBee|eMBee]] 15:15, 17 November 2011 (UTC)
:: It's an unnecessary complication for programs running from inittab, for example. For example, from bourne shell:
::<lang bash>(myprog </dev/null >/dev/null 2>&1 &)</lang>
 
::This detaches <code>myprog</code> from the shell (its parent process will be init, and it obviously will not be using the shell's terminal). And, of course, if you want to reconfigure it to log to a file (or to another process) from stdout, you could do that instead.
 
::But if you are really serious about running myprog as a daemon, you should probably run it from inittab (or xinittab or whatever ...), probably wrapped in <code>su</code> and so it runs as a relevant user. --[[User:Rdm|Rdm]] 14:42, 17 November 2011 (UTC)
::: an unnecesary complication is having to write a shell script in order to run a daemon. X and getty are run from inittab without a shell and we can probably find other examples, of course we can find counter examples too, but i don't see a reason prefer using a shell wrapper.
::: also there are only few developers writing the daemon, but many more sysadmins running it. so any complication that is taken away from the sysadmin and moved to the developers is a win in the long run.
::: but the main point really is to show of the capabilities of languages here. using a shell script would defeat that purpose and would not fit on rosettacode. it also would not be portable.--[[User:EMBee|eMBee]] 15:15, 17 November 2011 (UTC)
Anonymous user