IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 22 February 2013   (all times are UTC)

00:03
<enslaver>
*cough*initramfs*cough*
00:03
<Phantomas>
enslaver: ListOf was introduced in 10.0 :-\
00:04
<enslaver>
k i'll build new rpms
00:05
11.0.0
00:05
<Phantomas>
of twisted?
00:05
<enslaver>
yes
00:06
python-twisted-core-11.0.0-3.el6.x86_64.rpm done
00:10
now its working much better
00:11
<Phantomas>
vagrantc: btw, should we specify a version number for python-twisted-core in debian/control or not?
00:12
enslaver: does it open?
00:12
<vagrantc>
Phantomas: only needed by debian policy if the version was not present in any current debian release ...
00:12
<enslaver>
An error occurred while connecting: 2: No such file or directory.
00:12
that might be my issue though
00:12
<vagrantc>
enslaver: squeeze has 10.0
00:12
<Phantomas>
the socket wasn't created
00:12
<vagrantc>
Phantomas: er, 10.1 ...
00:13
<Phantomas>
vagrantc: so we're fine! Good :)
00:13
<vagrantc>
Phantomas: though documenting minimum versions somewhere "upstream" might be a good idea.
00:13
<enslaver>
son of a ...
00:14
accidentally deleted my ssh keys
00:14
<Phantomas>
enslaver: is the epoptes daemon running?
00:14
ouch
00:14
<enslaver>
daemon?
00:14
:)
00:16
File "/usr/lib64/python2.6/site-packages/twisted/lore/scripts/lore.py", line 10, in <module>
00:16
from twisted.python import usage, plugin as oldplugin, reflect
00:16
when starting daemon
00:17
<Phantomas>
can you pastebin the full traceback?
00:17
<enslaver>
sure
00:17
<Phantomas>
how do you start the daemon?
00:18
<enslaver>
/etc/init.d/epoptes is the init
00:18
err epoptes-server
00:18
/usr/bin/twistd --pidfile /var/run/epoptes.pid --logfile /var/log/epoptes.log epoptes
00:19
<Phantomas>
sounds good
00:19
<enslaver>
well, i just ran epoptes and it came up
00:19
so the daemon may have started, just with error
00:20
http://pastebin.com/X4hFhYBX
00:20
<Phantomas>
yep, it seems so.
00:25
enslaver: python-twisted-bin version?
00:26
<enslaver>
I think the issue is my python-twisted-lore is still 8.2.0
00:26
actually python-twisted everything is still 8.2
00:26
except the core
00:27
i'll play with it later, I'm headed home from work
00:27
http://mirror.ancl.hawaii.edu/~k12linux/rpm/el6/x86_64/
00:27
stuck some rpms there
00:27
I just gotta add requires > python-twisted 9
00:27
err 10
00:28
see you all in a bit
00:30Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 255 seconds)
00:32Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
00:33* Phantomas wants FTTH
00:34
<Phantomas>
enslaver: try to completely uninstall python-twisted-lore (if you don't need it)
00:34
I don't have it
00:34
or upgrade it as you said
00:34
thanks for your packages ;)
00:36* Phantomas falls into sleep mode! It's 02:36 AM *gallons* here! :P
00:36Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
00:47Gremble has left IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com, Quit: I Leave)
01:04stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Quit: kernel update)
01:06Da-Geek has joined IRC (Da-Geek!~Da-Geek@p1040-ipad84marunouchi.tokyo.ocn.ne.jp)
01:14stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
01:24vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
01:42hays has joined IRC (hays!~quassel@unaffiliated/hays)
01:46hays_ has left IRC (hays_!~quassel@unaffiliated/hays, Ping timeout: 276 seconds)
01:49enslaver has left IRC (enslaver!~enslaver@c-98-196-42-169.hsd1.tx.comcast.net, Ping timeout: 264 seconds)
02:09adrianorg__ has left IRC (adrianorg__!~adrianorg@177.134.59.247, Ping timeout: 240 seconds)
02:16monteslu__ has joined IRC (monteslu__!~monteslu@ip68-109-174-213.ph.ph.cox.net)
02:19monteslu_ has left IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 260 seconds)
03:03elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, Ping timeout: 252 seconds)
03:03elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi)
03:49Parker955_Away is now known as Parker955
03:57alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:57
<alkisg>
'morning :)
04:01
sbalneav: any progress on the LDM/SSHFS issue?
04:03
<sbalneav>
alkisg: have looked a bit. It will take me some time.
04:03
right at the moment, I'm fiddling with libpam-sshauth...
04:05
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/libpam-sshauth/revision/76
04:05
<alkisg>
sbalneav: I'm just worried because of the data loss issues involved (had numerous reports from schools already)... I could probably do the xsetioerrorhandler() thing myself today, but not the daemonize stuff... is that necessary?
04:09
<sbalneav>
Don't know what I can tell you. I haven't had a chance to fully read through everything. Much has changed in the code since I last looked at it, so it will take me some time. I'm certainly not going to promise I'll be able to get a fix out within a day.
04:23Enslaver has joined IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net)
04:29Parker955 is now known as Parker955_Away
04:44alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
04:45alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
04:45alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
04:57sha has left IRC (sha!~sha@e177116104.adsl.alicedsl.de, Read error: Operation timed out)
05:00sha has joined IRC (sha!~sha@e177119135.adsl.alicedsl.de)
05:10vnc786 has left IRC (vnc786!~chatzilla@49.248.129.178)
05:11staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 255 seconds)
05:19work_alkisg is now known as alkisg
05:29F-GT has left IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net, Ping timeout: 252 seconds)
06:28anunnaki has left IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net, Remote host closed the connection)
06:28anunnaki has joined IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net)
06:47komunista has joined IRC (komunista!~slavko@adsl-195-168-244-224.dynamic.nextra.sk)
07:09vmlintu has joined IRC (vmlintu!~vmlintu@cs181214103.pp.htv.fi)
07:27
<Enslaver>
ok lets try more epoptes
07:28khildin has joined IRC (khildin!~khildin@ip-80-236-193-140.dsl.scarlet.be)
07:35komunista has left IRC (komunista!~slavko@adsl-195-168-244-224.dynamic.nextra.sk, Quit: Leaving.)
07:39
<Enslaver>
any epopteians around?
07:41
<knipwim>
usually alkisg and Phantomas
07:41dobber_ has joined IRC (dobber_!~dobber@89.190.199.210)
07:41
<knipwim>
Enslaver: btw, your 04-server also works for me
07:41
<Enslaver>
Phantomas was helping earlier, we almost had it going
07:41
knip: the 04-server?
07:41
<knipwim>
for LTSP, in the init-ltsp.d ?
07:41
<Enslaver>
knip: i dont think i changed it that much
07:42
<knipwim>
the one with the =~ rofs
07:42
<Enslaver>
oh
07:42komunista has joined IRC (komunista!~slavko@adsl-195-168-244-224.dynamic.nextra.sk)
07:42
<Enslaver>
yeah i changed that to echo $MOUNTPOINT|grep rofs to make it posix compliant :/
07:42
<knipwim>
Enslaver: perhaps i can help with the install of epoptes, i recently went through that for gentoo
07:43
cool
07:43
<Enslaver>
knip: you're exactly what i need then :)
07:43
<knipwim>
and also glad you didn't get fired
07:43
<Enslaver>
i'm just packaging it for el6
07:43
the main problem thus far is that the python-twisted in el6 is version 8
07:43
i got python-twisted core to 11 but the other parts are still 8
07:43
so its taking it 1 by 1
07:45
<knipwim>
do they matter? gentoo depends on dev-python/twisted in general, no specific version
07:45
lowest version is 10.2 btw
07:46
<Enslaver>
yah
07:47
gentoo, ubuntu and everything else comes with 10.2
07:47
trying to find python-twisted 11 rpms
07:49
<knipwim>
so, you actually need a specific version
07:52
<Enslaver>
no, just anything above 10 i guess
07:54
my python experience is 0
07:54
<knipwim>
and you can't use fedora packages?
07:55
<Enslaver>
tried
07:56
i ported it based on that though
08:01
File "/usr/lib64/python2.6/site-packages/twisted/__init__.py", line 51, in _checkRequirements
08:01
raise ImportError(required + ".")
08:01
ImportError: Twisted requires zope.interface 3.6.0 or later.
08:06
but i have python-zope-interface4-4.0.2-7.el6.x86_64
08:08
past that, now cant find twistedzoc
08:14khildin has left IRC (khildin!~khildin@ip-80-236-193-140.dsl.scarlet.be, Remote host closed the connection)
08:29markakis has joined IRC (markakis!51ba3179@gateway/web/freenode/ip.81.186.49.121)
08:39mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
08:39komunista has left IRC (komunista!~slavko@adsl-195-168-244-224.dynamic.nextra.sk, Read error: Operation timed out)
08:42shogunx has left IRC (shogunx!~shogunx@2001:4978:106:1:a0ad:1413:495f:600, Ping timeout: 240 seconds)
08:55shogunx has joined IRC (shogunx!~shogunx@2001:4978:106:1:e596:27a9:7e4b:acad)
08:59Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
09:02meamy has joined IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de)
09:16garymc has joined IRC (garymc!~chatzilla@host81-148-18-165.in-addr.btopenworld.com)
09:21komunista has joined IRC (komunista!~slavko@87.244.209.244)
09:32F-GT has joined IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net)
09:50adrianorg__ has joined IRC (adrianorg__!~adrianorg@177.156.58.168)
10:08Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com)
10:10Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
10:12Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Read error: Operation timed out)
10:12Phantomas1 is now known as Phantomas
10:22Enslaver has left IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net, Ping timeout: 252 seconds)
10:36markakis has left IRC (markakis!51ba3179@gateway/web/freenode/ip.81.186.49.121, Ping timeout: 245 seconds)
10:59
<alkisg>
!socat
10:59
<ltsp>
socat: One way to share a console with a remote person is: [local pc] forward port 5500, run: socat tcp-listen:5500,keepalive=1 stdio,raw,echo=0 [remote pc] socat tcp:server:5500 SYSTEM:"{ sleep 1; xterm -e screen -xRR ra$$; } & exec screen -S ra$$",pty,stderr
11:05Enslaver has joined IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net)
11:09markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)
11:12alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
11:13alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
11:14Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
11:16alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Client Quit)
11:16alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
11:36baptiste_ has joined IRC (baptiste_!baptiste@paul-sud.asso.ups-tlse.fr)
11:37baptiste has left IRC (baptiste!baptiste@paul-sud.asso.ups-tlse.fr, Read error: Connection reset by peer)
11:40komunista has left IRC (komunista!~slavko@87.244.209.244, Quit: Leaving.)
11:44alkisg is now known as work_alkisg
11:45komunista has joined IRC (komunista!~slavko@87.244.209.244)
11:51udayb has joined IRC (udayb!~udayb@117.219.244.94)
11:59udayb has left IRC (udayb!~udayb@117.219.244.94, Ping timeout: 255 seconds)
12:09komunista has left IRC (komunista!~slavko@87.244.209.244, Quit: Leaving.)
12:18anunnaki has left IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net, Ping timeout: 264 seconds)
12:19anunnaki has joined IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net)
12:26Tatanka has joined IRC (Tatanka!~tim@revue.vtk.be)
12:29meamy has left IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de, Quit: meamy)
12:43udaybhatye has joined IRC (udaybhatye!~udayb@117.219.242.200)
12:43
<udaybhatye>
error trying to compile ltspfs-trunk
12:43
configure.ac:6: error: 'AM_CONFIG_HEADER': this macro is obsolete.
12:45
I'm trying to get ltsp up in arch linux
12:45udaybhatye has left IRC (udaybhatye!~udayb@117.219.242.200, Client Quit)
13:16alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:19vnc786 has joined IRC (vnc786!~chatzilla@49.248.129.178)
13:25meamy has joined IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de)
13:50monteslu__ is now known as monteslu
13:50baptiste_ has left IRC (baptiste_!baptiste@paul-sud.asso.ups-tlse.fr, Read error: Operation timed out)
13:52baptiste has joined IRC (baptiste!baptiste@paul-sud.asso.ups-tlse.fr)
14:08Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:15komunista has joined IRC (komunista!~slavko@87.244.209.121)
14:21vmlintu has left IRC (vmlintu!~vmlintu@cs181214103.pp.htv.fi, Ping timeout: 255 seconds)
14:39Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:39Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:57jammcq has joined IRC (jammcq!~jam@c-69-245-75-255.hsd1.mi.comcast.net)
14:57
<sbalneav>
jammcq!!!!!!!!!!
14:57
<jammcq>
heh
14:57
sbalneav: Scotty !!!!!!!!!!!!!!!!!!!!!!!!
14:57
you beat me to it
14:57
<sbalneav>
It doesn't happen often.
14:57
So, I was thinking last night...
14:58
<jammcq>
yessssss
14:58
<sbalneav>
maybe we can solve alkisg's problem simply.... atexit(3)
14:58
<alkisg>
sbalneav: from my experience, atexit() doesn't get called when one presses e.g. ctrl+c
14:58
Btw hi guys :)
14:59
<sbalneav>
Rather than making the shutdown code part of the mainline, just register an atexit handler.
14:59
<jammcq>
atexit - register a function to be called at normal process termination
14:59
atexit - register a function to be called at normal process termination
14:59
oops
14:59
notice: 'normal process termination'
14:59
<sbalneav>
right, but if we trap the signal, and as part of the trap, just call "exit", wouldn't that work?
15:00
<alkisg>
sbalneav: in #xorg, they suggested this one: http://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html
15:00
<jammcq>
what's the point of atexit then?
15:01
<sbalneav>
alkisg: The only problem is: at no time does ldm currently have the display open.
15:02
<jammcq>
it's the greeter than opens the display, right?
15:02
the greeter, being a separate process
15:02* jammcq is just guessing
15:02
<alkisg>
sbalneav: are you referring to the save/restore the environment problem that I committed some shell scripts to bypass?
15:02
I think the best way is to send a signal to the child process, `ldm-script xsession`
15:03
That process would have a trap itself
15:03
So upon receiving e.g. SIGKILL, it would run `ldm-script stop`
15:03
With the current environment, containing DISPLAY, SSH_HOME and everything
15:04
<sbalneav>
in order to receive X errors, it has to be listening to the X display's event queue. Currently, ldm doesn't.
15:04
<alkisg>
What I'm worried about is if Xorg only waits for a few msec after sending its children the TERM signal, before forcefully killing all of them, i.e. LDM too
15:04
Ah, gotcha
15:04
<sbalneav>
I'll test the atexit event handler today.
15:04
<alkisg>
But Xorg will send its children a KILL signal nonetheless, right?
15:05
<jammcq>
why do you care about X errors. if LDM is a child of xinit, won't LDM receive a SIGKILL ?
15:05
<alkisg>
Whether they have open displays or not...
15:05
<sbalneav>
I'm not sure if it receives SIGKILL or SIGTERM.
15:05
<alkisg>
What's the equivalent of `trap command TERM KILL` in glib/C ?
15:05
<jammcq>
are they both catchable?
15:05
<sbalneav>
Kill isn't
15:05
<alkisg>
Maybe SEGV is sent on xorg crashes too?
15:06
<jammcq>
alkisg: man signal
15:06
<alkisg>
(we'd like to catch those as well, if at all possible)
15:06
<jammcq>
it shows how to setup a sighandler
15:06
<sbalneav>
bbiab, workping
15:07
<alkisg>
In other cases, I saw that the master process first sends SIGTERM to all of its children, waits for just a bit, and then sends SIGKILL
15:07
If xorg does the same, I hope we have enough time to run the cleanup scripts...
15:07
Otherwise we'd have to setup the ssh connection "outside" of X
15:07
<jammcq>
it's not xorg that does it. I think the kernel does it
15:08
when the leader of a "process group" dies, the kernel signals all the children in the same process gorup
15:08
<alkisg>
Ah, I thought that xorg had an error handler to write the backtrace etc that took care of all that
15:08
<jammcq>
well... it could
15:09
but it probably still leaves the signalling of the children up to the kernel
15:09* alkisg wishes he spent his youth learning glib instead of windows api... soooo much unusable knowledge :-/
15:09
<jammcq>
heh
15:09
i'm just a bit rusty with it but I used to do this sort of stuff all the time
15:12khildin has joined IRC (khildin!~khildin@ip-80-236-193-140.dsl.scarlet.be)
15:32staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
15:41Gremble has left IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com, Quit: I Leave)
15:42Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com)
15:44Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com)
15:47staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Quit: Leaving)
15:47staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
15:50Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 264 seconds)
15:53Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
16:04meamy has left IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de, Quit: meamy)
16:18FidemTurbare has joined IRC (FidemTurbare!~LumberCar@96.53.47.42)
16:33Ismael1 has joined IRC (Ismael1!~ismael@wldin04-103.tpa.net.br)
16:42FidemTurbare has left IRC (FidemTurbare!~LumberCar@96.53.47.42)
16:43dobber_ has left IRC (dobber_!~dobber@89.190.199.210, Remote host closed the connection)
16:44alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
16:57
<markit>
anyone here sets a more reasonable value of swappiness for fat clients in chroot?
16:58vagrantc has joined IRC (vagrantc!~vagrant@c-98-232-129-196.hsd1.or.comcast.net)
16:58vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
17:20JesseC has left IRC (JesseC!~JesseCWor@wsip-98-175-20-126.br.br.cox.net, Ping timeout: 244 seconds)
17:26vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
17:27markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, )
17:42garymc has left IRC (garymc!~chatzilla@host81-148-18-165.in-addr.btopenworld.com, Ping timeout: 240 seconds)
17:46dievel has left IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it, Quit: Leaving)
18:21adrianorg__ has left IRC (adrianorg__!~adrianorg@177.156.58.168, Ping timeout: 244 seconds)
18:28[conrad] has joined IRC ([conrad]!~mrice@rrcs-70-62-71-144.midsouth.biz.rr.com)
18:34Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
18:36adrianorg__ has joined IRC (adrianorg__!~adrianorg@177.156.58.168)
18:43adrianorg__ has left IRC (adrianorg__!~adrianorg@177.156.58.168, Ping timeout: 248 seconds)
19:06
<[conrad]>
We're using the LTSP bundled with Ubuntu 12.04 in an environment that's made up of thin clients only on a gigabit network.
19:06
Server specs: 4 x Quad-Core AMD Opteron(tm) Processor 8360 SE ( 16 total cores ), 64GB RAM, 4 x 2 TB RAID 10
19:06
Server load average: 0.28, 0.48, 0.52 ( are tests are currently with just 2-3 clients connected, so it's well underutilized ).
19:06
Client specs: Dell XPS 410's. Core 2 Duo's, 4GB RAM. Overkill for thin I know, but we thought the gigabit NIC might bring a resolution to some of these problems.
19:06
Client apps: Skype, Eclipse, Firefox ( though we really need Chrome to run better ), gedit, and Nautilus for basic file exploration.
19:06
I'm noticing even with LDM_DIRECTX equal to true, that I'm seeing some pretty bad performance on some somewhat basic applications. Google Chrome in particular. It's to a point where Firefox is being used as a substitute because there are no real issues when using Firefox in the sense of browsing, but we need some of the features built into Chrome. To be more specific in Google Chrome, when opening a new tab, sometimes it's a second or
19:06
two before the tab draws open, and if you're in the habit of being a quick typer and starting to type immediately after ctrl+t'ing, you'll find sometimes your first few characters are missed. Additionally, page that require scrolling, when scrolling, do so very "clunky". Firefox doesn't have either of these issues.
19:06
We've considered NIC bonding when we were testing with 8-10 clients, but even when we had that, netperf was showing that there was still a ton of network resources available. We took it down to two just to eliminate the network as a potential bottleneck.
19:06
I've tried Googling around, but I can't seem to find much on the topic. Does anyone know of anything else that could help increase performance of this setup?
19:11
Also, we're using Gnome with no effects.
19:13
<muppis>
What GPU do you got in clients? Shouldn't be the case, but to make sure.
19:17
<warren>
[conrad]: browser as local app or remote?
19:17alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.12.47)
19:19alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds)
19:25Ismael1 has left IRC (Ismael1!~ismael@wldin04-103.tpa.net.br, Quit: Leaving.)
19:28alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
19:35
<[conrad]>
muppis: 256MB Nvidia GeForce 7900 GS
19:35
warren: the problem exists with both.
19:37
<muppis>
Quite old. noveau or nvidia module?
19:41
<alkisg>
...why not fats?!
19:41
<muppis>
That's a good point.
19:42
4GB of RAM is more than enough to run fat.
19:43
<warren>
phat clients, the hip new rebranding
19:44
<[conrad]>
It is enough to run fat, but again that's not what we're looking for. The only reason machines with this much resources are being used was to prove that the problem wasn't with the resources.
19:46
The 8-10 machines that are designated for this have far less resources. I guess my point is this problem exists regardless of the resources available on the thin client. Even with LDM_DIRECTX equal to true we're experiencing these problems. When we were researching LTSP we saw several examples on the site of 50-100 thin clients, and given that all of them at a minimum must be using a web browser, I feel as though there might be some ad
19:46
justment that's able to be made.
19:47
<warren>
[conrad]: minimum web browser is not a good assumption
19:47
[conrad]: we used to be able to handle many more clients per server before the web and youtube became prevalent
19:47
now a tiny number of clients can kill a gigabit ethernet
19:49
<alkisg>
...even 2 of them :)
19:49
Hence the localapps and fat clients trend
19:49
But with those specs you shouldn't be having those delays, sure
19:50
The whole network is gigabit? Or just the server?
19:52
<warren>
[conrad]: are you sure the switches are stable and quality? I've used switches in the past that seemed fine for ordinary traffic but had weird errors with LTSP heavy traffic
19:52
<[conrad]>
The whole network is gigabit. The 8-10 thin clients we have are not gigabit, which we thought might have been contributing to the issue, which is why we tested with the machines with extra resources.
19:52
<alkisg>
Hmmm actually 1920*1080*30fps*4 bytes per pixel = 248832000, more than 2 Gbps for 1 client
19:53
[conrad]: you can test with iperf -s on the clients, and simultaneous iperf -c <client-ip> on the server
19:53
<[conrad]>
warren: Yes, they're stable and quality. They're Cisco, and we've been very happy with their results in everything else we done.
19:54* alkisg has also seen grave network problems with atheros cards
19:54
<[conrad]>
alkisg: is iperf much different then netperf?
19:54
<alkisg>
No, but take care to measure traffic sent from the server to the clients and not the opposite
19:56
Also check for any dns/reverse dns issues
19:57
<[conrad]>
I tried the 192.168.0. LTSP internal on the server->client for iperf, but am getting "connection refused"
19:58
Let me clarify, I tried 192.168.0.200, the IP of the thin client.
19:58
<alkisg>
Did you run iperf -s on the client first?
19:58
<[conrad]>
Which is on the 192.168.0.x internal network we have setup for LTSP that the LTSP server has a DHCP setup for.
19:59
Yes, iperf -s has run.
19:59
Server listening on TCP port 5001
19:59
TCP window size: 85.3 KByte (default)
19:59
<alkisg>
And that's *locally* on the client? Or in the server session?
19:59
I.e. you should be root on the client to do that
19:59
<[conrad]>
Are you sure this applies for thin clients?
19:59
<alkisg>
!screen_02
19:59
<ltsp>
screen_02: To get a root shell on an Ubuntu thin client: https://help.ubuntu.com/community/UbuntuLTSP/ClientTroubleshooting#Using_a_shell_SCREEN
20:00
<alkisg>
Or unlocking root pass, or epoptes, or ssh, whatever...
20:01
<sbalneav>
!pastebin
20:01
<ltsp>
pastebin: the LTSP pastebin is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebin, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.
20:01
<sbalneav>
alkisg: http://pastebin.com/DutB0k11
20:02
So, atexit handling works for catching a signal...
20:02anunnaki has left IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net, Ping timeout: 248 seconds)
20:03
<sbalneav>
http://pastebin.com/mYYmfJg4
20:03
<[conrad]>
alkisg: My apologies, is this shell somehow different from the terminal I can launch from ctrl+alt+t ?
20:04
<alkisg>
[conrad]: if you see conrad@server, you're on the server. If you see root@ltsp123, you're root locally on the client
20:04
Yup, big difference there
20:05Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
20:05
<alkisg>
sbalneav: but you don't need the atexit() there, right? You could just call the functions from handle_sigterm, that's the one that does all the work...
20:06
In any case, that does what we need, as long as xorg sends the term signal and waits for a bit...
20:08
<[conrad]>
alkisg: I actually thought *@ltsp123 was only available on a fat client? Is it that *@ltsp123 is the default behavior of a fat client?
20:08
<jammcq>
sbalneav: the docs for atexit clearly say it wont' work for catching signals
20:09
Functions registered using atexit() (and on_exit(3)) are not called if a process terminates abnormally because of the delivery of a signal.
20:09
<alkisg>
[conrad]: yes, it's the default behavior for fat clients, but you can also get it on a thin client. For a quick example, try running this inside your alt+ctrl+t terminal: ltsp-localapps xterm
20:14
<[conrad]>
alkisg: I'll have to check that later, I'm not able to restart any of the machines currently. Can you think of anything else I might be able to do?
20:16
Actually, regarding "Hmmm actually 1920*1080*30fps*4 bytes per pixel = 248832000, more than 2 Gbps for 1 client", using that math, is the problem itself then that LTSP isn't really setup for anything over 1024x768 on a gigabit network?
20:16
<alkisg>
Not LTSP. Remote desktops in general.
20:16
<[conrad]>
But at the same token, it's only Chrome we're having issues with. Firefox behaves fine.
20:17
<jammcq>
[conrad]: moving the browser to run in the client greatly reduces that traffic
20:17
<alkisg>
Firefox is using local X cache (pixmaps), it usually speeds things up a bit
20:17
<jammcq>
keep the video compressed as long as possible
20:17
but are you actually running 1920x1080x30fps ?
20:18
<alkisg>
Some ideas that you can try, if everything else fails... You can install the nvidia proprietary drivers, you can enable a compositing manager like xcompmgr, you can check for dns issues etc
20:18
<jammcq>
dns issues show up as multiples of 15-second delays
20:19
2 or 3 seconds to open a tab is NOT a dns issue
20:19
<alkisg>
It's not a timeout, but I've seen other dns issues than timeouts..
20:19
No links handy, but I do remember dns issues in the seconds range...
20:20
<jammcq>
[conrad]: do you have chrome opening a default page when you open a new tab? or is it just opening a blank page?
20:20
<[conrad]>
jammcq: blank.
20:20
<jammcq>
yeah, that's just a drawing problem.
20:20
the opensource nVidia drivers are crap, so I'd seriously try the proprietary drivers
20:21
<[conrad]>
We are actually testing with 1920x1080.
20:21
<jammcq>
chrome is trying to do 3d rendering with opengl, I don't think FF is doing that
20:21
1920x1080 screens, but you aren't doing full motion video at that resolution, are you?
20:21
<[conrad]>
No, not at all. Not doing any media on the machines.
20:22
<jammcq>
yeah, so don't worry about bandwidth requirements for 1920x1080x30fps
20:22
nobody is doing that anyway
20:22
<[conrad]>
To confirm, you're saying to install the propriety drivers on the server? Are we going to run into any issues given that the server *doesn't* have an nvidia card?
20:23
<jammcq>
chrome has some cmdline options
20:23
no, on the client
20:23
err, in the chroot
20:23* alkisg has students double clicking youtube videos all the time :)
20:23
<jammcq>
alkisg: at 1920x1080 ?
20:23
<alkisg>
Whatever resolution the monitor is in, it doesn't matter much
20:23
<jammcq>
full screen?
20:23
<alkisg>
1024×768×30×4 = 94371840
20:24
I client == 1 gbit in 1024x768
20:24
yeah they're used to double clicking youtube videos when they want to see them
20:24
So we have to tell them to keep them non-full screen, and only 3-4 of the students can watch youtube at one time
20:24
<jammcq>
[conrad]: chrome has some cmdline options for turning off things like 3d rendering
20:24
it can help alot
20:25
http://peter.sh/experiments/chromium-command-line-switches/
20:26
<alkisg>
[conrad]: out of curiosity, what are your *actual* client specs?
20:26
<jammcq>
google-chrome --disable-3d-apis
20:27
that's probably a good one to try
20:27Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Read error: Operation timed out)
20:31
<[conrad]>
jammcq: That didn't make any difference. I'll try the drivers.
20:31
alkisg: http://www.ebay.com/itm/WYSE-902122-04L-V30-DUAL-VIDEO-THIN-CLIENT-EDEN-LOT-OF-4-/251224582596?pt=US_Thin_Clients&hash=item3a7e26e9c4 , but honestly the 410's could end up working better for us for a few reasons.
20:31
<jammcq>
[conrad]: you have to make sure when you use those options that it's the first invocation of the browser.
20:32
<[conrad]>
It was.
20:32
<jammcq>
ie, if you already have a browser window open, they won't work
20:32
<[conrad]>
I understand.
20:33
<alkisg>
Yup those have the minimum specs for thin clients
20:35
<[conrad]>
They're near the bottom of the listing. Processor: Via C7 Eden 800 Mhz, Memory: 128 MB Flash / 128 MB Ram
20:36
<alkisg>
Yes you'll have at least RAM problems with them
20:37
Big lags when browsing pictures etc
20:39JesseC has joined IRC (JesseC!~JesseCWor@wsip-98-175-20-126.br.br.cox.net)
20:41Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
20:43[conrad] has left IRC ([conrad]!~mrice@rrcs-70-62-71-144.midsouth.biz.rr.com)
20:44vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
20:47
<sbalneav>
jammcq: Right, they won't work in this case:
20:48
jammcq: if you comment out the call to signal, and send the kill, the exit handlers won't get called.
20:49
but because the signal handler explicitly calls exit, that works.
20:49
The only case it wont work for is for SIGKILL, which is uncatchable.
20:49
So we'll have to test.
20:50
alkisg: right, we could potentially just call the functions, but iirc, there's limitations as to things you can do in signal handlers. I'll have to test.
20:51* alkisg thought all the exit() / atexit() etc was in the same execution thread...
20:51vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 256 seconds)
20:51
<alkisg>
sbalneav: ideally, we'd want to send a signal to our `ldm-script xsession` child
20:52
So that the shell trap executes, and the K* scripts are executed with the same shell environment
20:52
Do you think we'll get any problems if we keep the pid and send e.g. SIGTERM to it?
20:56
Hmmm actually all the shell script phases, init, pressh, start, xsession and stop could be run from the same shell, with signals... but anyway let's postpone that until the lightdm rewrite, let's stick to the current problem with the X* and the K* scripts
20:56
<sbalneav>
yup.
20:58[conrad] has joined IRC ([conrad]!~mrice@rrcs-70-62-71-144.midsouth.biz.rr.com)
20:58
<alkisg>
sbalneav: is there any way to "detach" the ssh connection so that it stays alive even after LDM dies?
20:59
Can't we run it somehow with parent pid = 1? Is that what 'daemonize' is about?
21:15
<completely unrelated>: sshfs with the defaults 3des needs 18 seconds to read some file in a tmpfs, while with arcfour it needs 8.
21:15ltspuser_53 has joined IRC (ltspuser_53!44aaff56@gateway/web/freenode/ip.68.170.255.86)
21:16
<alkisg>
I.e. arcfour is more than 2 times faster... why not enable it by default in our ssh options, even for X?
21:17[conrad] has left IRC ([conrad]!~mrice@rrcs-70-62-71-144.midsouth.biz.rr.com)
21:18
<ltspuser_53>
Wondered if anyone has any insight into an issue we are having? Ubuntu 12.04 LTSP with COMPAQ old PCs as clients. All using Intel 845G Video. After 7-8 minutes of no use, the screen will flash briefly and then the entire session will not respond although you can move the mouse around. Tried disabling all power related issues but still having issue.
21:18
<alkisg>
Get local access, check xorg.log, dmesg etc etc
21:19
<ltspuser_53>
Yeah - any advice on how - can't do a Ctrl+Alt+F1 to gain a shell...
21:20
<alkisg>
ssh, epoptes...
21:26vagrantc has joined IRC (vagrantc!~vagrant@c-98-232-129-196.hsd1.or.comcast.net)
21:26vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
21:27
<jammcq>
alkisg: what are some of the examples you have of the Xserver dying?
21:27
btw, I think the only signal we can't do anything with is SIGKILL (-9) and I don't think that happens in nature
21:27
<alkisg>
jammcq: have a nouveau client and open firefox
21:27
<jammcq>
it only happens when someone wants it to happen
21:27
<alkisg>
X segfaults then
21:28
jammcq: my first concern is to make it work on normal exit though, the "x crashes" part come later
21:28* vagrantc suspects some programs always use -9
21:28
<jammcq>
hmm, which signal would that be
21:28
<alkisg>
Because now, login, logout, relogin => no /home/username mounted
21:28
<jammcq>
maybe SIGILL
21:28
for illegal instruction
21:29
or SIGSEGV for trying to access memory it doesn't own
21:29
and we can trap those
21:29
<alkisg>
vagrantc: hi - thoughts on enabling arcfour ssh/sshfs compression by default in our ssh command lines?
21:29
<jammcq>
I don't know anything about arcfour, but my guess is it wouldn't get past the security guys at the distros
21:30
<alkisg>
It's like 8 seconds arcfour vs 18 seconds with the default 3des on some file transfer
21:30ltspuser_53 has left IRC (ltspuser_53!44aaff56@gateway/web/freenode/ip.68.170.255.86, Ping timeout: 245 seconds)
21:30
<vagrantc>
alkisg: any time we deviate from defaults, i'd want to see benchmarks...
21:30
<alkisg>
Yup benchmarks are easy, ^ that was a quick one but i've seen others on the net
21:31
<vagrantc>
as long as the security is reasonably strong, i don't see any reason not to.
21:31
we should at least make it easy to enable, if it isn't already.
21:32
give the nature of remote X, a faster even i'd be willing to trade some security for improved performance
21:33
ditto for the sshfs homedirs
21:33adrianorg__ has joined IRC (adrianorg__!~adrianorg@177.132.222.29)
21:34
<vagrantc>
i.e. i'd rather see people be happy enough with a faster less secure encryption algorithm than people defaulting to LDM_DIRECTX, as long as it was still reasonable secure...
21:34
<alkisg>
I think anyone that wants it, can enable it with LDM_SSHOPTIONS, but only for X, not for sshfs
21:34
<vagrantc>
reasonable may be hard to define...
21:34
doesn't sshfs use the same tunnel?
21:35
<alkisg>
Ah, so the same encryption will apply, nice
21:36
!learn arcfour as http://en.wikipedia.org/wiki/RC4 is more than 2 times faster than the default 3des SSH encryption cipher. To enable it, set LDM_SSHOPTIONS="-o Cipher=arcfour".
21:36
<ltsp>
The operation succeeded.
21:41
<vagrantc>
if it's included in upstream openssh at all, it can't be too terrible.
21:44
<sbalneav>
ok, so I'm unclear. If one normally logs in, and logs out, does everything work correctly?
21:45
<vagrantc>
alkisg: in my docs, Cipher only supports blowfish, 3des, and des with ssh1
21:45
<alkisg>
vagrantc: yeah sorry that's Ciphers
21:45
With an s
21:45
<vagrantc>
alkisg: Ciphers appears to support some of the arcfour options
21:45
<alkisg>
sbalneav: no, it doesn't, on second login he doesn't get an sshfs home
21:46
So all LTSP users that use localapps and fat clients can only login once until the next client reboot, without data loss
21:46
<sbalneav>
So this is a fatclient problem?
21:46
<alkisg>
Or localapps problem
21:46
sshfs, to be exact
21:46
And most people do have at least a localapps browser...
21:47
<sbalneav>
I don't. Never have.
21:47
<vagrantc>
the use of most is suspect ...
21:47
but the point is localapps and fatclients have a pretty serious problem
21:47
<alkisg>
Nah. See the map. Prove me wrong. :P http://www.ltsp.org/stories/
21:48
(ok just kidding there, but most people here in IRC that I've talked with, also do use either localapps or fats)
21:48* jammcq loves local apps
21:49
<sbalneav>
So, what, exactly, isn't getting executed on a normal logout?
21:50
which set of scripts that are supposed to run, arent?
21:50
<alkisg>
They all run. At the wrong time.
21:50Parker955_Away is now known as Parker955
21:50
<alkisg>
E.g. fusermount -u gets to run when ssh is already gone
21:50
It goes like this
21:51
<vagrantc>
http://security.stackexchange.com/questions/26765/what-are-the-differences-between-the-arcfour-arcfour128-and-arcfour256-ciphers
21:51
sounds like using arcfour128 would be a better recommendation
21:51
i.e. same key size, without less security problem
21:52
<sbalneav>
Like, here looks like the problem:
21:52
<alkisg>
User logs out. Xorg dies, LDM dies, the SSH connection dies. Then the cleanup scripts are called, which want access to the SSH socket to run cleanup scripts on the server. It's not there though, it's dead.
21:52
The problems continue:
21:53
All non-X user processes die after that. So they try to write their data to /home/username, which isn't there
21:53
so they end up writing to the tmpfs. Data loss #1.
21:53
<sbalneav>
* From here plugins has taken control. When plugin return, close everything
21:53
*/
21:53
log_entry("ldm",6,"X session ended");
21:53
/* Closing plugin */
21:53
ldm_close_plugin();
21:53
<alkisg>
On next login, /home/username is in the tmpfs, so our scripts think it's already mounted, so they don't use sshfs to mount it from the server
21:53
So the user sees a clean environment, no settings, no files
21:54
And if he does anything on that clean environment, it's lost on reboot. Data loss #2
21:54
<sbalneav>
So you guys are closing the plugin. We used to have a "rcfiles" function that would run rcfiles. If you want to have something run before the ssh socket closes, you need to run it before the ldm_close_plugin() call.
21:54
<vagrantc>
would checking if /home/username is a mountpoint on login help?
21:55
<alkisg>
sbalneav: the problem there was that user processes were still running so /home/username couldn't be unmounted, so it'd be nice to wait for them to finish (when X dies) before unmounting
21:56[conrad] has joined IRC ([conrad]!~mrice@rrcs-70-62-71-144.midsouth.biz.rr.com)
21:56
<alkisg>
And there was still the problem of non-X processes writing to the tmpfs /home/username after the session (e.g. 2 secs after xorg dies)
21:56
vagrantc: not really, because one might mount the whole /home with nfs
21:57
<[conrad]>
alkisg: While I do believe my issue has to deal with Google's attempt of hardware rendering, I did get a chance to restart the environment, and below is the output of iperf:
21:57
3] local 192.168.0.1 port 33682 connected with 192.168.0.201 port 5001
21:57
[ ID] Interval Transfer Bandwidth
21:57
[ 3] 0.0-10.0 sec 1.10 GBytes 944 Mbits/sec
21:57
<alkisg>
!pastebin
21:57
<ltsp>
pastebin: the LTSP pastebin is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebin, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.
21:57
<[conrad]>
And that's with one other client active on the network.
21:58
alkisg: Do you have a sample from your network for comparison?
21:58
<alkisg>
[conrad]: we're in the middle of some chat... but what I mean was that you would try with multiple clients simultaneously, so that you make sure you don't have flow control problems etc. Not with just 1 client.
21:58
<vagrantc>
definitely should recommend arcfour128 http://www.securityfocus.com/columnists/375
21:59
<alkisg>
[conrad]: Anyway I think you should try the other ideas first... like e.g. the drivers
21:59* alkisg tries arcfour128...
22:01
<alkisg>
arcfour=8.5 secs, arcfour128=8.6 secs, 3des=18 secs
22:01
!forget arcfour
22:01
<ltsp>
The operation succeeded.
22:02
<alkisg>
!learn arcfour as http://en.wikipedia.org/wiki/RC4 is an SSH cipher which is more than 2 times faster than the default 3DES. To enable it, set LDM_SSHOPTIONS="-o Ciphers=arcfour128".
22:02
<ltsp>
The operation succeeded.
22:03
<vagrantc>
alkisg: is 3des really the default?
22:03
<alkisg>
Not tested, but the man page says so
22:04* vagrantc sees
22:04
<vagrantc>
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc, aes256-cbc,arcfour
22:04
<alkisg>
How can I verify that the manpage is correct?
22:04
Ah let me check, maybe I was looking at the protocol 1 paragraph...
22:04
<vagrantc>
at least, in the manpage
22:04
for ssh_config
22:05
<[conrad]>
Yeah, I'm working on the drivers, and I got them installed in the chroot, but nouveau is still listed as the driver.
22:07
<alkisg>
aes128-ctr = 18.8 secs (that's probably the default, the one I was measuring before), ...
22:07
<sbalneav>
So, at the end of the day, what are we looking for? That when ldm exits, the ssh it's spawned will continue to run?
22:07
<alkisg>
sbalneav: that would be ideal
22:07
Then the scripts can take care of waiting for processes to die, clean up, and close the socket
22:08
vagrantc: 3des-cbc = 48 secs
22:08
<vagrantc>
ouch
22:08
<jammcq>
sbalneav: what process creates the ssh tunnel?
22:09
<vagrantc>
alkisg: what is it you're testing, exactly?
22:09
<alkisg>
vagrantc: I have ubuntu.iso in /run (==tmpfs), and I'm copying it to /dev/null from an sshfs connection
22:09
And echo 3 > /proc/sys/vm/drop_caches inbetween
22:09
<vagrantc>
ok.
22:10
all this localapp/fatclient stuff is pretty ugly for ubuntu precise and debian wheezy...
22:11
doesn't sound like a simple fix is feasible...
22:11* vagrantc still hopes
22:11
<sbalneav>
ok. Someone can test this, see what happens
22:11
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/revision/1480
22:13
<alkisg>
sbalneav: i tried this when we last talked about it, it doesn't work, ssh dies with ldm
22:13
As it's its child
22:13
<sbalneav>
ok, leave that in, I'll look at what needs to be done to ldm_spawn to fork a full process.
22:15khildin_ has joined IRC (khildin_!~khildin@ip-80-236-193-214.dsl.scarlet.be)
22:16
<sbalneav>
Or, alternatively, we run an rc_files("stop") or whatever before the ssh_endsession()
22:16
and your stop scripts either wait on processes to shut down, or actively kill them
22:16
use lsof to determine who's got their fingers on the mount point.
22:17
<vagrantc>
that sounds somewhat reasonable...
22:18
<Hyperbyte>
Weren't all these problems going to go away with the lightdm hackathon?
22:18
Or is this an 'in the meantime' solution?
22:18
<sbalneav>
Well 2 things.
22:18
<alkisg>
Yup, lightdm == for 14.04, this == for 12.04, wheezy etc etc
22:18
<Hyperbyte>
Ah.
22:18khildin has left IRC (khildin!~khildin@ip-80-236-193-140.dsl.scarlet.be, Ping timeout: 264 seconds)
22:19
<vagrantc>
we're stuck with it for at least a couple years
22:19* vagrantc really wishes this got figured out sooner
22:19
<sbalneav>
1) you're probably not going to have the same level of control over lighdm. Any regular dm isn't going to have rc file exit points all over the place. So some of your scripts are going to have to behave differently.
22:19
<vagrantc>
i don't think i've seen this problem on squeeze's LTSP/LDM ... when did it get introduced?
22:19[conrad] has left IRC ([conrad]!~mrice@rrcs-70-62-71-144.midsouth.biz.rr.com)
22:20
<sbalneav>
2) alkis wants a fix for some of his clients.
22:20
OK, what's the script called for the stop stuff?
22:20
<alkisg>
I'd say, all 12.04 and wheezy users that use localapps or fats would want that...
22:20
ldm-script stop?
22:21
<sbalneav>
That's it?
22:21
<alkisg>
That one calls the K* scripts
22:21
rc_files("stop"); was the ldm call
22:22
Killing all user processes before the ssh socket exits could work, if we're OK with that. At that point, all user processes are still running...
22:23
So, send a SIGTERM, wait for a couple of secs to allow them to flush their data, and then SIGKILL them?
22:24
<sbalneav>
Sure. You could find out who's got stuff open with lsof. Etc. OK, let's try this, I'll hack this in, and someone can test.... 1 sec...
22:25
<alkisg>
It's all user processes, so I don't think we need lsof... e.g. when some app receives a term signal, it might decide *then* to open ~/.config/app/settings to store its settings, so lsof won't show that before the signal
22:25
<vagrantc>
alkisg: regarding ldm-trunk 1479 ... it looks like you removed it from the rc.d hook, but didn't add it to init-ltsp.d ?
22:25
<alkisg>
(imagine fat clients, pidgin open, thunderbird, etc etc)
22:26
vagrantc: it was in ltsp-trunk
22:26
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2447
22:27
<sbalneav>
1481 pushed.
22:27
OK, gotta go pick up my wife. On later tonight.
22:27
<alkisg>
BB Scotty
22:29Enslaver has left IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net, Read error: Connection reset by peer)
22:29Enslaver has joined IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net)
22:43
<vagrantc>
so, that last revision sbalneav pushed ... clearly needs more to make all that work, no?
22:45
<alkisg>
Yup
22:46
Now it's basically as it was at the time of 12.04 and wheezy release, i.e. what most users are using now
22:46
We need to kill the user processes etc
22:47
<vagrantc>
you mean before 12.04 and wheezy?
22:48
i.e. the stop scripts got lost along the way?
22:52
<alkisg>
Kinda. I was looking to reorganize the scripts a bit:
22:52
Previously, all X* and K* scripts actually run at the same event
22:52
So the K* scripts weren't called at all e.g. if xorg crashed
22:52
<vagrantc>
?!
22:53
<alkisg>
And we had duplicate code that tried to cleanup things on normal exit (X*), and also on crash, at the next initialization phase (I*)
22:53
<vagrantc>
some of that was just unfinished transitions
22:54
<alkisg>
So I thought we'd make it like this instead: K* scripts would get called after Xorg and the user processes are dead, but with the ssh socket still open so that we could clean up things
22:54
That proved to be very difficult, to have xorg dead and ssh open
22:54
So the current trunk state is a bit of a mess
22:55
It didn't work before (so users are hit by the bug we're talking about),
22:55
but it doesn't work in the current trunk state either, for different reasons
22:55
It's not finished yet, it needs more work
22:56
So the next plan is to merge again the X* and K* events as they were before,
22:56
<jammcq>
scotty will be around later this evening to finish it
22:56
<alkisg>
to have all of them while xorg and ssh are still alive,
22:56
(and user processes etc),
22:56
and forcibly kill all user processes and do the cleanup before xorg+ldm exit
22:57
And... also do what we can to cleanup if xorg crashes
22:57
<vagrantc>
this sounds like a pretty big diff...
22:57
probably requires modification to both ldm and ltsp?
22:58
<alkisg>
The essense of it is "kill all processes before the socket dies". That can be small enough to backport to 12.04 and wheezy...
23:01
vagrantc: my "complete" cipher benchmarks: http://paste.debian.net/237228/
23:01
<vagrantc>
hope so...
23:02
<alkisg>
So without sshfs in the middle, arcfour128 is 3 times faster than the default aes128-ctr
23:04
<vagrantc>
it's still quite reasonably secure, especially with arcfour128 vs. plain arcfour
23:04
so would be a candidate for a reasonable default, and has been present since openssh 4.2 ...
23:05
<alkisg>
Let's talk about making it the default, in the next devs meeting
23:05mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving)
23:05
<vagrantc>
alkisg: though we've deviated from the default in the past... so i'd want to avoid algorithm switching becoming routine...
23:06* alkisg doesn't mind having that in a wiki instead
23:06
<vagrantc>
alkisg: should do some testing how it affects a running thinclient environment, too.
23:06
and/or server load...
23:07
well, sbalneav's patch builds fine for me...
23:07
<alkisg>
It won't help without the script to kill the user processes though
23:08
<vagrantc>
sure
23:08
just checking for obvious barriers to getting that far :)
23:09
<alkisg>
'night all
23:09alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
23:22Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 246 seconds)
23:42alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.12.47, Ping timeout: 248 seconds)
23:51komunista has left IRC (komunista!~slavko@87.244.209.121, Quit: Leaving.)