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)
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!)
You are welcome to comment on Pike, but I think you'll find your comments will be better recieved if they are better motivated. True, there is a domain conflict. In matters where only religion can decide, our religion will be the norm. But we might yield to actual reason. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-03 22:46: Subject: argv[0]?
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)
I guess I'm just not the one who should speak up - I never was good at talking with people, so screw it. To sum up - I just don't understand what a fucking harm can a function, module, class whatever do just by existing, that's it. If a feature doesn't bother anybody, and it pleases somebody else, is useful for them - it's enough of a reason for me to implement it. But I guess I'm just a dumbfuck.
/ Marek Habersack (Grendel)
Previous text:
2002-09-03 22:55: Subject: argv[0]?
You are welcome to comment on Pike, but I think you'll find your comments will be better recieved if they are better motivated. True, there is a domain conflict. In matters where only religion can decide, our religion will be the norm. But we might yield to actual reason. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Well, basically we believe that introducing functions that are inherently importable by being heavily influenced by e.g. UNIX intrinsics (fork would be a prime example of this) _can_ hurt the language, by making Pike programs less portable. So we are reluctant to have such functions if the actual high level operation (the goal, rather than the means) associated with the function can be reasonably simply accomplished in some other way.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-03 22:57: Subject: argv[0]?
I guess I'm just not the one who should speak up - I never was good at talking with people, so screw it. To sum up - I just don't understand what a fucking harm can a function, module, class whatever do just by existing, that's it. If a feature doesn't bother anybody, and it pleases somebody else, is useful for them - it's enough of a reason for me to implement it. But I guess I'm just a dumbfuck.
/ Marek Habersack (Grendel)
fair enough
/ Marek Habersack (Grendel)
Previous text:
2002-09-03 23:06: Subject: argv[0]?
Well, basically we believe that introducing functions that are inherently importable by being heavily influenced by e.g. UNIX intrinsics (fork would be a prime example of this) _can_ hurt the language, by making Pike programs less portable. So we are reluctant to have such functions if the actual high level operation (the goal, rather than the means) associated with the function can be reasonably simply accomplished in some other way.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
I seriously doubt the possibility to (perhaps) change the arg or display name in Unix would be hurtful, granted it was marked / documented correctly.
/ David Hedbor (I live in interesting times)
Previous text:
2002-09-03 23:06: Subject: argv[0]?
Well, basically we believe that introducing functions that are inherently importable by being heavily influenced by e.g. UNIX intrinsics (fork would be a prime example of this) _can_ hurt the language, by making Pike programs less portable. So we are reluctant to have such functions if the actual high level operation (the goal, rather than the means) associated with the function can be reasonably simply accomplished in some other way.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
I know of code that will break. That doesn't mean that I have a strong opinion in the matter. Let's get the Pikefarm up properly (we'll have a meeting end of this week to determine the shoppinglist for the last items we need) and get some green plupps and then we can open for more experimental work.
Speaking of the future; might this weekend be good to try release Pike 7.4?
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-09-03 23:13: Subject: argv[0]?
I seriously doubt the possibility to (perhaps) change the arg or display name in Unix would be hurtful, granted it was marked / documented correctly.
/ David Hedbor (I live in interesting times)
I'm not saying thus must be added before 7.4, only that it's a to me safe method to add in a future version of Pile. As for 7.4 - sure. I should sit down and finish SDL (got distracted there...) this week.
/ David Hedbor (I live in interesting times)
Previous text:
2002-09-03 23:18: Subject: argv[0]?
I know of code that will break. That doesn't mean that I have a strong opinion in the matter. Let's get the Pikefarm up properly (we'll have a meeting end of this week to determine the shoppinglist for the last items we need) and get some green plupps and then we can open for more experimental work.
Speaking of the future; might this weekend be good to try release Pike 7.4?
/ Martin Nilsson (Fake Build Master)
Not ideal for me. I will be gone for at least saturday. I could probably clear up sunday.
/ Peter Bortas
Previous text:
2002-09-03 23:18: Subject: argv[0]?
I know of code that will break. That doesn't mean that I have a strong opinion in the matter. Let's get the Pikefarm up properly (we'll have a meeting end of this week to determine the shoppinglist for the last items we need) and get some green plupps and then we can open for more experimental work.
Speaking of the future; might this weekend be good to try release Pike 7.4?
/ Martin Nilsson (Fake Build Master)
So? That wasn't the function we were talking about. If a function can be implemented as a nop without breaking the programs that use it, such as the case would be for a "change argv[0]" function, then that does go some way towards making it less problematic, yes.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-03 23:13: Subject: argv[0]?
I seriously doubt the possibility to (perhaps) change the arg or display name in Unix would be hurtful, granted it was marked / documented correctly.
/ David Hedbor (I live in interesting times)
What method was being discussed then? Oh, daemonize. Long thread. Had to look back a bunch of levels to see that.
/ David Hedbor (I live in interesting times)
Previous text:
2002-09-03 23:22: Subject: argv[0]?
So? That wasn't the function we were talking about. If a function can be implemented as a nop without breaking the programs that use it, such as the case would be for a "change argv[0]" function, then that does go some way towards making it less problematic, yes.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Yeah. Changing the subject would make it too easy. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-03 23:25: Subject: argv[0]?
What method was being discussed then? Oh, daemonize. Long thread. Had to look back a bunch of levels to see that.
/ David Hedbor (I live in interesting times)
I think it's time for a timeout here. Like stop, take a deep breath and relax.
/ David Hedbor (I live in interesting times)
Previous text:
2002-09-03 22:57: Subject: argv[0]?
I guess I'm just not the one who should speak up - I never was good at talking with people, so screw it. To sum up - I just don't understand what a fucking harm can a function, module, class whatever do just by existing, that's it. If a feature doesn't bother anybody, and it pleases somebody else, is useful for them - it's enough of a reason for me to implement it. But I guess I'm just a dumbfuck.
/ Marek Habersack (Grendel)
I just don't understand what a fucking harm can a function, module, class whatever do just by existing, that's it.
This is the serious part... Imagine a function/module/class/language construct/whatever that does something useful, but in the wrong/non-generic/braindead way. Now give that function/module/class/language construct/whatever a really good and easily memorized name so that it is easy for newcomers to find it, even without reading the documentation.
I can give you an example. Let's introduce a top level function ls() that returns an array with lower cased file names of the files in the current working directory. This function will work great for all MS Windows programmers.
I'm sure you can come up with more interesting examples on your own.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-09-03 22:57: Subject: argv[0]?
I guess I'm just not the one who should speak up - I never was good at talking with people, so screw it. To sum up - I just don't understand what a fucking harm can a function, module, class whatever do just by existing, that's it. If a feature doesn't bother anybody, and it pleases somebody else, is useful for them - it's enough of a reason for me to implement it. But I guess I'm just a dumbfuck.
/ Marek Habersack (Grendel)
the solution is simple - implement it in a non-braindamaged, generic way. Don't make it easily accessible, make it harder to use - here's the cure for the itch.
/ Marek Habersack (Grendel)
Previous text:
2002-09-03 23:12: Subject: argv[0]?
I just don't understand what a fucking harm can a function, module, class whatever do just by existing, that's it.
This is the serious part... Imagine a function/module/class/language construct/whatever that does something useful, but in the wrong/non-generic/braindead way. Now give that function/module/class/language construct/whatever a really good and easily memorized name so that it is easy for newcomers to find it, even without reading the documentation.
I can give you an example. Let's introduce a top level function ls() that returns an array with lower cased file names of the files in the current working directory. This function will work great for all MS Windows programmers.
I'm sure you can come up with more interesting examples on your own.
/ Martin Nilsson (Fake Build Master)
Exactly. Nice to hear you are with us again.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-09-03 23:14: Subject: argv[0]?
the solution is simple - implement it in a non-braindamaged, generic way. Don't make it easily accessible, make it harder to use - here's the cure for the itch.
/ Marek Habersack (Grendel)
I begun with "move it", until someone pointed out the non-braindamaged genericness of the Process.create_process implementation.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-09-03 23:21: Subject: argv[0]?
so far I heard only the "remove, remove, remove" mantra, not "move it, make it less accessible" :P
/ Marek Habersack (Grendel)
pike-devel@lists.lysator.liu.se
-
David Hedbor (I live in interesting times) ＠ Pike (-) developers forum -
Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Marek Habersack (Grendel) ＠ Pike (-) developers forum
-
Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum