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

Thu Apr 8 10:14:27 UTC 2010

Antoine Martin <antoine at nagafix.co.uk> wrote on 07/04/2010 22:40:00:

[snip]

> > To emulate synchronous launching, a delay must be introduced.
> Well spotted! I had hit this bug too.
> Generally happened when I was doing a well rehearsed demo.. ;)
> 
> The solution that I have used successfully (and is also used in neatx)
> is to watch the output of the nxagent process: once the line saying
> "Waiting for connection from ..." shows up, you can be certain that the
> socket is ready.
> I have also previously used a tcp-connect loop (with a 1 second
> timeout), but the log parsing is both quicker and more proper.
> 
> The "sleep 4" that you have added may work in most cases,

It will work unless the machine is maxed out . . .

> but you can't
> guarantee that it is the correct delay.

No ! it will only do for about 99.99% of first logins after a reboot.

> Too short and it causes the
> aforementioned bug, too long is also problematic as it slows down
> session startup unnecessarily. (4 extra seconds is pretty long when you
> don't actually need it in most cases)

No one will notice !!

<Snip>

> 
> My 2p
> Cheers
> Antoine
> 

So we differ.

Here is my view.

I am concerned with live systems staying live.

I am unconcerned with log in times of 8 seconds ( which
is the time my machines take ).

I want a fix that can be understood by people who can't solve
the problem for themselves, that is to say ordinary users.

I want something that they can type in easily without making
mistakes.

I want something which will will be benign in the event  a 
mistake is make ie. no unterminated loops or "

I want minimum intervention patching, following the coding 
style used by the original developer, right or wrong (which
is of course standard practice throughout the industry).

More elegant and quicker solutions are for the maintainers
to include for thorough testing in the next version, after a
complete review of the surrounding code and associated
algorithms.

Your solution is to write a new product, which is perfectly
valid and of course I wish you good luck.

But that won't help an overworked and underpaid systems 
manager supporting for a charity, who is getting flak about a 
system which appears cronky or badly configured and is 
giving a shaky "user experience" to that senior manager 
who is always first in the office on the monday after reboot
sunday, and views things like this as a test of competence
or feels he needs to push people along . . .

Antoine, did you send me an out of band email a bit back
asking about printing ??

There was a thread going about cups re-direction for a
bit, but I've been a bit too busy since December to bother
with anything else, and NX printing is a bit of a convoluted
pass the parcel.

If you are writing a new application with a new CLIENT
then you can do what you want and don't have to follow
the nomachine client.

Looking back at the thread though , my advice is still
to run the userland cupsd on the NX server, so all sessions
are the same regardless, and to spool postcript as far
along the line as you can if you are using a non postscript
printer rather than having the .ppd on the NX server
and spooling raster down a remote link.

Whatever you do . . .

. . . the main userbase will stay with FreeNX, because
it works OK, and almost no organisations will gain 
overall benefit from the cost of a project to move
to one of the other new nxagent launchers 
( whichis what FreeNX is, though it does also aim
 to pass ipp and samba printing and samba drive
mapping over the link).

I don't see there is much demand for remote printing
especially to windows work stations, though I use it 
quite a bit to put ooo-writer on remote XP with local
USB printers and mapped drives.

The truisms are :-

99% of the work on any of these projects has been
done by Nomachine, building and maintaining the 
libraries, nxagent

and 

the client software, which deals with all the caching
on the workstation and provides an X server for 
windows.

In adition there is ssh/sshd doing the encrypted link.

All the other stuff runs once at login, again at logout
and is irrelevant during the operation session.

cb

> > 
__
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEAREKAAYFAku8+68ACgkQGK2zHPGK1rtW9wCfezKY/yCoTMpOtQ2d55DJZx0l
> 758An3on5jn6B4IRGitCPDVAdDKl4j4N
> =U1L/
> -----END PGP SIGNATURE-----
> ________________________________________________________________
>      Were you helped on this list with your FreeNX problem?
>     Then please write up the solution in the FreeNX Wiki/FAQ:
> 
> 
http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ
> 
>          Don't forget to check the NX Knowledge Base:
>                  http://www.nomachine.com/kb/ 
> 
> ________________________________________________________________
>        FreeNX-kNX mailing list --- FreeNX-kNX at kde.org
>       https://mail.kde.org/mailman/listinfo/freenx-knx
> ________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20100408/95097350/attachment.html>