Process.daemonize() - Pike-devel

4 Sep 2002

      And another thing about discussions in KOM in general: it is often the
case that the debate or discussion itself runs amok just because some,
possibly several, person(s) start talking about philosophy, operating
systems behaviour or other somewhat unrelated topics rather than being
in disagreement about relevant facts.
I'm sure nobody would object about a Process.daemonize() call if you
or someone else who wanted it implemented it and tested it to work on
systems where this is possible, and disabled and documented this added
dependency on systems where it does not work. From what I have heard,
implementing a Process.daemonize call would require a syscall giving
an inverted fork(1) (to move along all threads), on systems with
threads, or be easy on systems without threads.
Arguing that someone else should write it will almost certainly fail,
implementing it on one's own will almost certainly succeed; doers
decide, except for the cases where there are loud vetos. Of course,
doers who show clear signs of disrespecting portability or other
important issues; typically by not disabling functions on systems
where they fail, failing to document such dependencies or naming the
methods in a manner suggesting universal portability.
There has not yet been loud vetos against a daemonize call, but Marcus
will not implement it, since he is fully satisfied with having the
setsid (IIRC) hack for the same purpose in Process.create_process. The
fact a daemonize call like this could be made in two different ways
from the Pike level is not something that unlikely to irritate anyone.
/ Johan Sundström (risplockare)
Previous text:
...
2002-09-03 18:40:
Subject: argv[0]?

...
Quite the opposite.  According to the UNIX philosophy, there should be
one program for each task that does that task well.  nohup performs
the task for daemonization.  So in a sense, _not_ using nohup is a
hack.  ;-)
You could argue that, yep :) - but nohup isn't necessary in this scenario
and, compared to other methods of daemonizing the program, it is a definite
hack.
...
You are relying on init to start getty, which you are relying on to
start your login shell, which you are relying on to start program.
yeah, that's the usual way. At least once in my life I had an installation
where my program was the only one started on the machine - instead of
init. And, frankly, except for the kernel there was nothing else but the
static program there.
...
Why would inserting nohup into this chain be a special case?
see above.
...
I.e. what makes
init -> getty -> sh -> nohup -> prog
so much different than
init -> getty -> sh -> prog
unnecessary dependence on the nohup presence.
...
?  In both cases you are relying on a number of "external programs".
This is what separates a real OS from a C64.
no, I'm not relying on init, to be honest :) - it's a part of the sequence,
but it is possible to avoid it, so it's not a strict relation.
...
...
When I exec a pike script and move it to the background and I don't
exec anything from inside it, then I'm not relying upon anything _during
the execution_ of the script.
Nor would you be relying upon nohup _during the execusion_, since
nohup just sets things up and then calls exec().  So when your
programs starts executing, nohup is already gone.
You're right, but I still don't consider this solution an elegant one.
/ Marek Habersack (Grendel)