>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(a)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(a)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(a)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)
>