RE: oninit -i -y from PHP - cannot detect that command have exited

On Fri, 16 Jun 2000, Andrej Falout wrote: >Jonathan Leffler wrote: >> Andrej Falout wrote: >> > This little saga have to do with IDS (7.3 LE) oninit command, when >> > executed from PHP code using exec() or system() >> [...snip discussion of merits of running oninit -i -y in web service...] > >> > Problem is, when PHP executes oninit like this, oninit runs fine, I >> > can see my db space being created, but PHP just hangs there waiting >> > for command to return to PHP, and it never does. >> >> Maybe oninit looks at some environmental factors (such as "is stdin, >> stdout or stderr a terminal; if so, I need to do a forking start, but >> otherwise I don't") > >No, oninit works without any problems. It successfully builds root >space. I didn't say anything about it not working. I was implying that oninit might not terminate under some environmental conditions which are different inside PHP running as some part of the Apache web server compared with the environmental conditions which apply when you manually run a program at the command line. Daemons can be stroppy processes, and unless you know a lot about the way they are written, it can be difficult to decide what it will do. For example, a daemon can decide that since at least one of stdin, stdout and stderr is a terminal, then some user ran oninit from the command line and wants the initial daemon process to exit so the user can get on with life. However, if none of the standard channels is a terminal, it can decide that some specialized script ran it and that the initial process doesn't need to exit. Other daemons can decide to always do a fork with the parent process exiting. Such daemons might or might not process their configuration files and otherwise startup before the parent process exits. So, one typical sequence of events is that you get output from a daemon such as: $ daemon; echo $?0 $ cannot read configuration file /usr/daemon/configexiting The daemon indicated success (meaning it successfully forked and the parent died without problems), but the main part of the daemon (the forked child) really didn't get around to doing anything useful. >If I run my script, root space will be built, and engine will be left >in on-line mode. That I believe. >Script will exit, Are you sure? How do you know? >... but PHP will not resume control. If >I at that moment go to terminal window, and a) shutdown this engine, >or b) just kill ALL oninit processes on the box, PHP WILL IMMEDIATELY >RESUME CONTROL FROM THE SHELL SCRIPT OUTPUT FROM PHP TO THE BROWSER >WILL IMMEDIATELY CONTINUE. > >Apparently, PHP exec() is monitoring what is started/forked/spawned >with it, and if it see any of this processes running when command >exits, it assumes command is not done. This I doubt. There isn't a reliable way to find that information out on Unix, so unless there's something weird about your environment, I am confident this does not happen. >> I'd hypothesize that at the point when exec or system doesn't return, >> it is because oninit has not exited. That's more likely than a >> breakage in PHP. > >It is, and I agree, but why does PHP care about it? Well, PHP cares because it was told to. You said "wait for the command to finish and then get back to me". If the command doesn't finish, then of course PHP can't get back to you. >In my view, it should care just about the command that was launched >with it, and if it is an shell script or whatever, what goes one in >there should not be of PHP's interest? Correct. But if the command that was launched doesn't exit, there's not much PHP can do. >> Try running the script with i/o redirection: >> >> script >/dev/null < /dev/null 2>&1 > >slash/back-slash/left-curly-bracket/dot/man/this/su***/ > >When will I understand what is going on here? Now if you can answer >THAT! :-) Well, the '>/dev/null' sends standard output to /dev/null. The '< /dev/null' (the space is basically a typo but does no damage) makes standard input come from /dev/null. And the '2>&1' is Bourne/Korn/Posix shell notation for send stderr (2) to the same place as stdout (1). I could equivalently have written '2>/dev/null'. >Of course, you are right, again, it works fine, and I am very grateful. And I'm lucky. >It was enough to change just oninit line in my shell script to: > >oninit >/dev/null < /dev/null 2>&1 My turn to be baffled; I expected that to mean that oninit would not exit. Oh well, at least you're up and running. Some time, we could investigate exactly what i/o channels PHP left open when the oninit did and did not work. And we could monitor exactly which process the PHP created (forked) and then use ps to establish that said process did not exit when PHP got hung up. -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"