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


Channel log from 18 March 2020   (all times are UTC)

01:06vagrantc_ has left IRC (vagrantc_!~vagrant@unaffiliated/vagrantc, Quit: leaving)
01:20gdi2k has left IRC (gdi2k!~gdi2k@49.145.67.147, Ping timeout: 246 seconds)
03:27vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
03:29gdi2k has joined IRC (gdi2k!~gdi2k@203.177.136.19)
03:52gdi2k_ has joined IRC (gdi2k_!~gdi2k@122.55.84.2)
03:56gdi2k has left IRC (gdi2k!~gdi2k@203.177.136.19, Ping timeout: 264 seconds)
04:12gdi2k_ has left IRC (gdi2k_!~gdi2k@122.55.84.2, Ping timeout: 264 seconds)
04:47
<map7>
Just testing IMAGE_TO_RAM=1 on my debian 11 + LTSP 20.1 and when I add that feature (and run ltsp initrd) I cannot login to my fat-clients
04:47
When I take the option out again, it's back to normal
04:47
my fat-clients have 8GB or RAM and my img is 2.9GB
05:19
<alkisg>
map7: that option was implemented/tested by kvaps, who isn't here currently, so maybe you could ask that in the github pull request where the implemenation was
05:20
<map7>
alkisg: cool, I thought I better ask here before doing that.
05:21
<alkisg>
Sure, you did the correct thing, I just have many things atm and I haven't tested that at all, it's a special case... :)
05:21
!sync
05:21
<ltspbot>
I do not know about 'sync', but I do know about these similar topics: 's', 'sis', 'sound', 'specs', 'sshd', 'suse'
05:23
<map7>
alkisg: Is this the pull request you want me to comment on? https://github.com/ltsp/ltsp/pull/86
05:24
<alkisg>
Yes, sounds fine
05:24
<map7>
cool thanks
05:24
<alkisg>
map7, just out of curiosity, in which case is IMAGE_TO_RAM needed, when server access is required anyway for /home?
05:25
<map7>
alkisg: It's not needed, but I wanted to improve the speed on access of applications and was testing out this solution
05:25
on first load of libreoffice it's taking 15seconds
05:25
second loading takes 3seconds
05:26
<alkisg>
You can dd if=image of=/dev/null at boot, and cache all of it
05:26
and have the same effect as image_to_ram, with the additional benefit that if you ever need that ram, it'll be freed
05:26
<map7>
Do I put that in a POST_ option in ltsp.conf?
05:27
<alkisg>
I think PRE_INITRD_BOTTOM_x would be the easiest one, although POST_INIT_x=dd & with the & to background it would be the best, but it'll be difficult to locate the device then
05:31
ogra, highvoltage, hi, I want to sync ltsp from debian to ubuntu but I forgot where I kept notes about this, could you tell me the base command to do it, so that I grep through my notes?
05:32* alkisg checks dpkg -L ubuntu-dev-tools
05:32
<alkisg>
Yey, syncpackage
05:34
!learn syncpackage as to sync ltsp from unstable to the current Ubuntu development series: syncpackage -d sid ltsp
05:34
<ltspbot>
The operation succeeded.
06:58adrianor1 has joined IRC (adrianor1!~adrianorg@177.204.159.122.dynamic.adsl.gvt.net.br)
07:01adrianorg has left IRC (adrianorg!~adrianorg@187.113.249.171, Ping timeout: 240 seconds)
07:23woernie_ has joined IRC (woernie_!~werner@pD9E8BE9E.dip0.t-ipconnect.de)
07:31Klimm has left IRC (Klimm!~Georg@p548973AD.dip0.t-ipconnect.de, Quit: Leaving)
07:35gvy_ has left IRC (gvy_!~mike@83.220.44.62, Quit: Leaving)
07:35gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
07:37statler has joined IRC (statler!~Georg@p548973AD.dip0.t-ipconnect.de)
10:02alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
10:13gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19)
10:24gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Quit: Leaving)
10:24gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19)
10:52statler_ has joined IRC (statler_!~Georg@gwrz.lohn24.de)
10:56Teridon has joined IRC (Teridon!~Teridon@dragon.teridon.com)
11:12alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
12:39gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Ping timeout: 250 seconds)
12:43gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.18)
13:50markit has joined IRC (markit!~marco@mail.ammdomus.it)
13:51
<markit>
hi alkisg, I've done a simple test comparison, and now client boots + responsive GUI interface in -20 less, goood job (20.04 "old" config 1'40", now 1'20")
13:52
just wondering why server VM is able to boot + responsive GUI in 30" and if there is further space to improve. I.e. systemd-analyze blame seems to have a lot of useful info, but maybe I'm wrong (like "11.747s man-db.service")
13:53
<MWALTERS>
netbooting client on a VM hosted by same physical box as the server?
13:54
<markit>
also there is a lot of time with black screen that I wonder what the client is doing/waiting in the meantime
13:54
<alkisg>
Back, reading...
13:54
markit: do you have access now to such a client/setup?
13:54
For vnc?
13:54
<markit>
I'm very far from your timings in any case, but I've a different configuration
13:54
I'm running as "test lab" in my Proxmox VM server
13:55
<alkisg>
1.20 is a lot, mine are a lot less than 1 min
13:55
OK, can you vnc to me from there?
13:55
!vnc-edide
13:55
<ltspbot>
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
13:55
<markit>
yep, but I'm lazy and I've just boot and take time "visually", if you want I have a 6MB video of the client booting
13:56
sure, let me run again the server
13:56
<alkisg>
For example man-db shouldn't have run at all
13:56
It's supposed to be blacklisted in: ltsp/client/init/56-mask-services.sh:man-db.timer # Daily man-db regeneration
13:57
<markit>
also I was building the image and had this message: File /tmp/tmp.2AbkoAV1mI/root/var/cache/apt/pkgcache.bin changed size while reading filesystem, attempting to re-read
13:57
brb, phone call
13:58
<alkisg>
That's normal if you run apt update while running ltsp image
14:07
<markit>
back
14:07
yep, but apt update is automatic and wondering why it takes /tmp in consideration
14:08
but back to our problem
14:08
cennected
14:08
<alkisg>
markit: rootfs, /, is bind-mounted there in tmp for the ltsp image
14:08
<markit>
let me know when you wamt me to run the client
14:08
<alkisg>
bind mount means that the same path is in two places
14:14
markit: ok reboot client
14:14
<markit>
ok
14:14
<alkisg>
You had put my optimizations inbetween of your sddm configuration, so that destroyed ltsp.conf
14:15
<markit>
I saw :(
14:15
login reached after 42"
14:15
<alkisg>
OK, that sound better
14:16
<markit>
I've configured for NFS home
14:17
<alkisg>
You haven't configured the client part
14:17
You had only done the server part
14:17
I.e. FSTAB in ltsp.conf
14:17
<markit>
my misunderstanding of the whole stuff :(
14:18
<alkisg>
This one needed to be uncommented: FSTAB_HOME="server:/home /home nfs defaults,nolock 0 0"
14:21
<markit>
tell me what to type
14:21
I see you can't quit that program
14:23
<alkisg>
Something is wrong with epoptes there, but let's leave that for later
14:25
I tested with .iso images and not with the chrootless case
14:25
So I might have omitted some more services like nfs-kernel-server
14:25
Let's see
14:28
<markit>
pws is ltsp101
14:29
<alkisg>
Login needs less than 20', not bad
14:29
<markit>
really :)))
14:30
user is amministratore
14:33
the 'infamous' kde icon cache... there is one in each user .cache also
14:34
<alkisg>
If we include it in the image, will it get regenerated anyway?
14:34
Or it only gets regenerated one time?
14:34
<markit>
I think that the problem is that in any case it search through all the icons to check if something has changed, and it's a hell of I/O
14:35
probably less I/O than if it has to recreate it, but I should test. I.e. if you look at the user *.kcache, and run a new kde program, the timestamp of .kcache change
14:36
so I think that at boot time it creates the .kcache with the icons it used to run the login and desktop, then it updates it
14:37
<alkisg>
The first 100 MB is the kernel/initrd now, they grew too big because of the amdgpu and other drivers
14:37gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.18, Ping timeout: 250 seconds)
14:37
<markit>
do you want me to login in the client?
14:38
<alkisg>
Only 202 to login? Woah that's very little!
14:38
I was getting more :)
14:38
No wait there
14:38
And that includes the sddm traffic
14:38
All is fine then
14:39
It's strange that the date there isn't the current one
14:40
So it's like they're opening it without actually writing anything... meh
14:40
OK anyway it seems faster than mate now :D
14:40
<markit>
icon-cache.kcache is
14:40
<alkisg>
Play a bit with it and tell me timings etc
14:40
<markit>
ok, thanks a lot for fixing and improving my configuration
14:40
<alkisg>
15:39:11 vs 14:26
14:40
It's not the same time
14:41
np, thank you too for sponsoring the last release markit
14:41
<markit>
btw, I've seen that tplink has a "not too costly" 24 Gbit port + 4 10Gb spf+ ports...
14:41
<alkisg>
For now, I'll be using 2*1 Gbps bond on the servers, and plain full gigabit switches
14:41
As the government ordered a whole lot of new servers and switches for ltsp
14:42
In the next hardware update after 10 years, we'll see :)
14:42
Now at least we got rid of all pentium 3's and some p4's
14:42
<markit>
Tplink T1700G-28TQ if you are curious :) ok, time to review your changes, update my "install notes" and do some tests
14:42
(TQ is fanless)
14:43
<alkisg>
Sounds good :)
14:44
<markit>
btw2: when I connect with socat SYSTEM:"sleep 1 && exec screen -xRR ra",pty,stderr tcp:<ip_ass_remota>:5500 & screen -l -S ra
14:45
then the X-term in my home PC seems not to like a lot of keyboard combinations
14:45
is really hard to work with emacs / nano or whatever, and nor TAB for bash completion works... is it normal?
14:47Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
14:49
<alkisg>
markit: I think kubuntu is exposing some variable like TERM that screen/socat don't like, that's why I was having the issue with keyboard there,
14:49
but we'll have to look into this another time, as I'm working on something else currently...
14:50
<markit>
sure, have a nice day :)
14:51
<alkisg>
You too, do ping if something goes wrong with ltsp though :)
15:25
<fiesh>
oh god tplink
15:25
apart from sony the only brand I will *never ever* buy anything again
15:25
my advice: don't buy it, you'll regret it, no matter what it is
15:57vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:57
<markit>
fiesh: why? I usually buy netgear but I think are also cheap
15:59
<MWALTERS>
I've been turned off netgear after this 48port poe switch I have... web interface doesn't work in any modern browser =/
16:00
<markit>
MWALTERS: I've worked for some month for a municipality that had expensive HP Procurve... with web interfaces requiring Java for some features :(
16:01
MWALTERS: so the problems is (not only) the brand, but mainly their williness to keep things updated
16:02
<MWALTERS>
yeah, it's not unusual, unfortunately =/. We only have 1 of those netgears, and I just keep it around for emergencies. We mostly have a bunch of cisco SGP small business switches
16:02
<markit>
tplink seems have a LOT of features. I've tested (but not for ltsp) their 24 x 1Gb port and worked fine so far
16:02
<MWALTERS>
I've replaced all of our routers with ubiquiti edge routers, which have been great... probably gonna go with edgeswitches when I need to buy switches in the future
16:03
They're like... $900usd for 500w 48p poe+... the web interface works well... and the cli works great too.
16:03shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
16:04
<MWALTERS>
But yeah, you're right. My supermicro servers all require java for the silly remote console thing in the iLO =/
16:04
My thoughts: never let a firmware developer also develop the web admin interface ;)
16:06shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
16:44
<alkisg>
TPLINK tl-sg1024de is one of the cheapest managed switches that I've seen, with flow control=off by default, so we've bought hundreds of them, and in 5+ years only one port of all these switches has failed
16:44
It even reports "the cable in that port has problems" and the cable length etc
16:45
vagrantc: ltsp 20.03 synced to ubuntu 20.04 and to the stable ppa, ty
17:09
<markit>
alkisg: hi, I've looked at systemd-analyze blame and found 2 more services that eat time and are useless, added in MASK_SYSTEM_SERVICES, they are wpa_supplicant pppd-dns
17:29statler_ has left IRC (statler_!~Georg@gwrz.lohn24.de, Remote host closed the connection)
17:33
<fiesh>
must be random variance in the quality of tplink products... the ones I had all sucked horribly
18:05Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
18:30
<markit>
alkisg: I've kdeconnect (/etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop) that starts in the client even if I have MASK_SESSION_SERVICES=org.kde.discover.notifier org.kde.kdeconnect.daemon
18:31
Also discover seems was running anyway, I had to purge it
18:31
am I doing something wrong? seems they are "dbus" services and not easy to disable, but I don't really know what am I talking about
18:32
<quinox>
does it start before you log in?
18:32
<markit>
let me try
18:32
<quinox>
I would think that KDE starts all sorts of shit as soon as you login with a KDE session
18:33
<markit>
quinox: sure
18:33
i can't remove it due to a tons of dependencies
18:33
<quinox>
I hate Mate, I don't use it but whenever you install it it will overwrite your Firefox homepage with a Mate URL >:(
18:35
I install all the Desktops / Window managers that people want, so my image contains at least 4 different ones at all times
18:35
<MWALTERS>
just make them all use i3
18:35
<markit>
quinox: yep, after login
18:37
MWALTERS: have a look at supermicro latest firmware for your MB, they intruduced HTML5 console recently
18:40
<MWALTERS>
oh, thanks... I'll have to actually look at that
18:40
:)
19:03
<markit>
alkisg: in 56-mask-services I find this line "re rm -f "/etc/xdg/autostart/$service.desktop" \" ... what does "re" stand for? seems not to be a command
19:11
<alkisg>
back, reading...
19:13
markit, previously /etc/xdg/autostart was used, now there's a trend to migrate everything to systemd user services,
19:13
and, there's also desktop-environment-specific dirs for autostart
19:13
"re" means "run and exit on error"
19:13
It's a shell function in /usr/share/ltsp/ltsp
19:14
Did you remember to run `ltsp initrd` after modifying ltsp.conf?
19:15
MASK_SESSION_SERVICES=org.kde.discover.notifier org.kde.kdeconnect.daemon => remember to use quotes
19:15
A=B C in shell means:
19:15
Set A=B, and run C with A in the environment
19:15
MASK_SESSION_SERVICES="org.kde.discover.notifier org.kde.kdeconnect.daemon"
19:24
<markit>
alkisg: quotes are there, dinner time, I will take one more look later, thanks
19:25
btw, for systemservices adding "wpa_supplicant pppd-dns" worked fine, some less seconds for boot :)
19:26
<alkisg>
markit: sure, but we can't disable these by default as some people might want to use wifi or ppp with ltsp clients
19:27
<markit>
you remarked the line POST_INIT_SWAPPINESS="sysctl vm.swappiness=10"
19:28
is it not userful at all?
19:28
<alkisg>
In general, setting swappiness usually harms rather than helps
19:28
So I wanted to test with the defaults first
19:28
If you see that it helps, np, use it
20:29Teridon has left IRC (Teridon!~Teridon@dragon.teridon.com, Remote host closed the connection)
20:51Klimm has joined IRC (Klimm!~Georg@p54897080.dip0.t-ipconnect.de)
20:52statler has left IRC (statler!~Georg@p548973AD.dip0.t-ipconnect.de, Ping timeout: 256 seconds)
21:17woernie_ has left IRC (woernie_!~werner@pD9E8BE9E.dip0.t-ipconnect.de, Remote host closed the connection)
22:55
<map7>
alkisg: I did the caching the when I benchmark starting libreoffice it still takes the same amount of time.
22:55
PRE_INITRD_BOTTOM_IMAGE_TO_RAM="dd if=/root/images/x86_64.img of=/dev/null"
22:56
I upgraded to 20.3 this morning and that helped a little (15secs -> 9secs on a cold start of libreoffice)
22:56
2secs on a warm start
22:57
<markit>
map7: just curious, why dd in /dev/null?
22:58
<map7>
that's what alkisg said to do if I want to cache the image to memory, but I would of thought it would just throw it away if anything goes to /dev/null
22:59
markit: I tried IMAGE_TO_RAM=1 but then my fat-client doesn't boot
23:00
<markit>
map7: are you using the last version of ltsp, so only "fat, chrootless" clients are supported, right?
23:01
<map7>
yes I'm using ltsp 20.3 from PPA on Debian bullseye (testing)
23:02
yesterday I was on 20.1
23:02
The IMAGE_TO_RAM wasn't booting on 20.1
23:02
I'm just testing now with 20.3 to see if that's fixed
23:03
<markit>
btw, how much ram do you have on the client?
23:03
<map7>
8GB
23:03
<markit>
urgh!
23:03
<map7>
and my image is 2.9GB
23:04
The image seems to copy to ram, but the boot process stops at 'A start job is running for /home'
23:05
I do have this in my config: FSTAB_HOME="server:/home /home nfs defaults,nolock 0 0"
23:05
<markit>
map7: what is your goal? Mine is improve boot and login performance with Kde (kubuntu 20.04), and speed in general
23:05
map7: and you have NFS enabled on the server side too? /etc/exports.d/ltsp-nfs.exports
23:05
<map7>
same goal, but I'm running debian + xfce4
23:06
yes I do have NFS enabled
23:06
it all works if I don't use the image_to_ram
23:06
just slow
23:06
<markit>
define slow :)
23:06
<map7>
There is a blank screen before the login for about 15secs
23:06
libreoffice takes 9seconds to load on a cold boot
23:07
2seconds on a warm start
23:07
It has to be better performance than our current LTSP5 thin client setup otherwise we won't go with fat-clients for now
23:08
We have a powerful server so our thin-clients start programs like libreoffice very fast
23:08
<markit>
just tested my libreoffice cold start, 16 seconds (test environment, a VM for server, one as client)
23:08
<map7>
yes that's slow
23:09
<markit>
it's a matter of disk I/O I suppose
23:09
<map7>
On our thin-clients (using the same server but different VM) it loads libreoffice in 1.5seconds
23:09
both VM's are on the same disk
23:10
same IO
23:10
<markit>
do you have a fast connection with the switch? Have you tested with epoptes test the lan bandwidth?
23:10
<map7>
same network
23:10
I have a 10Gbit switch for the server and each client (5 thin clients) have a 1Gbit connection to that server
23:11
<markit>
thin clients just transfer screen, not the program and also have direct access to home, not through NFS
23:12
libreoffice warm start here 2 seconds too
23:12
<map7>
Just testing the fat-client connection speed now
23:13
<markit>
I've iftop to see how much traffic, but don't know how to check how much disk I/O with a sum (iotop -o is just in "real time")
23:14
map7: NFS is much worse in I/O than direct I/O, and seems that now that programmers have SSD, they care less and less about optimization of it
23:14
<map7>
I'm getting 942Mbps down, 940Mbps up to that client
23:15
<markit>
loading Libreoffice is about 80MB (from server to client) and 5MB in the other direction
23:16
<map7>
Just timed the blank screen before login and it was 33seconds that boot
23:17
<markit>
wondering if a NFS optimization could help, but I see there already "async" parameter
23:17
map7: try in the client systemd-analyze blame
23:18
you could find some service that slows thing down and are useless
23:19gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19)
23:19
<markit>
also systemctl status should have no errors
23:19
you could have some service that has problems and wastes time
23:20
dmesg also could help
23:21
<map7>
systemctl status says 'State: degraded'
23:22
<markit>
if is nfs, use this line in ltsp.conf: MASK_SYSTEM_SERVICES="nfs-kernel-server wpa_supplicant pppd-dns"
23:23
(well, the last 2 services are useless for me, so you can just stay with nfs-kernel-server)
23:23
to see what is the problem, systemctl failed
23:23
(just learned watching alkisg troubleshoot my server this afternoon, lol)
23:24
<map7>
cool
23:25
checked 'systemctl' and found it is nfs-server failing
23:26
Also in 'dmesg' it's complaining about a missing firmware for my NIC
23:27
<markit>
map7: firmware should not be a problem, maybe you can't have certain features, or is not really stable without it, but should be fine since you tested it and was almost at 1Gb/s
23:29
now I try sync; echo 3 > /proc/sys/vm/drop_caches and then warm run again of libreoffice
23:30
again 15 seconds, so is really the time it takes to fetch the image from the server :(
23:30
80MB at 1Gb/s should be 1 second of transfer
23:31
<map7>
hmmm, could be NFS speed
23:32
<markit>
I've run iotop -o on the server, and there has been NO I/O during the client libreoffice load (probably server caches that too)
23:32
so seems only a matter of NFS access to the compressed image... maybe the compress algorithm is not optimal?
23:33
let's have a look at client CPU also
23:33
mmm does not seem to be saturated during LiBo loading
23:34
I think only alkisg can save us :)
23:35
<map7>
after adding the firmware and disabling those three services the blank screen is still taking 30seconds
23:38
my client is running an i3-7100U @ 2.4Ghz
23:38
Intel HD graphics 620
23:38
it's pretty new
23:41
<markit>
I'm googling for nfs3 optimization
23:41
netstat -s (client side) could give info about network problems
23:41
<map7>
markit: I now have an error free systemctl status and no errors in my dmesg at all
23:41
same slow speed
23:45
<markit>
you can see what is "wrote" during boot by the client having a look at /run/initramfs/ltsp/0/up
23:45
using du -csh you can see how many MB
23:47
<map7>
16MB
23:49
My NFS mount is;
23:49
server:/home /home nfs defaults,nolock 0 0
23:52
<markit>
map7: I've instead the default one generated by ltsp command
23:53
ah, sorry, in ltsp.conf, ok
23:53
but I think loading libo is a matter of fetching it's executable from the image file
23:53
<map7>
FSTAB_HOME="server:/home /home nfs defaults,nolock 0 0"
23:53
Yes I agree
23:54
I don't think it has to do with my FSTAB_HOME line
23:54
<markit>
cat /etc/exports.d/ltsp-nfs.exports
23:54
<map7>
It's either NFS or the image file compression as you said
23:54
<markit>
that has /srv/ltsp *(ro,async,crossmnt,no_subtree_check,no_root_squash,insecure)
23:55
but don't understand how is used by the client, is not listed if I use the "mount" command in the client
23:55
(I can only see home mounted as nfs4 protocol, and rsize=262144,wsize=262144 that look strange value to me)
23:57
<map7>
my rsize & wsize on home NFS4 is 1048576
23:58
<markit>
nfsstat -r shows 0 retransmissions
23:59
<map7>
same
23:59
<markit>
I think that a) the image is compressed, so it needs time to decompress what has been transfered b) nfs is not that efficient