Version: LibreOffice 7.3.5.2 30(Build:2)
I noticed that after the upgrade from 7.3.4 to 7.3.5 (on 2022-08-01), the start time of LibreOffice is 53 seconds, sometimes even more than 2 minutes. I didn’t start in a certain mode.
I just downgraded to 7.3.4 – no problems there. I removed ~/.config/libreoffice/ and upgraded again to 7.3.5 – same long start time.
I don’t see high memory or CPU usage during startup.
Any ideas?
Most times such delays are due to unavailable network resources tried to be accessed until timeout, like printers, remote sites, shared drives, whatever. You could try with
strace -f -tt -T soffice |& tee tempfilename
and inspect tempfilename after startup whether you find something enlightening what it waited for, e.g. open/openat/access calls. Lines start with an absolute timestamp and at line end is the time spent in a system call in angel brackets, like <0.000017> in seconds with a precision of microseconds.
If you are using the Arch package you could also try to use the TDF provided build and see if that behaves different and if it does it’s probably something Arch build specific.
Thanks, that looks like a good debugging trick! Hm, for me it’s not enlightening though; I have 7 lines that took about 25 seconds, all something like
[pid 236886] 19:41:16.306273 <... read resumed>"75%\n", 255) = 4 <26.056669>
(either “read resumed” or “poll resumed”)
Right before the first of these lines there is also a gap in the timestamp:
[pid 236950] 19:40:24.516581 openat(AT_FDCWD, "/home/xxx/.config/libreoffice/4/user/eFq4nJ", O_RDWR|O_CREAT|O_EXCL, 0600) = 20 <0.000473>
[pid 236950] 19:40:24.517119 newfstatat(20, "", {st_mode=S_IFREG|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0 <0.000040>
[pid 236950] 19:40:24.517234 fcntl(20, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0 <0.000023>
[pid 236950] 19:40:24.517845 mprotect(0x7f87ac021000, 32768, PROT_READ|PROT_WRITE) = 0 <0.000263>
[pid 236950] 19:40:24.518238 pwrite64(20, "<?xml version=\"1.0\" encoding=\"UT"..., 75272, 0) = 75272 <0.000126>
[pid 236950] 19:40:24.518937 pwrite64(20, "</value></prop></node></item>\n<i"..., 51290, 75272) = 51290 <0.000088>
[pid 236950] 19:40:24.519092 close(20) = 0 <0.000023>
[pid 236950] 19:40:24.519168 rename("/home/xxx/.config/libreoffice/4/user/eFq4nJ", "/home/xxx/.config/libreoffice/4/user/registrymodifications.xcu") = 0 <0.000557>
[pid 236950] 19:40:24.519829 rt_sigprocmask(SIG_BLOCK, ~[RT_1], NULL, 8) = 0 <0.000014>
[pid 236950] 19:40:24.519902 madvise(0x7f87b03bc000, 8364032, MADV_DONTNEED) = 0 <0.000024>
[pid 236950] 19:40:24.519960 exit(0) = ?
[pid 236950] 19:40:24.520046 +++ exited with 0 +++
[pid 236918] 19:40:49.236482 <... poll resumed>) = 0 (Timeout) <25.023172>
But I can’t see to what resource this timeout refers to…
For the <... poll resumed> there should be a poll([fd=number] <unfinished ...> where fd=number indicates a file descriptor that was opened previously and you’d have to skim through the log what file descriptor actually was opened with that number. Similar for <... read resumed>. But yeah, that’s not exactly easy…