Anonymous user
Talk:Run as a daemon or service: Difference between revisions
m
Simplified description
m (Simplified description) |
|||
| (10 intermediate revisions by 4 users not shown) | |||
Line 103:
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)
| |||