IRC chat logs for #ltsp on irc.libera.chat (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:30 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 255 seconds) | |
| 00:32 | Phantomas 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:36 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 00:47 | Gremble has left IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com, Quit: I Leave) | |
| 01:04 | stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Quit: kernel update) | |
| 01:06 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@p1040-ipad84marunouchi.tokyo.ocn.ne.jp) | |
| 01:14 | stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber) | |
| 01:24 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 01:42 | hays has joined IRC (hays!~quassel@unaffiliated/hays) | |
| 01:46 | hays_ has left IRC (hays_!~quassel@unaffiliated/hays, Ping timeout: 276 seconds) | |
| 01:49 | enslaver has left IRC (enslaver!~enslaver@c-98-196-42-169.hsd1.tx.comcast.net, Ping timeout: 264 seconds) | |
| 02:09 | adrianorg__ has left IRC (adrianorg__!~adrianorg@177.134.59.247, Ping timeout: 240 seconds) | |
| 02:16 | monteslu__ has joined IRC (monteslu__!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 02:19 | monteslu_ has left IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 260 seconds) | |
| 03:03 | elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, Ping timeout: 252 seconds) | |
| 03:03 | elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi) | |
| 03:49 | Parker955_Away is now known as Parker955 | |
| 03:57 | alkisg 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:23 | Enslaver has joined IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net) | |
| 04:29 | Parker955 is now known as Parker955_Away | |
| 04:44 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out) | |
| 04:45 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 04:45 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 04:57 | sha has left IRC (sha!~sha@e177116104.adsl.alicedsl.de, Read error: Operation timed out) | |
| 05:00 | sha has joined IRC (sha!~sha@e177119135.adsl.alicedsl.de) | |
| 05:10 | vnc786 has left IRC (vnc786!~chatzilla@49.248.129.178) | |
| 05:11 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 255 seconds) | |
| 05:19 | work_alkisg is now known as alkisg | |
| 05:29 | F-GT has left IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net, Ping timeout: 252 seconds) | |
| 06:28 | anunnaki has left IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net, Remote host closed the connection) | |
| 06:28 | anunnaki has joined IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) | |
| 06:47 | komunista has joined IRC (komunista!~slavko@adsl-195-168-244-224.dynamic.nextra.sk) | |
| 07:09 | vmlintu has joined IRC (vmlintu!~vmlintu@cs181214103.pp.htv.fi) | |
| 07:27 | <Enslaver> ok lets try more epoptes
| |
| 07:28 | khildin has joined IRC (khildin!~khildin@ip-80-236-193-140.dsl.scarlet.be) | |
| 07:35 | komunista 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:41 | dobber_ 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:42 | komunista 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:14 | khildin has left IRC (khildin!~khildin@ip-80-236-193-140.dsl.scarlet.be, Remote host closed the connection) | |
| 08:29 | markakis has joined IRC (markakis!51ba3179@gateway/web/freenode/ip.81.186.49.121) | |
| 08:39 | mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk) | |
| 08:39 | komunista has left IRC (komunista!~slavko@adsl-195-168-244-224.dynamic.nextra.sk, Read error: Operation timed out) | |
| 08:42 | shogunx has left IRC (shogunx!~shogunx@2001:4978:106:1:a0ad:1413:495f:600, Ping timeout: 240 seconds) | |
| 08:55 | shogunx has joined IRC (shogunx!~shogunx@2001:4978:106:1:e596:27a9:7e4b:acad) | |
| 08:59 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 09:02 | meamy has joined IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de) | |
| 09:16 | garymc has joined IRC (garymc!~chatzilla@host81-148-18-165.in-addr.btopenworld.com) | |
| 09:21 | komunista has joined IRC (komunista!~slavko@87.244.209.244) | |
| 09:32 | F-GT has joined IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net) | |
| 09:50 | adrianorg__ has joined IRC (adrianorg__!~adrianorg@177.156.58.168) | |
| 10:08 | Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com) | |
| 10:10 | Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas) | |
| 10:12 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Read error: Operation timed out) | |
| 10:12 | Phantomas1 is now known as Phantomas | |
| 10:22 | Enslaver has left IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net, Ping timeout: 252 seconds) | |
| 10:36 | markakis 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:05 | Enslaver has joined IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net) | |
| 11:09 | markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it) | |
| 11:12 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out) | |
| 11:13 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 11:14 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 11:16 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Client Quit) | |
| 11:16 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 11:36 | baptiste_ has joined IRC (baptiste_!baptiste@paul-sud.asso.ups-tlse.fr) | |
| 11:37 | baptiste has left IRC (baptiste!baptiste@paul-sud.asso.ups-tlse.fr, Read error: Connection reset by peer) | |
| 11:40 | komunista has left IRC (komunista!~slavko@87.244.209.244, Quit: Leaving.) | |
| 11:44 | alkisg is now known as work_alkisg | |
| 11:45 | komunista has joined IRC (komunista!~slavko@87.244.209.244) | |
| 11:51 | udayb has joined IRC (udayb!~udayb@117.219.244.94) | |
| 11:59 | udayb has left IRC (udayb!~udayb@117.219.244.94, Ping timeout: 255 seconds) | |
| 12:09 | komunista has left IRC (komunista!~slavko@87.244.209.244, Quit: Leaving.) | |
| 12:18 | anunnaki has left IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net, Ping timeout: 264 seconds) | |
| 12:19 | anunnaki has joined IRC (anunnaki!~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) | |
| 12:26 | Tatanka has joined IRC (Tatanka!~tim@revue.vtk.be) | |
| 12:29 | meamy has left IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de, Quit: meamy) | |
| 12:43 | udaybhatye 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:45 | udaybhatye has left IRC (udaybhatye!~udayb@117.219.242.200, Client Quit) | |
| 13:16 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 13:19 | vnc786 has joined IRC (vnc786!~chatzilla@49.248.129.178) | |
| 13:25 | meamy has joined IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de) | |
| 13:50 | monteslu__ is now known as monteslu | |
| 13:50 | baptiste_ has left IRC (baptiste_!baptiste@paul-sud.asso.ups-tlse.fr, Read error: Operation timed out) | |
| 13:52 | baptiste has joined IRC (baptiste!baptiste@paul-sud.asso.ups-tlse.fr) | |
| 14:08 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 14:15 | komunista has joined IRC (komunista!~slavko@87.244.209.121) | |
| 14:21 | vmlintu has left IRC (vmlintu!~vmlintu@cs181214103.pp.htv.fi, Ping timeout: 255 seconds) | |
| 14:39 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 14:39 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 14:57 | jammcq 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:12 | khildin has joined IRC (khildin!~khildin@ip-80-236-193-140.dsl.scarlet.be) | |
| 15:32 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 15:41 | Gremble has left IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com, Quit: I Leave) | |
| 15:42 | Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com) | |
| 15:44 | Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com) | |
| 15:47 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Quit: Leaving) | |
| 15:47 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 15:50 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 264 seconds) | |
| 15:53 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 16:04 | meamy has left IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de, Quit: meamy) | |
| 16:18 | FidemTurbare has joined IRC (FidemTurbare!~LumberCar@96.53.47.42) | |
| 16:33 | Ismael1 has joined IRC (Ismael1!~ismael@wldin04-103.tpa.net.br) | |
| 16:42 | FidemTurbare has left IRC (FidemTurbare!~LumberCar@96.53.47.42) | |
| 16:43 | dobber_ has left IRC (dobber_!~dobber@89.190.199.210, Remote host closed the connection) | |
| 16:44 | alkisg 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:58 | vagrantc has joined IRC (vagrantc!~vagrant@c-98-232-129-196.hsd1.or.comcast.net) | |
| 16:58 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 17:20 | JesseC has left IRC (JesseC!~JesseCWor@wsip-98-175-20-126.br.br.cox.net, Ping timeout: 244 seconds) | |
| 17:26 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 17:27 | markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, ) | |
| 17:42 | garymc has left IRC (garymc!~chatzilla@host81-148-18-165.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
| 17:46 | dievel has left IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it, Quit: Leaving) | |
| 18:21 | adrianorg__ 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:34 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 18:36 | adrianorg__ has joined IRC (adrianorg__!~adrianorg@177.156.58.168) | |
| 18:43 | adrianorg__ 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:17 | alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.12.47) | |
| 19:19 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds) | |
| 19:25 | Ismael1 has left IRC (Ismael1!~ismael@wldin04-103.tpa.net.br, Quit: Leaving.) | |
| 19:28 | alkisg 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:02 | anunnaki 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:05 | Phantomas 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:27 | Phantomas 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:39 | JesseC has joined IRC (JesseC!~JesseCWor@wsip-98-175-20-126.br.br.cox.net) | |
| 20:41 | Phantomas 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:44 | vmlintu 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:51 | vmlintu 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:15 | ltspuser_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:26 | vagrantc has joined IRC (vagrantc!~vagrant@c-98-232-129-196.hsd1.or.comcast.net) | |
| 21:26 | vagrantc 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:30 | ltspuser_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:33 | adrianorg__ 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:50 | Parker955_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:15 | khildin_ 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:18 | khildin 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:29 | Enslaver has left IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net, Read error: Connection reset by peer) | |
| 22:29 | Enslaver 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:05 | mikkel 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:09 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 23:22 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 246 seconds) | |
| 23:42 | alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.12.47, Ping timeout: 248 seconds) | |
| 23:51 | komunista has left IRC (komunista!~slavko@87.244.209.121, Quit: Leaving.) | |