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


Channel log from 8 January 2019   (all times are UTC)

00:15vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:17kjackal has joined IRC (kjackal!~quassel@62.103.222.236)
07:51kjackal has left IRC (kjackal!~quassel@62.103.222.236, Ping timeout: 268 seconds)
08:23ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:23kjackal 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:24kjackal has left IRC (kjackal!~quassel@195.97.13.252, Ping timeout: 244 seconds)
10:24kjackal 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:52kjackal 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:37kjackal 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:24mmarconm 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:59spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 250 seconds)
13:40spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
13:45spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection)
13:48josefig has left IRC (josefig!~jose@unaffiliated/josefig, Ping timeout: 240 seconds)
13:50spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
14:20
<fiesh>
wow, that would be something :)
15:29GodFather has joined IRC (GodFather!~rcc@2600:1011:b11c:9fb3:95d3:6e04:4912:c01f)
15:39GodFather has left IRC (GodFather!~rcc@2600:1011:b11c:9fb3:95d3:6e04:4912:c01f, Ping timeout: 268 seconds)
15:53GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f)
16:09GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds)
16:11GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f)
16:17josefig has joined IRC (josefig!~jose@unaffiliated/josefig)
16:27GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 252 seconds)
16:35mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Ping timeout: 258 seconds)
16:35mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)
16:37mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Client Quit)
16:44GodFather 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:33GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds)
18:42GodFather 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:07GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds)
19:15GodFather has joined IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f)
19:26vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
19:28GodFather has left IRC (GodFather!~rcc@2600:1011:b112:33fc:95d3:6e04:4912:c01f, Ping timeout: 250 seconds)
19:42GodFather 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:56kjackal has left IRC (kjackal!~quassel@62.103.222.236, Ping timeout: 258 seconds)
20:56kjackal has joined IRC (kjackal!~quassel@62.103.222.236)
21:13GodFather has left IRC (GodFather!~rcc@2600:1011:b116:8e9e:95d3:6e04:4912:c01f, Ping timeout: 268 seconds)
21:25GodFather has joined IRC (GodFather!~rcc@2600:1011:b111:870e:95d3:6e04:4912:c01f)
22:24ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
22:47ZAJDAN 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:55kjackal 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:03GodFather 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)