I cannot get my point accross. Sorry for posting any of what I posted. I shouldn't have spoken at all. Pike is not my domain, so I shouldn't comment on it at all. I will just stay in my sandbox - the debian packaging. Thanks and sorry for the mess.
/ Marek Habersack (Grendel)
Previous text:
2002-09-03 22:44: Subject: argv[0]?
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!)