On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell <gus...@nyvell.se> wrote:
> On 07/15/14 23:55, Philip Guenther wrote: > > On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell <gus...@nyvell.se > > wrote: > >> On 07/15/14 11:13, Peter Hessler wrote: >> >>> On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell >>> wrote: >>> :On 07/15/14 09:48, Philip Guenther wrote: >>> :>When the process that's executing your .xinitrc exits, startx/xinit >>> :>will shutdown the X server and then itself exit, taking you back to >>> :>the non-X shell prompt. Your .xinitrc should end with execution on >>> :>some program which will not exit until you want to exit X; many >>> :>people have it be their window manager. >>> :> >>> :>This is described in the startx(1) manpage: >>> :> The .xinitrc is typically a shell script which starts many >>> clients >>> :> according to the user's preference. When this shell script >>> exits, >>> :> startx kills the server and performs any other session >>> :>shutdown needed. >>> :> Most of the clients started by .xinitrc should be run in the >>> :> background. The last client should run in the foreground; when >>> it >>> :> exits, the session will exit. People often choose a session >>> :>manager, >>> :> window manager, or xterm as the ''magic'' client. >>> :> >>> :I know all of this. The problem is why does X lose .xinitrc when >>> :.xinitrc (ksh) forks. >>> : >>> >>> because the process you called stopped running. >>> >> It does not. If you mean daemon() I run it from inside a fork() so the >> main process never exits. You're making me uncertain so I will check this >> out better later. > > > So you're saying that the process that the .xinitrc ksh executes calls > fork() and the child of that fork() then calls daemon()? If so, what does > the *parent* of the fork(), the original process executed by ksh, do after > forking? It's child will exit from the daemon() call, so if it calls > wait() it won't block long. Then what? Exit? If so, you've created a > self-backgrounding process (in a very complicated fashion) which means it > cannot be the process that keeps the .xinitrc script from exiting. > > Hm, no, .xinitrc itself is the process that calls fork etc since it uses a > lib that does this. > > So let's try that question directly: what process (*not* program) > directly executed in the foreground by the .xinitrc script will run and not > exit until your X session is complete? The answer CANNOT be "the child of > this program which fork()s", because it is the original process which > matters. Nor can the answer be "this program which calls daemon()", > because the original process exits then too. > > Not a process in .xinitrc, .xinitrc itself. > I don't understand your answer. Since I apparently cannot guess what you're doing, I'll suggest that you show it, such as by simply including your complete .xinitrc. Philip Guenther
