Pike-devel

pike-devel@lists.lysator.liu.se

4 participants
3044 discussions

Start a nNew thread

Process.daemonize()
by Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

> an inverted fork(1) (to move along all threads), on systems with Oops, that should have been fork1(2).

1 0

argv[0]?
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

Yes. / Henrik Grubbström (Lysator) Previous text: >2002-09-03 20:14: >Subject: argv[0]? >-------------------------------------------------------------------- >so it would have to be an option passed to the interpreter, right? > > / Marek Habersack (Grendel) >

1 0

[Pike-devel] argv[0]?
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

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

6 19

argv[0]?
by Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

Just like that works fine. If you prefer, use <URL:http://...> instead (but it will probably not make more clients able to render clickable links; those who support links already find your URLs). / Johan Sundström (risplockare) Previous text: >2002-09-03 18:04: >Subject: argv[0]? >-------------------------------------------------------------------- >that's because linux-threads suck. The kernel implements the appropriate stuff >on the clone() level. Linux 2.6 is likely to use something else than >linux-threads - >http://oss.software.ibm.com/developerworks/opensource/pthreads/ > >(btw, how do I make the URI clickable by recipients on lyskom? :) > > / Marek Habersack (Grendel) >

1 0

[Pike-devel] Re: pike-devel@caudium.info
by Hedda (Tsar) ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

>ps: any way i can get the complete conference exported so that i can >read it? http://www.xnetz.com/pike-devel.txt (The side-text is in Swedish, but "Ärende" means "Subject", "Kommentar till" means "Comment to", and the rest of the Swedish is irrelevant.) Some texts are comments to texts outside the conference. / Hedda (Tsar) Previous text: >2002-09-03 21:06: >Subject: Re: pike-devel(a)caudium.info >-------------------------------------------------------------------- >On Tue, Sep 03, 2002 at 08:50:03PM +0200, Peter Bortas @ Pike developers forum wrote: >> You haven't asked. > >i HAVE asked!!!!!!! >noone answered!!!! > >on the pike list of course. >(because asking inside of lyskom for a mailinglist for it, >was a chicken end egg problem i did not manage to solve due to >a lack of understanding swedish) > >> *click* *click* There you go: >> http://lists.lysator.liu.se/mailman/listinfo/pike-devel > >excellent!!! >of course i prefer having the lists on lysator too. >hedda would you mind getting that set up? >we'll drop the lists on the caudium server as soon as it does. > >greetings, martin. >ps: any way i can get the complete conference exported so that i can read it? > > > / Brevbäraren >

5 16

[Pike-devel] argv[0]?
by Per Hedbor () ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

On the other hand, forking all threads is also a problem, since fork() in UNIX is mostly used to start a new process, that is, fork(); do_some_setup(); exec();, if you then have more than one thread running, things you Dont Expect(tm) can happen between those fork() and exec() calls.

2 1

[Pike-devel] argv[0]?
by Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

Pth is the default thread library on FreeBSD I think, and that seems to work just fine. / Fredrik (Naranek) Hubinette (Real Build Master) Previous text: >2002-08-29 22:24: >Subject: argv[0]? >-------------------------------------------------------------------- >what about plans for alternative threads implementations? Like pth, ngpth >etc.? > > / Marek Habersack (Grendel) >

3 8

[Pike-devel] argv[0]?
by Per Hedbor () ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

The same is true for read and write, but since the aioread/aiowrite calls are normally used in user-level threads, that's not really a problem. On the other hand, those functions are actually implemented using threads on many operating systems, thus seriously confusing the issue. :-)

2 3

[Pike-devel] Welcome to the "Pike-devel" mailing list
by Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

> If you forget your password, don't worry, you will receive a monthly > reminder telling you what all your lists.lysator.liu.se mailing list > passwords are I do worry. / Martin Nilsson (Fake Build Master) Previous text: >2002-09-03 21:22: >Subject: Welcome to the "Pike-devel" mailing list >-------------------------------------------------------------------- >Welcome to the Pike-devel(a)lists.lysator.liu.se mailing list! > >To post to this list, send your email to: > > pike-devel(a)lists.lysator.liu.se > >General information about the mailing list is at: > > http://lists.lysator.liu.se/mailman/listinfo/pike-devel > >If you ever want to unsubscribe or change your options (eg, switch to >or from digest mode, change your password, etc.), visit your >subscription page at: > > http://lists.lysator.liu.se/mailman/options/pike-devel/10353%40lyskom.lysat… > > >You can also make such adjustments via email by sending a message to: > > Pike-devel-request(a)lists.lysator.liu.se > >with the word `help' in the subject or body (don't include the >quotes), and you will get back a message with instructions. > >You must know your password to change your options (including changing >the password, itself) or to unsubscribe. It is: > > pike > >If you forget your password, don't worry, you will receive a monthly >reminder telling you what all your lists.lysator.liu.se mailing list >passwords are, and how to unsubscribe or change your options. There >is also a button on your options page that will email your current >password to you. > >You may also have your password mailed to you automatically off of the >Web page noted above. > > > / Brevbäraren >

3 3

[Pike-devel] the Pike module system
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 03 Sep '02

03 Sep '02

I don't see the point in providing site wide settings for this. Each Pike application might for some reason use a partially different namespace than the standard one. So let there be some method for it to define a namespace mapping, preferably only once and not in each source file. There might also be a reason for doing the mapping only once for a group of related applications. But doing it on a site wide level would mean that all pike applications on the site are treated as a single group (unless those that doesn't use the site wide pike installation, of course). That strikes me as a totally arbitrary grouping; I see no reason to expect that all applications that happen to be installed on a site should want to use the same nonstandard namespace. / Martin Stjernholm, Roxen IS Previous text: >2002-09-03 18:35: >Subject: the Pike module system >-------------------------------------------------------------------- > >>>that warning about clashes on the global level would be enough, but it >>>might be useful if Pike warned about method arguments and local variables >>>shadowing some global identifier. >> >>No. Not per default, maybe if supplying a flag, like -Wclobber. I >>quite often overload lfuns (which are present globally) and I don't >>want Pike to complain on that. >Yep, that makes sense, sure. > >>>>should themselfs make sure they contain all dependencies they need. As >>>>nilsson said earlier, it would not be fun to every now and then get >>>>complaints to pike fora that certain programs fail miserably, just >>>I'm sorry, but I don't understand this argument. The impression I get is >>>that you (plural) are promoting a language that is to resolve all the >>>user's problems and, IMHO (and some people I talked to about the issue) >>>Pike should stay a general purpose language that gives its users maximum >>>flexibility in choosing the ways to solve one problem. As I said - the >>>autoloading _feature_ would be fully under the control of the site >>>administrator or the individual user - no upstream default autoloads, >>>nothing like that. Why would such a _feature_ be bad? >> >>There is nothing bad as such to the feature (other than that it's >>redundant in some sense). The problem is that given such a feature >It is very useful for site-wide policy setting - we've just talked about it >on IRC, people seem to like the idea and find it useful. > >>programmers will start writing code depending on autoloaded modules, >that's ok, as long as it is a site policy. Pike docs should describe only >the autoload feature, not that any modules are available through it. Don't >assume all users are dummies. > >>or that certain compatability code has been run, etc. In doing so, the >>will make sure the program won't work unless that code has been >again, it's ok if it is a site-wide policy. Change the scale of your point >of view - look at it from the site standpoint, not from the language >implementor's standpoint. > >>run. The most common user will, when a script fails, not ask the >>administrator, but rather ask in relevant Pike fora, just to make the >>people in those fora reply "go blame your system administrator", and >That's what FAQ is for... Also, I assume that people will read docs - they >should stress that relying on any modules being autoloaded is WRONG. > >>pike will get bad karma since people then find the people in pike fora >>unfriendly and non-helpful. I don't want this to happen. The good >oh, come on! What kind of bad karma if the docs make things clear? > >>thing with Pike is that it's a portable envirnoment in which you can >>be sure that the program works, given that the dependincies made >>explicitly in your code are met. These explicit dependencies will be >>even easier to trace given a hierarcical third party module tree with >>clear delegations -- and people on the lists can give the more >>informative answer: Check the pike module repository for that and that >>module, install it and it will work. >> >>Anything unclear in that? >No, it's perfectly clear, but I've got a feeling that I didn't make myself >clear enough. This is only a feature, not a way to free users from checking >whether the module they need is loaded, that's first. Second, pike loads >the modules on demand - your hypothetical situation will have no place, >because if some module isn't auto-loaded, it will be loaded when the user >accesses it for the first time. Third, the autoload feature is good for >setting up some kind of widely understood environment - setting some >site-specific variables, setting up security contexts etc.; Fourth, the >autoload feature might be used by the site administrator to show some >motd-like thing (a stupid example made up ad hoc :)) > >>>Let me give you one ad-hoc example - what if the administrator was >>>able to autoload a simple module, loaded each time pike is used, which >>>would set the default security settings? Resource limits, pike security - >>>anything? >> >>That's really nothing that should be done in Pike, especially since >>a user can upload his own pike to the system and easily circumvent >>such things. >Come on, that can be avoided _easily_ by a half-experienced programmer and >is really of no importance here. And pike-security cannot be set up outside >of the pike context. > >>No, to be honest, I don't see any use for your autoload feature. >>Especially if the hierarcical delegated module system becomes a >>reality. If any module is moved within the base modules of pike, that >>should be reflected in the current compatability system. >Compatibility should be thrown away at some point, otherwise it doesn't >make sense to introduce improvements. > > / Marek Habersack (Grendel) >

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel