00:15 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
06:17 | kjackal has joined IRC (kjackal!~quassel@62.103.222.236) | |
07:51 | kjackal has left IRC (kjackal!~quassel@62.103.222.236, Ping timeout: 268 seconds) | |
08:23 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
08:23 | kjackal has joined IRC (kjackal!~quassel@195.97.13.252) | |
08:37 | <fiesh> has anyone here ever experience issues of the following kind? when deleting an (unused) nbd image, nbd goes in funkatronic mode, intermittently creating huge io lag for the clients still running (with a different image!)
| |
08:37 | after restarting nbd and rebooting the clients, it works again
| |
08:38 | (it does keep working, it just makes working on the fat clients impossible since every 10 seconds or so there is a lag of several seconds for any file io)
| |
09:03 | <alkisg> fiesh: that sounds rather strange; are you using a plain rm on the server, or something like srm (secure rm)?
| |
09:05 | <fiesh> plain rm
| |
09:06 | <alkisg> And at that point, does the server itself have disk lag?
| |
09:06 | <fiesh> I don't really understand how this happens since the filedescriptor should still be in use by nbd and thus the file not removed. My speculation is that nbd somehow does something where it tries to read file attributes or something like that which is no longer possible since the file is no longer represented by the filesystem?
| |
09:07 | no
| |
09:07 | <alkisg> It's possible to rm a file while it's still in use; the file will be kept on disk, invisible to other processes, until the file handle is closed
| |
09:07 | We actually use that feature in nbd swap
| |
09:08 | But it shouldn't be at all related to the lag you experience
| |
09:08 | <fiesh> yes, I know
| |
09:08 | it alas also doesn't create any logs
| |
09:09 | <alkisg> Check the network requests on the server with some kind of tool like wireshark
| |
09:09 | If the server disk isn't the bottleneck, that basically leaves just the network, to cause lags...
| |
09:09 | <fiesh> neither dmesg nor syslog
| |
09:09 | ok I'll do that when it appears again
| |
09:10 | <alkisg> Btw, when you say unused, do you really mean unused by nbd-server, or that at that point you think that no client uses it?
| |
09:11 | Because if nbd-server does have it open (you can check with lsof before deletion), then it's possible that the lag is caused by nbd-server
| |
10:23 | <fiesh> the latter, no client uses it
| |
10:23 | how is that possible?
| |
10:24 | kjackal has left IRC (kjackal!~quassel@195.97.13.252, Ping timeout: 244 seconds) | |
10:24 | kjackal has joined IRC (kjackal!~quassel@ppp-2-84-217-51.home.otenet.gr) | |
10:29 | <alkisg> fiesh: well, if you hard-reset a client, the nbd-server on the server is not notified of the nbd-client disconnection, so it keeps the file open
| |
10:29 | (that's just one of the possible causes to have the file still open)
| |
10:52 | kjackal has left IRC (kjackal!~quassel@ppp-2-84-217-51.home.otenet.gr, Ping timeout: 246 seconds) | |
11:36 | <fiesh> right, but it'll eventually timeout since NBD uses TCP connections, right?
| |
11:36 | besides I don't see how that leads to the lag
| |
11:36 | it should only mean the file isn't removed from the filesystem until nbd is restarted, which I'm fine with
| |
11:37 | kjackal has joined IRC (kjackal!~quassel@62.103.222.236) | |
12:13 | <fiesh> well I guess I'm not going to run into the issue any more anyway, seeing that I got rid of all the legacy cruft
| |
12:14 | speaking of legacy cruft -- does LTSP work with IPv6 btw?
| |
12:24 | mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm) | |
12:48 | <alkisg> fiesh: it will timeout (2h 11mins), yes, but the problem may happen while it's still active
| |
12:49 | So, the nbd-server master thread may have some *bug* that could cause the lag there
| |
12:49 | But if `lsof` didn't show nbd-server having this file open, then we wouldn't need to search for such a bug
| |
12:49 | Re: ipv6, ltsp might need a bit of ironing here and there
| |
12:52 | <fiesh> hmm ok, then I'll wait, I've had sufficient pains with setting up IPv6 correctly over the Christmas break ;)
| |
12:58 | <alkisg> If all goes well, this year's gsoc might be about reimplementing ltsp6 from scratch
| |
12:58 | That will then have a minimal codebase, easier to support ipv6 and uefi and all
| |
12:59 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 250 seconds) | |
13:40 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
13:45 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection) | |
13:48 | josefig has left IRC (josefig!~jose@unaffiliated/josefig, Ping timeout: 240 seconds) | |
13:50 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
14:20 | <fiesh> wow, that would be something :)
| |
15:29 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b11c:9fb3:95d3:6e04:4912:c01f) | |
15:39 | GodFather has left IRC (GodFather!~rcc@2600:1011:b11c:9fb3:95d3:6e04:4912:c01f, Ping timeout: 268 seconds) | |
15:53 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f) | |
16:09 | GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds) | |
16:11 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f) | |
16:17 | josefig has joined IRC (josefig!~jose@unaffiliated/josefig) | |
16:27 | GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 252 seconds) | |
16:35 | mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Ping timeout: 258 seconds) | |
16:35 | mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm) | |
16:37 | mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Client Quit) | |
16:44 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f) | |
17:05 | <quinox> what kind of architectural differences would v6 have?
| |
17:08 | <alkisg> quinox: essentially, it won't have ltsp-build-client as there are many better ways to manage chroots, but it will support various sources (VMs or chroots) for the image,
| |
17:08 | it won't have LDM, but it will support LightDM and other display managers via libpam-sshauth,
| |
17:09 | it will drop all legacy code like altlinux and nbd-proxy etc etc,
| |
17:09 | and it will introduce an https configuration/control daemon instead of lts.conf
| |
17:10 | <quinox> cool
| |
17:11 | getting rid of code is always good
| |
17:11 | libpam-sshauth can't be integrated into the current LTSP?
| |
17:12 | "from scratch" are famous last words :)
| |
17:13 | although when you're intimite familiar with the codebase like you it's a more valid option
| |
17:24 | <alkisg> Putting all those to the existing code base is more work than starting from scratch,
| |
17:24 | where of course "from scratch" surely means "keep code that we added in the recent years"
| |
17:25 | ltsp-update-image is still very relevant,and I think I rewrote it only 3-4 years ago...
| |
17:25 | (and a lot of other ltsp* tools)
| |
17:40 | <josefig> good morning guys
| |
17:40 | nice to read this o/
| |
18:33 | GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds) | |
18:42 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f) | |
19:06 | <mwalters> !cheap-client
| |
19:06 | <ltsp> cheap-client: https://www.gearbest.com/tv-box-c_11262/?attr=2081-1279
| |
19:07 | GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds) | |
19:15 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f) | |
19:26 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
19:28 | GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds) | |
19:42 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b116:8e9e:95d3:6e04:4912:c01f) | |
20:21 | <mwalters> ugh, this nuc absolutely refuses to load grub efi image
| |
20:21 | looks like dnsmasq is showing it where the bootfile is, it just refuses to try to load it
| |
20:21 | Who asked for UEFI anyways?
| |
20:22 | <vagrantc> does it require a signed bootloader?
| |
20:22 | wild shot in the dark here
| |
20:22 | <mwalters> Secure boot is off, but I have a signed one anyways
| |
20:22 | it randomly booted once while I was flailing wildly at the config file yesterday... no luck since ;)
| |
20:23 | but yeah, I see this line in the log
| |
20:23 | Jan 8 15:22:57 stnserver dnsmasq-dhcp[5283]: 3862561622 bootfile name: /ltsp/amd64/grub/grubnetx64.efi.signed
| |
20:23 | the client just never actually tries to grab it as far as I can tell
| |
20:24 | had it working on my 14.04 set up =/
| |
20:24 | but that was isc-dhcp
| |
20:56 | kjackal has left IRC (kjackal!~quassel@62.103.222.236, Ping timeout: 258 seconds) | |
20:56 | kjackal has joined IRC (kjackal!~quassel@62.103.222.236) | |
21:13 | GodFather has left IRC (GodFather!~rcc@2600:1011:b116:8e9e:95d3:6e04:4912:c01f, Ping timeout: 268 seconds) | |
21:25 | GodFather has joined IRC (GodFather!~rcc@2600:1011:b111:870e:95d3:6e04:4912:c01f) | |
22:24 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection) | |
22:47 | ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75) | |
22:47 | <ZAJDAN> hi...anybody here?
| |
22:52 | <quinox> yup
| |
22:52 | quite a few
| |
22:52 | also see the channel topic :)
| |
22:53 | <ZAJDAN> when the server where runs ltsp+epoptes has been started as virtual headless ...is possible launch epoptes or will need it screen?
| |
22:55 | kjackal has left IRC (kjackal!~quassel@62.103.222.236, Ping timeout: 268 seconds) | |
22:56 | <quinox> sine epoptes uses a daemon I suppose it's possible to start the GUI over SSH fe.
| |
22:57 | I've never used epoptes myself; if you wait someone with actual experience can answer your question
| |
22:58 | (I'd suggest logging in on the epoptes server with 'ssh -Y epoptes-server' and then see if you can start the epoptes GUI)
| |
22:58 | <ZAJDAN> epoptes is perfect
| |
22:59 | <quinox> (or perhaps you can even connect to the epoptes server directly using the GUI on another PC... like I said, I never used it myself)
| |
22:59 | <ZAJDAN> I use?: ssh -X user@IP epoptes
| |
23:00 | but:
| |
23:00 | /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display
| |
23:00 | warnings.warn(str(e), _gtk.Warning)
| |
23:00 | I have susspicion, that when the machine runs as virtual headless ...it makes this problem
| |
23:00 | <quinox> what if you do 'ssh -X user@IP', login and then start epoptes from bash?
| |
23:01 | <ZAJDAN> I need the epoptes GUI display remotely
| |
23:02 | <quinox> yes
| |
23:02 | that's how I start remote apps all the time
| |
23:02 | (-Y instead of -X will bypass some security measurements which are needed for some GUI applications)
| |
23:03 | GodFather has left IRC (GodFather!~rcc@2600:1011:b111:870e:95d3:6e04:4912:c01f, Ping timeout: 268 seconds) | |
23:04 | <quinox> on Linux headless doesn't mean much BTW, a machine with a monitor attached is basically headless + a running X server
| |
23:05 | and what about 'ssh -Y user@IP' followed by 'dbus-launch epoptes' ?
| |
23:05 | http://www.epoptes.org/documentation/fat-clients
| |
23:08 | (I'm going to bed now, but keep hanging around in the channel and you will get the answer from someone)
| |