Anonymous user
Talk:Run as a daemon or service: Difference between revisions
m
Simplified description
m (Simplified description) |
|||
| (19 intermediate revisions by 6 users not shown) | |||
Line 64:
--[[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)
Line 78 ⟶ 80:
:: 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)
| |||