Am I? Let's test your theory, my friend. Given a script:
int main() { write("I'm returning -1\n"); return -1; }
put it on some remote host and type this on another host:
ssh -T yourlogin@your.remote.host.com /path/to/pike /path/to/tst.pike
According to you no daemonization is necessary in this case (no allocated shell nor terminal) - in this case there's no interactive shell nor a pty allocated, the process should go to the background and return to the calling process. Somehow it doesn't happen. I probably didn't RTFM enough, though.
No, "going to the background" is a separate operation. You can see for yourself that daemonization is not necessary: If you press ^C the ssh process dies but the pike program remains.
In order to put the program in the "background" as well, you just have to use & as usual. An additional quirk with ssh though is that the client will hang around until everything has closed the stdout/stderr that ssh creates. So in this particular case we'll need a redirection too:
ssh -T yourlogin@your.remote.host.com /path/to/pike '>&/dev/null' \ /path/to/tst.pike &
(My login shell is tcsh, so I'm using >& to redirect both stdout and stderr in one go.)
That you should use & to put things in the background shouldn't come as a surprise, and as I said the redirection is only strictly necessary for the ssh case. If starting tst.pike from inetd, cron or rc, you only need to redirect if you are not satisifed with where stdout/stderr ends up per default. In none of these cases do you need nohup.
You really seem to be missing the point.
Quite possibly. Provided that there really is one, apart from "waah waah that's not the solution _I_ though of so I don't like it".
It's only when you start the program manually that you need to daemonize it.
And not only when there's controlling terminal and/or interactive shell?
You only have a controlling terminal and/or interactive shell when you're starting it manually. (Yes, there may be edge cases, but this is the general case.)
Yes, I know, but I'm arguing that that is usually not necessary, since it can be daemonized from "without" instead. There is a good reason for using an external program: It reduces the complexity of your program. Just as not including a file manager in every program but instead relying on the shell reduces the complexity of programs.
What complexity??? Is calling 3 more functions that complex?
It's more complex than not calling them. Hence "adding". It also adds to the complexity of the language to have the function at all. Especially from a porting complexity point of view.
It is probably you who should read the thread again, since the answers to your "real question" is already there, but to recapitulate:
- To daemonize a pike program from the shell: Use nohup.
I was right, you missed the point, completely. I DO NOT want to use nohup to do that. I want the program I invoke to take a parameter and go to the background on its own. It is that simple.
You have a problem: You want to daemonize a program
I have a solution: You run nohup on it
Just throwing yourself on the ground and yelling "DONT WANNA!!!!" when presented with a workable solution just seems to indicate that you weren't really interrested in solving the problem at all.
Sure it is religious. That answer should satisfy you. I've got an allergy to relying on external processes, still trying to find a cure for the itch.
Yeah, but in order to understand the deeper nature of your religion, I was trying to figure out what "relying on external processes" (and other terms of canon to the religion :) really meant, hence the various excursions. It's not terribly important, so you don't have to endulge me if you don't want to. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-03 21:07: Subject: argv[0]?
Fine, let's start nit-picking now. Let's remove the interactive shell from the chain - that still makes your nohup an unncecessary addition which fits nowhere in the picture.
If you remove the interactive shell, then the very operation of daemonization is unnecessary (since the process won't have a controlling shell/terminal anyway), so of course there's no need for nohup in that case. Neither have I suggested that you should have one. You are fighting strawmen.
Am I? Let's test your theory, my friend. Given a script:
int main() { write("I'm returning -1\n"); return -1; }
put it on some remote host and type this on another host:
ssh -T yourlogin@your.remote.host.com /path/to/pike /path/to/tst.pike
According to you no daemonization is necessary in this case (no allocated shell nor terminal) - in this case there's no interactive shell nor a pty allocated, the process should go to the background and return to the calling process. Somehow it doesn't happen. I probably didn't RTFM enough, though.
Should I use nohup to make it detach?
which 5 daemons that are in common use are daemonized by the use of nohup and a redirection of the nohup output to /dev/null?
Using nohup to daemonize something would still not be a property of that program, since you can use nohup to daemonize anything. For example, the 5 programs 'tee', 'sed', 'cat', 'awk' and 'grep' can all be daemonized with nohup (alhough redirecting to something other than /dev/null would usually be more useful for these examples).
You really seem to be missing the point.
Not really. That's mainly because I don't stand around looking over peoples shoulders trying to accumulate statistics on their shell usage. At any rate, most people don't start daemons manually.
What does it have to do with the subject?
It's only when you start the program manually that you need to daemonize it.
And not only when there's controlling terminal and/or interactive shell?
no, you got it all wrong. I want a way to daemonize my program from within it - without relying upon external programs for no good reason.
Yes, I know, but I'm arguing that that is usually not necessary, since it can be daemonized from "without" instead. There is a good reason for using an external program: It reduces the complexity of your program. Just as not including a file manager in every program but instead relying on the shell reduces the complexity of programs.
What complexity??? Is calling 3 more functions that complex?
It is probably you who should read the thread again, since the answers to your "real question" is already there, but to recapitulate:
- To daemonize a pike program from the shell: Use nohup.
I was right, you missed the point, completely. I DO NOT want to use nohup to do that. I want the program I invoke to take a parameter and go to the background on its own. It is that simple.
You are way out of topic here and you perfectly know that. Let me remind you that it was you who came up with that chain of execution, relying on external programs etc.
Yes, that's why I have to struggle with understanding exactly what you mean by them that allows you to draw the conclusions that you do.
I will improve my English, promise.
While, again, the original question is - how to daemonize a pike program? (yes, I can repeat it ad nauseam)
Ok, how about I repeat the answers ad nauseum then, since you don't seem to be satisfied with them only being answered once or twice?
My IQ is just too low, you know. That's the biggest problem of my life... a real tragedy.
hmm? Now you're making personal excursions?
I'm just curious about what's so bad about "relying" on tools provided by the operating system. It seemed like some kind of religious standpoint, and those are typically very personal.
Sure it is religious. That answer should satisfy you. I've got an allergy to relying on external processes, still trying to find a cure for the itch.
/ Marek Habersack (Grendel)