Anonymous user
Talk:Run as a daemon or service: Difference between revisions
m
Simplified description
m (Simplified description) |
|||
| (24 intermediate revisions by 6 users not shown) | |||
Line 48:
::::: well, yes, except that this is very rare. to many services need special handling, extra arguments. some don't like their stdout redirected to /dev/null because they actually write something there, to the extent that it is rather hard to have one shell script to cover all. there is a reason why the sysv init has one shell script for each service.--[[User:EMBee|eMBee]] 18:09, 17 November 2011 (UTC)
:::: Meanwhile, if you are not running the program from the shell, there is no reason to detach it from the shell context. --[[User:Rdm|Rdm]] 17:50, 17 November 2011 (UTC)
::::: true. with a modern init system this is not needed, but it is nice to have the option and none of the arguments given here show that being able to detach from the terminal is inherently bad, nor has anyone yet explained that we shouldn't document capabilities that do exist. however all comments so far center on a solution which is outside of the scope of rosettacode because it has nothing to do with language comparison if we use a shellscript to solve the problem for any language. the shell solution will have its place in the [[
== A different angle ==
i'd like to restart the discussion from a different angle. instead of discussing a solution which is beyond the scope of rosettacode, i'd like to ask this direct question:
* is this task suitable for rosettacode?
if the discussion until now is any indication then the answer is ''no''.
however i'd disagree with that.
* the capability to disconnect from a tty and to redirect or close stdout,stderr,stdin from within a process does exist in more than one language so it is worth demonstrating it.
* this method of writing daemons has been used traditionally for a long time. a search for "how to write a unix daemon" has most links on the first result pages point to resources that explain just this method and do not talk about shell scripts. and it not only works on unix. (DOS TSR comes to mind)
* using a shell script is a very unix centric solution whereas an in-language solution is likely more portable.
--[[User:EMBee|eMBee]] 18:23, 17 November 2011 (UTC)
: I did not see anything in this task which was relevant to DOS TSRs.
:: see [[wp:Daemon_(computing)#Implementation_in_MS-DOS_and_Microsoft_Windows|Wikipedia]]: ''In the Microsoft DOS environment, daemon-like programs were implemented as Terminate and Stay Resident (TSR) software.''--[[User:EMBee|eMBee]] 09:19, 18 November 2011 (UTC)
::: Yes... ok, TSRs get mentioned. But to set up a DOS TSR you need to arrange for your interrupt handler to remain after the program exits, and of course you also need to set things up so that when interrupts happen the handler gets the interrupts. Then you need to exit the program. But this task is not about setting up interrupt handlers under DOS. Most of the languages here will not even run under DOS. So, anyways, this task is not about setting up a DOS TSR, and would not be useful for setting up a DOS TSR. --[[User:Rdm|Rdm]] 15:37, 18 November 2011 (UTC)
: As far as I know, this approach (redefining stdout) is only relevant for "daemons" when you are running the program under Unix. --[[User:Rdm|Rdm]] 18:36, 17 November 2011 (UTC)
:: from a users perspective the process ends, but it is actually still there. the fact that DOS TSR requires an interrupt for the program to wake up has more to do with the lack of multitasking than being something different alltogether.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
: Current problems with the task:
: # It's difficult to say what constitutes a daemon. It should run in background in some sense, and preferrably do something useful; other than that anything goes. It may or may not hold on to a tty (getty vs sendmail); it may or may not be system wide (gnome launches a million per-user background processes upon user session start); it may or may not interact with direct user input (gpm, XIM daemon, etc). You need to narrow it down, or change the task to just focus on detaching from parent process.
:: hmm, all these should be fine. the daemon just shouldn't interact with the shell that it was started from.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
: # Backgrounding a process has more to do with OS than programming language.
:: but programming languages may well include support for this for different OSes so that the programmer does not have to deal with the details. or they may not. we might find out in the course of this task.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
: On unix you may let init adopt the process, on Windows you need to have user login script to start the process or use regsvc or svchost. It's also not clear if any of the systray icons count as a daemon.
:: they probably would if the program disconnects from the command shell it was started from. but i don't know how that actually works on windows. i'll probably find out at some point--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
: # Redirecting stdio is useful to have the daemon not die unexpectly on hangup or something, but it's not a defining property.
:: correct. it is a requirement specific to this task.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
:Also your requirement of redirecting is strange: the program is supposed to write to stdout; the program is not supposed to ''really'' write to stdout; the program is not supposed to worry about where the output goes; the program is not supposed to be invoked by shell redirection, so it must know where the output goes. Make up your mind, maybe? --[[User:Ledrug|Ledrug]] 00:10, 18 November 2011 (UTC)
:: ok, this needs clearing up: the daemon should not write to the stdout that is connected to the terminal it was started from. it may write to stdout if that has been redirected to a file, by means that are either within the daemon itself or in a separate helper program written in the same language.
:: the part with not caring was supposed to refer to functions or libraries used within the daemon which constitute the useful part, not the daemonizing part. that is, it should be possible to take an existing program, and turn it into a daemon without having to replace all references of say <code>printf(...)</code> with <code>fprintf(somefile,...)</code>--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
::: And, of course, the shell script approach supports all of this. Redirect to /dev/null means those printf references do not have to be changed and, if stdout is redirected within the program, their output will be redirected appropriately. --[[User:Rdm|Rdm]] 18:56, 18 November 2011 (UTC)
== Strange stdout rule ==
For some strange reason, the current draft task wants to use "stdout which should be redirected to a file". This redirection of stdout has no purpose to the daemon, and is not better than simply opening a file. To redirect stdout, my C code calls dup2().
<lang c>fd = open(argv[1], O_WRONLY | O_APPEND | O_CREAT, 0666);
dup2(fd, STDOUT_FILENO);
fputs("string\n", stdout);</lang>
But if I forgot stdout, I would simplify the code by removing open() and dup2() and using a regular fopen().
<lang c>file = fopen(argv[1], "a");
fputs("string\n", file);</lang>
I suggest to remove the stdout rule from the draft task, and to permit each solution to write to a file without regard to whether it redirects stdout. --[[User:Kernigh|Kernigh]] 00:55, 19 November 2011 (UTC)
: you are permitted to write to any file that you want, but in addition to that i'd like to know how you can do the above. this could be a seperate task, but i find tasks more interesting if they combine a few simple requirements to form a program than just questions like ''"how do you redirect stdout?"''--[[User:EMBee|eMBee]] 02:59, 19 November 2011 (UTC)
== Doh, use screen! ==
You can run processes under screen so that they always have a tty. And screen can be detached from your real tty, then re-attached later.
Screen makes an obsolete practice of in-the-app daemonization.[[Special:Contributions/24.85.131.247|24.85.131.247]] 03:34, 15 January 2012 (UTC)
: i have found screen seems to be popular among the lisp community probably in order to keep access to the repl, but i don't like it. the thing that screen does not do is restart your daemon if it disappears.--[[User:EMBee|eMBee]] 06:06, 15 January 2012 (UTC)
:: <code>while true ; yourdaemon ; done</code> [[Special:Contributions/24.85.131.247|24.85.131.247]] 03:18, 17 January 2012 (UTC)
::: sure, anything can be done by hand. but the job of a sysadmin is to automate things. if i am going to write a script, i might as well write a real init script. but then i don't need screen anymore.
:::: An init script doesn't provide the functionality of screen. A little while loop to run a program over again is hardly a script.[[Special:Contributions/24.85.131.247|24.85.131.247]] 04:48, 17 January 2012 (UTC)
::: doing things by hand is like starting a car with empty batteries. you push it until the motor can be started. this task is about including the batteries. you start the program and it does everything by itself. no extra scripting required.--[[User:EMBee|eMBee]] 03:38, 17 January 2012 (UTC)
:::: I'm afraid you and the unsigned guy are above grasping at straws here to make a point. Pardon me, I'm only describing the simplest possible way of doing it.[[Special:Contributions/24.85.131.247|24.85.131.247]] 04:48, 17 January 2012 (UTC)
::::: the simplest way for whom? the developer? sure, because the developer then doesn't need to bother with running the daemon. for the user? well, anything extra the user needs to do is a complication. regardless how small. depending on screen certainly is one. as a developer i can't be sure that screen is available on the target machine, even if i provide all the scripts for it. so why add the extra dependency when i can write the daemon in such a way that it does not depend on additional tools just to run it as a daemon.--[[User:EMBee|eMBee]] 06:29, 17 January 2012 (UTC)
:::: A half-liner while loop to restart a program is hardly comparable to pushing a car, and such a little script can in fact be part of the application (an included battery). (Never seen Unix programs that are actually launched by shell scripts that are installed by the application installer?)[[Special:Contributions/24.85.131.247|24.85.131.247]] 04:48, 17 January 2012 (UTC)
::::: For the record (and off topic): there was no "unsigned guy" here except for anon IPs. It's probably unfair to break up someone else's comment in halves and then blame the first half for lacking a signature. --[[User:Ledrug|Ledrug]] 05:20, 17 January 2012 (UTC)
:::::: actually, it makes it look like there is another person arguing my point. so i think that works in my favour :-) --[[User:EMBee|eMBee]] 06:29, 17 January 2012 (UTC)
: personally i use screen actively, and if i start a daemon inside screen i exactly do not want it to clutter up my screen terminals, but get out of the way.--[[User:EMBee|eMBee]] 06:06, 15 January 2012 (UTC)
:: This is not about cluttering your interactive screen sessions with daemons, but screen as a dedicated tool for having daemons running. Like under a different user ID from your account, etc! To interact with the daemons, you might "su" to a different account and attach a different screen session. Such screen sessions can be arranged to start at boot time with daemons in them. [[Special:Contributions/24.85.131.247|24.85.131.247]] 04:51, 17 January 2012 (UTC)
::: two screens is also clutter. if i want to run the daemon as a user that is already running screen, i get an additional screen session which adds an extra step every time i want to connect to the interactive session. and if i want to run multiple daemons do i run a separate screen session for each? or all in one session with multiple terminals? what if screen gets stuck and you can no longer connect to it to run additional daemons? yes, i have seen that happen. the only way out was to kill screen which would bring down all the daemons inside.
:::: I haven't used screen in many years, yet I certainly do remember bugs like that. But, surprisingly, it seems to be quite actively maintained.There is quite a bit of recent activity in the GIT repo: http://git.savannah.gnu.org/cgit/screen.git What version are you using? [[Special:Contributions/24.85.131.247|24.85.131.247]] 07:31, 17 January 2012 (UTC)
:::: Then again, there are a LOT of un-investigated bugs in the database also (including one generic one about the hangs and one about attaching from another user and tty permissiosn). The most recent bug was reported a few days ago: someone ran gcc -Wall and found a few issues. That's pretty terrible for an old project.[[Special:Contributions/24.85.131.247|24.85.131.247]] 08:02, 17 January 2012 (UTC)
:::if you "su" to a user other than root, then you keep using your existing terminal and screen can't connect because the new user does not have permission to access the terminal:
$ screen
Cannot open your terminal '/dev/pts/1' - please check.
::: so multiple daemons in one screen session is not practical either. there are ways around it (eg. by running <code>script</code>) but that's just another complication.
::: i am afraid we just have to agree to disagree. in my view screen is for interactive sessions. a daemon is not interactive, and there are better tools out there to run programs in the background than screen. either way, this task is not about any of those existing tools but about the capability of a language to build such a tool--[[User:EMBee|eMBee]] 06:29, 17 January 2012 (UTC)
: From my perspective, the problem with screen is that it is a manual solution at all. Daemons should run without having someone start them up by hand; after all, if it is a true daemon then it will have been set to be started automatically upon reboot of the machine (or on demand by some automated code that is itself auto-started). While I suppose I could automate screen's startup with the use of expect, the resulting hacked together lash up(/ball of mud/screaming horror from the depths) is enough to give me shivers just thinking about it. Screen is ''not'' a solution to this problem. –[[User:Dkf|Donal Fellows]] 09:43, 17 January 2012 (UTC)
:: screen has arguments to start a detached session, and run a command in that session. <code>screen -dmS <session_name> /path/to/your/server</code>. [[Special:Contributions/24.85.131.247|24.85.131.247]] 04:24, 18 January 2012 (UTC)
===Simplified description===
I propose we just simplify the task description as follows:
A daemon is a service that runs in the background independent of a users login session. The task is to demonstrate the steps that a program needs to take run as a background daemon or service.
[[User:Markhobley|Markhobley]] 12:49, 29 March 2013 (UTC)
| |||