[FreeNX-kNX] A Fix for the problem of multiple attempts needed to login to FreeNX after a re-boot

[chris at ccburton.com]

Some people are reporting having to make several attempts
to login to FreeNX after a server re-boot, before the first
successful login takes place.

After this, things are reported as being fine, until the next
OS restart.
( I'm not sure that this is the full picture, as I'll explain )


I've had a run through the code, and watched some startups
Here's what I see happening.


For a new session, FreeNX runs the nxagent in the 
background from an instance of nxnode 
( node_start_agent & )
 
 . . then immediately . .

runs what it calls "The Application", also in the background,
( node_start_applications & )

The Application can be "startkde" ( or whatever ) for a
desktop session, or a user application eg. ooo-writer
for a rootless session.

Before starting kde, the script runs xrdb -merge which
is normally launched as part of the X client, startx etc. 


This is causing a problem, because the xrdb and the
application, kde ( for example ) are starting before
the display port is open, failing, and terminating the
whole FreeNx session, including the agent.

The reason for this failure is that the script takes 
some time to launch nxagent, and then nxagent takes
some time to load its shared libraries, the first time
it is run.

These libraries stay in memory, unless thay are flushed
out, so subsequent logins are quicker and don't fail.


This is why I say I don't think that the re-boot senario
is the whole picture.

In fact, I expect that a machine also used for other tasks
will, if there is no FreeNX activity, revert to the 
"multiple login attempts required" state, due to other
jobs causing unused shared libraries to be flushed out
of memory.

No one has reported this however.

I also expect that xrdb fails quite often.

It is subsequently run if needed by the kde session after
it is started, and it is possible that things have only been
working up to now because of the delay caused by 
the launching of xrdb.

Note.

The reason it takes several runs to complete is that although
the nxagent is terminated after part loading its libraries, any
libraries which have been loaded are available for the next
attempt, which can therefore get a little nearer to completion.

After a few tries, they are all in memory, and no more
issues.


The fix is very simple.

The rule is very golden.

When backgrounding a script to launch something upon which
something else depends, bear in mind that the the script launch
will return straight away, then continue with the load. 

To emulate synchronous launching, a delay must be introduced.



Patch for nxnode 0.7.3

Watch out for line wraps messing up the diff.

It will probably be easier to look for xrdb -merge in an editor
and add the sleep.

--- nxnode.orig 2008-11-28 12:18:13.000000000 +0000
+++ nxnode.mod  2010-04-07 14:44:18.000000000 +0100
@@ -328,6 +328,9 @@
                NODE_WM_PID=$!
        fi

+       # Patch - delay to allow nxagent to complete lauching. ccb 
20100407
+       sleep 4
+
        echo "Xft.dpi: 96" | DISPLAY=:$display xrdb -merge 
>>"$USER_FAKE_HOME/.nx/C-$sess_id/session" 2>&1
        [ -d /etc/X11/Xresources ] && xrdb -display :$display -merge 
/etc/X11/Xresources/* >>"$USER_FAKE_HOME/.nx/C-$sess_id/session" 2>&1



If this works for you, please let us know so the next 
people with this problem have some idea if it is a fix
for them or not !!

If it doesn't work I'm sure you will say something!!


cb













-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20100407/98a85a87/attachment.html>