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

Request log from specific day:

Channel log from 15 November 2019 (all times are UTC)

10:27	ltspbot has joined IRC (ltspbot!~supybot@devs.ts.sch.gr)
10:27	<alkisg> !ltsp
10:27	<ltspbot> ltsp: LTSP is the Linux Terminal Server Project, the open source thin/fat client solution. You can find it at https://ltsp.github.io
10:27	<ltsp`> ltsp: LTSP is the Linux Terminal Server Project, the open source thin/fat client solution. You can find it at https://ltsp.github.io
10:28	<alkisg> Double bot :D
11:00	ltspbot has joined IRC (ltspbot!~supybot@devs.ts.sch.gr)
11:01	tbayen has left IRC (tbayen!~tbayen@x2f7fe59.dyn.telefonica.de, Ping timeout: 252 seconds)
11:02	<alkisg> !irclogs
11:02	<ltspbot> irclogs: This channel is logged, archives are available at http://irclogs.ltsp.org
11:02	<ltsp`> irclogs: This channel is logged, archives are available at http://irclogs.ltsp.org
11:21	tbayen_ has left IRC (tbayen_!~tbayen@x2f7fea8.dyn.telefonica.de, Ping timeout: 240 seconds)
11:40	tbayen has joined IRC (tbayen!~tbayen@x2f7fea8.dyn.telefonica.de)
13:57	os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Remote host closed the connection)
14:05	kjackal has joined IRC (kjackal!~quassel@64.141.80.139)
14:50	<quinox> I proxy letsencrypt requests from nginx to certbot, this way I don't have shut the webserver down while upgrading the cert
14:53	there's probably a nice integration solution for that nowadays
15:01	enoch112 has joined IRC (enoch112!25f71ea4@37-247-30-164.customers.ownit.se)
15:01	<enoch112> hi
15:01	it's me again :)
15:01	<quinox> hi
15:02	<enoch112> so I've grabbed some logs from dmesg and it's possible to reproduce the issue with random screen blanking when using VGA and DP.
15:02	Here are the dmesg: https://cloud.danielhansson.nu/s/C9qnaLjdPio4MPP
15:02	I've also found how to reproduce it
15:02	question is now, how to solve it?
15:03	alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-uctpvfcdfcktmkfp)
15:03	Guest28355 has joined IRC (Guest28355!enautmatri@gateway/shell/matrix.org/x-yjevzuavpxopjpxg)
15:03	enick_814 has joined IRC (enick_814!enauttchnc@gateway/shell/matrix.org/x-bmxozkjrvctpyrty)
15:03	uumas has joined IRC (uumas!uumaslyseo@gateway/shell/matrix.org/x-pfoqlgcdigxuigcw)
15:04	<quinox> have you checked out google results?
15:04	<enoch112> yeah, for like 2 hours now
15:04	* enoch112 looking for the bug
15:05	<enoch112> this describes it quite well: https://bugs.launchpad.net/ubuntu/+bug/1574617
15:07	<quinox> most pages I find don't offer much of a solution
15:07	<enoch112> to even show the DP screen it has to be forced in ltsp.conf
15:07	exactly, so I came here, waiting for alkisg to be available
15:08	he helped me before :)
15:08	* alkisg looksaround
15:08	<quinox> there's https://bbs.archlinux.org/viewtopic.php?id=198157 with something concrete to try out, but it's from 2015 so who knows if it still works
15:09	<alkisg> enoch112: since you have 200 such clients, I think the best way is to file a bug upstream in freedesktop.org and provide feedback etc, until ALL the issues are resolved
15:10	Or, check if dp to hdmi adapters or cables solve all issues, and buy 200 of those
15:10	<enoch112> alkisg yeah, will try to replace the cables
15:10	<alkisg> (or at least as many dual screen clients you have)
15:10	<enoch112> but at least I can reproduce it now :D
15:11	<alkisg> How?
15:12	<enoch112> move the cursor between the screens, and type at the same time on the DP screen
15:12	in a terminal
15:12	it triggers it almost instantly
15:13	<alkisg> Sounds great for providing feedback in a bug report;)
15:13	<enoch112> hehe
15:13	<alkisg> Intel is especially active at the freedesktop bug tracker
15:14	Is it reproducible with a single dp screen?
15:17	<enoch112> didn't try yet
15:18	ok, so I put that page in a tab
15:18	will report next week
15:18	anyway.. another thing
15:18	as we kind of went live with this setup we have around 15 users right now using it
15:19	i've noticed that there's a "limit"
15:19	like if user 16 connects, it takes foreeeeeever to netboot
15:19	I noticed that epotes crashed due to lack of RAM and it strarted happening after that
15:19	my question is:
15:19	how much RAM do I need per client?
15:20	I will increase it later tonight and I could set it to whatever
15:20	we have 4 GB now
15:21	does epotes require something like 100 MB per client or something?
15:21	+ overhead for other stuff
15:21	so maybe 200 MB?
15:21	<quinox> !server-ram
15:21	<ltspbot> server-ram: LTSP server RAM really depends on the usage. But anyway here's an approximation: Server RAM in MB = 1500 + 30number-of-fat-clients + 300number-of-thin-clients
15:21	<ltsp`> server-ram: LTSP server RAM really depends on the usage. But anyway here's an approximation: Server RAM in MB = 1500 + 30number-of-fat-clients + 300number-of-thin-clients
15:23	<enoch112> OK, will raise to 16GB and see if it makes any difference
15:23	thanks!
15:29	statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
15:36	<alkisg> 4 GB should be enough if you only have fat clients
15:38	eddyTV has left IRC (eddyTV!~eddyTV@2601:402:4500:4670:b979:7cfb:8b86:de83, Remote host closed the connection)
15:40	<alkisg> There might be a memory leak in epoptes 1.0; try restarting it if you see that it's wasting a lot of memory, and see if it's ok after that
15:43	<mwalters> if you're using chrome/gsuite... 8gb seems to be the sweet spot these days. I find I can get 2*4gb ddr for around $40 these days in the states.
15:45	<alkisg> I think he's talking about the server, with just fat clients
15:45	No browser involved
15:47	<enoch112> --^ correct
15:48	alkisg but what do you think it might be that's taking so long to load when it exeeds a number of users?
15:48	I've noticed it kind of stalls at loading pcie for USB
15:48	<alkisg> enoch112: epoptes takes a long time to load?
15:48	<enoch112> not that I've noticed
15:49	<alkisg> the clients take a long time to load?
15:49	<enoch112> yes
15:49	<alkisg> do a lan benchmark from epoptes
15:49	<enoch112> let me see if it happens when booting the one next to me
15:49	sec
15:49	<alkisg> Also, what do you have, 1 gigabit for 200 clients?
15:50	If it happens when booting just one client, then it's not related to ltsp
15:50	There's no bottleneck with 1 client
15:51	<enoch112> it's stalling when mounting overlay
15:51	do you know what I mean by that?
15:51	<alkisg> I think you mean that it's stalling after that message, which is unrelated...
15:51	<enoch112> it's when booting ALL clients after X clients are already online
15:51	<alkisg> dmesg might help; also checking if it happens with one client would help
15:51	Then it might be related to file handles on the server
15:52	ulimits etc
15:52	<enoch112> just recorded a vid
15:52	sec
15:53	https://cloud.danielhansson.nu/s/zf2ixs5j48msj63
15:53	it starts to stall here: https://cloud.danielhansson.nu/s/3ZwbcexxN4dCPtM
15:54	so let's say 15 cleints are online, this happens on the 16:th 17:th 18:th an so on
15:55	clients*
15:59	if 14 clients are online #15 boots just fine
15:59	it's just like there's a limit for how much it can handle
16:09	<alkisg> yup, server ulimits
16:09	there have been some notes about that in the mailing lists; open a community issue
16:10	* enoch112 is googling how to raise ulimits
16:10	<enoch112> it's set to 2014 now
16:11	1024*
16:11	what does get affected? RAM, CPU, DISK?
16:12	<alkisg> probably open files ulimit
16:12	<enoch112> so no need to increase RAM or something like that to cope with the "new load"?
16:13	<alkisg> No, just edit a config file
16:13	<enoch112> ok, thanks
16:13	<alkisg> np
16:13	Although you didn't answer half the questions :)
16:13	But it should be a good pointer
16:14	<enoch112> 1 GB yes
16:14	<alkisg> Does that mean 1 gigabit connection?
16:14	<enoch112> LAN Benchmark shows 1 GB
16:14	<alkisg> For 200 clients?
16:15	GB is gigabyte, i.e. 8 gigabit
16:15	<enoch112> no bottleneck with one client, it's when reaching a specific number of clients
16:15	<alkisg> OK ok check server ulimits, maxconnections etc
16:15	<enoch112> sorry GBit/s
16:20	will try the ulimit fix
16:20	thank you so much!
16:20	have a nice weekend!
16:21	kjackal has left IRC (kjackal!~quassel@64.141.80.139, Ping timeout: 265 seconds)
16:21	<alkisg> you too :)
16:34	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
16:34	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
16:52	kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
17:18	kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 265 seconds)
17:35	kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
17:41	tbayen has left IRC (tbayen!~tbayen@x2f7fea8.dyn.telefonica.de, Ping timeout: 276 seconds)
18:33	kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 265 seconds)
18:52	kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
19:15	woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
20:05	kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 252 seconds)
20:08	kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
20:46	kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 240 seconds)
21:19	eddyTV has joined IRC (eddyTV!~eddyTV@2601:402:4500:4670:1d91:964:85ca:368e)
21:19	<eddyTV> alkisg: around by any chance?
21:24	<uumas> alkisg is either around or will see your message when they come back, so why not just ask your question now? There's also the chance someone else will be able to help :-)
21:28	<eddyTV> Good point. I'm trying to figure out which dnsmasq option I need to change/specify to change the IP address that LTSP19-based clients use for NFS on boot. I'm doing some configuration testing, and the test client is trying to NFS to the IP of the server where dnsmasq is running.
21:30	But I have a separate NFS instance I'm trying to test, and it seems like there should be a way to specify an alternate NFS server IP.
21:30	kjackal has joined IRC (kjackal!~quassel@64.141.80.139)
21:32	<eddyTV> I thought it would be option:root-path
21:36	<\|\|cw> root-path would be for the squashfs image
21:38	<eddyTV> right... I tried prefixing it with IP: as mentioned here: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q3/001623.html
21:39	<uumas> That's really old (Ubuntu 6.10 :D) and it's most likely different in ltsp19
21:41	<eddyTV> Right, I was hoping the dnsmasq configuration part would still apply though
22:03	Ahh... it's coming from the kernel boot parameters. That's why DHCP options are no help. There's an nfsroot=IP:/srv/ltsp segment. Need to figure out how to adjust that.
22:06	Hmmm... that's coming from the ltsp.ipxe file: nfsroot=${srv}:/srv/ltsp
23:01	kjackal has left IRC (kjackal!~quassel@64.141.80.139, Ping timeout: 276 seconds)