Libreoffice Start dauert ewig

[Andi123]

Servus

Libreoffice Start dauert ca 10 Sek. beim Erststart nach Starten,Neustarten des Computers.

Dann geht es schneller.

Der Ladebalken geht zügig bis zur Mitte, dann ca. 10 Sek. Stillstand, dann schnell zum Ende.

Die Version ist die "Mitgelieferte", also keine Selbstinstallierte.

Was könnte das Problem sein?

HP Z-Book 15 G3 Debian 12

Gruß
Andi

[niemand]

Zehn Sekunden für diese dann doch ziemlich fette Software auf einer fast zehn Jahre alten Maschine finde ich nun nicht so absonderlich langsam. Leider schreibst du nicht, welches DE du verwendest – im Fall von KDE müssten bei LOo noch die ganzen Gtk-Sachen geladen werden, was auch etwas Zeit in Anspruch nimmt.

Was könnte das Problem sein?

Wenn zehn Sekunden Startzeit für dich ein Problem sind, wäre neue Hardware eine Überlegung wert.

[Andi123]

Deb12 KDE

und so schwach ist der Recner nicht.

In der VM Virtualbox habe ich ebenfalls ein Debian12 aber XFCE, da startet LO super schnell!

Außerdem starten und arbeiten alle anderen Programme schnell.
Ich bastle auch Videos mit Shotcut, schnell!

[Draal]

KDE ist natürlich auch ein Brocken. Mein 10 Jahre altes Acer Notebook läuft mit kde-plasma-desktop. Darauf startet LO in etwa 3 Sekunden.

[Andi123]

KDE ist natürlich auch ein Brocken. Mein 10 Jahre altes Acer Notebook läuft mit kde-plasma-desktop. Darauf startet LO in etwa 3 Sekunden.

Sogar die Debian VM startet LO fix.

Ist auch kei KDE Problem, denn alles andere ist schnell!!

[whisper]

Mach mal bei KDE und XFCE diesen Aufruf und schreibe das in ein Log
z.B.

Code: Alles auswählen

strace /usr/bin/libreoffice 2>lo-kde.txt

Aber beide frisch zum ersten Mal gestartet.
Evtl. siehst du dann wo die Unterschiede her rühren.

[heisenberg]

Mach mal bei KDE und XFCE diesen Aufruf und schreibe das in ein Log
z.B.

Code: Alles auswählen

strace /usr/bin/libreoffice 2>lo-kde.txt

Aber beide frisch zum ersten Mal gestartet.
Evtl. siehst du dann wo die Unterschiede her rühren.

Am besten den strace noch durch /usr/bin/time /usr/bin/ts (aus moreutils) mit den Optionen für inkrementelle timestamps als prefix pipen. Das könnte sehr hilfreich sein.

[Andi123]

Mach mal bei KDE und XFCE diesen Aufruf und schreibe das in ein Log
z.B.

Code: Alles auswählen

strace /usr/bin/libreoffice 2>lo-kde.txt

Aber beide frisch zum ersten Mal gestartet.
Evtl. siehst du dann wo die Unterschiede her rühren.

XFCE hab ich nicht mehr

Ich hatte das Problem vor Debian auch mit Mint XFCE, und ewige Diskussionen im Mintforum.
Die gaben der neueren Version die Schuld, hatte da ein Libreoffice PPA mit der neuesten Version.
Da Mint weg. Ubuntu original eine 7.3er Version hatte, mit dem PPA hatte ich eine 4.7er Version als rc.
Hier habe ich auch eine 4.7er Version.

[heisenberg]

Für die inkrementellen timestamps braucht es moreutils.

Das wäre dann das Kommando:

Code: Alles auswählen

strace /usr/bin/libreoffice 2>&1 | ts -i "%.T" >lo-kde.txt

[Andi123]

Für die inkrementellen timestamps braucht es moreutils.

Das wäre dann das Kommando:

Code: Alles auswählen

strace /usr/bin/libreoffice 2>&1 | ts -i "%.T" >lo-kde.txt

Gemacht.
Habe eine Textdatei mit 763 Zeilen erzeugt.

[niemand]

Habe eine Textdatei mit 763 Zeilen erzeugt.

Wenn du möchtest, dass jemand drüberschaut, solltest du sie verfügbar machen – etwa via pastebin/ – und am besten die Ausgabe vom zweiten Mal (wenn es schneller startet) auch gleich.

[heisenberg]

Desweiteren kannst Du Dir die Textdatei auch mal anschauen. Die meisten Zeilen werden dort mit einem Zeitstempel von 00:00:00.00xyz beginnen. D. h. der entsprechende System-Call braucht nur minimale Zeit.

Einige Zeilen werden aber schon eine gewisse Zeit da stehen haben, da die 10 Sekunden ja irgendwo verbraten werden müssen. Wenn Du also jetzt die Datei durchgehst, dann schaue nach den Zeilen die eine Zeit nahe oder über 1 Sekunde da stehen haben und setze die entsprechenden Zeilen (mit 5 Zeilen davor und 5 Zeilen danach) hier in code-tags rein.

Beispiel 1 - sleep

Code: Alles auswählen

$ strace sleep 3 2>&1 | ts -i "%.T" >sleep-strace.txt

$ cat sleep-strace.txt
...
00:00:00.000014 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
00:00:00.000014 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3048992, ...}, AT_EMPTY_PATH) = 0
00:00:00.000014 mmap(NULL, 3048992, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fef7de00000
00:00:00.000015 close(3)                                = 0
00:00:02.972493 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=3, tv_nsec=0}, 0x7ffee66babd0) = 0
00:00:00.000194 close(1)                                = 0
00:00:00.000181 close(2)                                = 0
00:00:00.000178 exit_group(0)                           = ?
00:00:00.000102 +++ exited with 0 +++

Man sieht hier, dass der Systemcall clock_nanosleep die 3 Sekunden verbraucht.

Beispiel 2 - Start von Gimp

Gimp braucht bei mir auch 2-3 Sekunden beim starten. Hier ist der untersuchte Start von Gimp. Die Ausgabe zeigt alle Syscalls, die mindestens 100 Millisekunden benötigen, ebenso wie 2 Zeilen vor dem entsprechenden Syscall und 2 Zeilen danach:

Code: Alles auswählen

$ strace gimp 2>&1 | ts -i "%.T" >gimp-strace.txt

$ cat gimp-strace.txt| cut -c8-| grep -E "^(0\\.[1-9]|[1-9]\\.)"  -B2 -A2

0.000023 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.000038 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.478647 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, 478) = 0 (Timeout)
0.000093 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
0.000071 writev(3, [{iov_base="&\30\2\0\241\1\340\7", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
--
0.000110 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.000045 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.110141 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, -1) = 1 ([{fd=3, revents=POLLIN}])
0.000117 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\6\0\356\f\4\234\275\0\362\2\0\0\241\1\340\7\0\0\0\0\7\3p\1\7\3S\1\0\0\1\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
0.000051 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
--
0.000135 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.000079 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.191274 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, -1) = 1 ([{fd=3, revents=POLLIN}])
0.000079 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\7\0\363\fL\235\275\0\362\2\0\0\241\1\340\7\0\0\0\0w\5 \0w\5\3\0\0\0\0\3"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
0.000025 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
--
0.000146 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.000079 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.119622 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, 324) = 1 ([{fd=3, revents=POLLIN}])
0.000093 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\6\0\364\ft\236\275\0\362\2\0\0\241\1\340\7\0\0\0\0X\5)\0X\5\f\0\0\0\1\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
0.000074 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
--
0.000092 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, 0) = 0 (Timeout)
0.000107 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.330608 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, -1) = 1 ([{fd=3, revents=POLLIN}])
0.000164 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241 \364\f\241\1\340\7Q\1\0\0R\1\0\0\346\237\275\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
0.000142 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
--
0.000159 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21\0\31\r\241\1\340\7\241\1\340\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 992
0.000083 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
0.114501 openat(AT_FDCWD, "/home/heisenberg/.config/GIMP/2.10/menurc", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 10
0.000193 write(10, "; gimp GtkAccelMap rc-file      "..., 101) = 101
0.000170 write(10, "; (gtk_accel_path \"<Actions>/too"..., 69) = 69

Mit den ersten 5 Treffern kann ich noch nicht viel anfangen. poll. Da wartet das Programm auf Daten auf einem Socket. Da bräuchte ich vermutlich mehr Kontextzeilen, um das genauer verstehen zu können. Beim letzten Treffer wird die Datei menurc geöffnet. Also Zugriff auf SSD. Da braucht er einen kurzen Moment.

[kalle123]

10" ist natürlich gewaltig. Wenn man das mal hochrechnet, bei 10 Starts pro Tag sind das im Jahr ~ 10 Stunden! Bei einer Reduzierung auf 3" ergibt das einen Zeitgewinn von 'sagenhaften' 6 - 7 Stunden.

Sorry dafür, aber mir geht einfach der Song hier
https://www.youtube.com/watch?v=UX4MY2u8jE8
nicht aus dem Kopf, wenn ich in den thread rein schaue

KH

[whisper]

Für die inkrementellen timestamps braucht es moreutils.

Das wäre dann das Kommando:

Code: Alles auswählen

strace /usr/bin/libreoffice 2>&1 | ts -i "%.T" >lo-kde.txt

[Andi123]

Ist mir zu kompliziert, da steig ich nicht wirklich durch.
Mit 61 gehts nimmer so einfach

Hab auf meinen Z-Book 17 G2 von 2015 Manjaro installiert
Da öffnet sich LO in 1-2 Sekunden.

Auch wenn Manjaro sonst eine Katastrophe ist, zumindest auf dem Z-Book.

[Andreas O.]

Für die inkrementellen timestamps braucht es moreutils.

Das wäre dann das Kommando:

Code: Alles auswählen

strace /usr/bin/libreoffice 2>&1 | ts -i "%.T" >lo-kde.txt

Ich hänge mich hier auch mal an, da ich auch das gleiche Problem habe, u.a. mit Libreoffice, Thunderbird, Firefox, epiphany-browser, sowohl unter XFCE als auch nur unter icewm, vermutlich wurde mir bei apt autoremove irgendwas Wichtiges deinstalliert. Im Übrigen starte ich ohne Displaymanager, nur noch mit 'startx' (XOrg)
Hier nun meine relevante Ausgabe für libreoffice:

Code: Alles auswählen

00:00:00.000022 close(5)                                = 0
00:00:00.138379 futex(0x55b1ae19aa98, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1710833485, tv_nsec=607690000}, FUTEX_BITSET_MATCH_ANY
00:00:00.000076 (soffice:1307112): dbind-WARNING **: 08:31:25.496: Couldn't connect to accessibility bus: Failed to connect to socket /root/.cache/at-spi/bus_0: Keine Berechtigung
00:00:00.111658 ) = -1 ETIMEDOUT (Die Wartezeit für die Verbindung ist abgelaufen)
00:00:00.000127 futex(0x55b1ae19aaa0, FUTEX_WAKE_PRIVATE, 1) = 0
00:00:00.000045 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
00:00:00.000051 writev(3, [{iov_base="8\2\4\0\2\0\200\1\4\0\0\0fff\0C\0\5\0\1\0\200\1\2\0\200\1\36\0\221\0"..., iov_len=72}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 72
00:00:00.000038 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)

Warum zur Hölle wollen hier Programme, die als normaler User gestartet wurden auf /root zugreifen!?
Habe dazu noch das gefunden:
https://www.mail-archive.com/users@list ... 58938.html

Kann es sein, dass mich hier jemand ausspähen will?

[niemand]

Warum zur Hölle wollen hier Programme, die als normaler User gestartet wurden auf /root zugreifen!?

Interessante Frage, allerdings geht das nicht von LOo aus, sondern von einen daraus aufgerufenen Accessibility-Ding. Wenn man danach sucht, findet man diese Meldung im Kontext mit vielen verschiedenen Programmen. Hast du vielleicht mal irgendwann was in deiner X-Usersession als Root gestartet?

Auch ist dieser Teil mit 0,1s vermutlich nicht der Grund für die Verzögerung.

[debianoli]

Schon mal mit einem neu angelegten Test-User LO gestartet? Wenn es da ebenso lange dauert, liegt es an der Installation.
Wenn es dann schneller geht, an irgendeiner Altlast im $user-home

[Andreas O.]

Warum zur Hölle wollen hier Programme, die als normaler User gestartet wurden auf /root zugreifen!?

Interessante Frage, allerdings geht das nicht von LOo aus, sondern von einen daraus aufgerufenen Accessibility-Ding. Wenn man danach sucht, findet man diese Meldung im Kontext mit vielen verschiedenen Programmen. Hast du vielleicht mal irgendwann was in deiner X-Usersession als Root gestartet?

Auch ist dieser Teil mit 0,1s vermutlich nicht der Grund für die Verzögerung.

Ganz selten startete ich auch mal Programme per 'sudo', z. B. den Texteditor 'leafpad' oder den Dateimanager 'thunar' oder, als ich mal kurz ein Berechtigungsproblem beim Start hatte, auch 'xsane' (nur um kurz zu sehen, ob mein Scanner generell erkannt wird).
Wobei ich immer mehr auf Alternativprogramme wie z. B. 'mc' ausweiche, wenn ich wirkilich mal "root-Zugriff" brauche auf bestimmte Verzeichnisse/Dateien.

[heisenberg]

Code: Alles auswählen

00:00:00.000022 close(5)                                = 0
00:00:00.138379 futex(0x55b1ae19aa98, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1710833485, tv_nsec=607690000}, FUTEX_BITSET_MATCH_ANY
00:00:00.000076 (soffice:1307112): dbind-WARNING **: 08:31:25.496: Couldn't connect to accessibility bus: Failed to connect to socket /root/.cache/at-spi/bus_0: Keine Berechtigung
00:00:00.111658 ) = -1 ETIMEDOUT (Die Wartezeit für die Verbindung ist abgelaufen)
00:00:00.000127 futex(0x55b1ae19aaa0, FUTEX_WAKE_PRIVATE, 1) = 0
00:00:00.000045 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
00:00:00.000051 writev(3, [{iov_base="8\2\4\0\2\0\200\1\4\0\0\0fff\0C\0\5\0\1\0\200\1\2\0\200\1\36\0\221\0"..., iov_len=72}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 72
00:00:00.000038 recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)

Ich sehe da in der Ausgabe jetzt aber überhaupt keine wesentliche zeitliche Verzögerung.

[niemand]

Ganz selten startete ich auch mal Programme per 'sudo', z. B. den Texteditor 'leafpad' oder den Dateimanager 'thunar' oder, als ich mal kurz ein Berechtigungsproblem beim Start hatte, auch 'xsane' (nur um kurz zu sehen, ob mein Scanner generell erkannt wird).

Aus meiner Erfahrung (auch hier im Forum) heraus: das sind schon sehr viele Gelegenheiten, an denen es zu so einer Änderung der Konfiguration kommen kann. Tatsächlich reicht’s unter Umständen, einmal ein Programm unter X als Root aufzurufen – dann wird die Konfigurationsdatei mit dessen Rechten erstellt und dessen Pfade landen darin, und späteres Starten als User hat keine Chance, das geradezuziehen – gehört ja Root.

Anyway – das ist hier eh OT, und ich schließe mich heisenbergs impliziter Frage an: an welcher Stelle hängt es denn nun bei dir?

[Andreas O.]

Debianoli hat mich auf die richtige Spur gebracht. Habe mal probeweise einen neuen User angelegt, jetzt "flutscht" wieder alles wie gewohnt
Mal sehen, wie ich das so "umziehe", bzw. repariere, damit ich möglichst wenig Arbeit habe, aber trotzdem alle "Altlasten" los werde...

Das Startbild von LibreOffice mit dem Fortschrittsbalken lief beim alten User gefühlt eine halbe Minute lang, bis ich überhaupt damit arbeiten konnte.
Andere Programme wie Firefox oder Thunderbird, die ja nicht unbedingt so einen "Fortschrittsbalken" haben, starteten dann eben auch erst gefühlt nach einer halben Minute, wo ich gar nicht mehr mit einem Start gerechnet hatte.
Selbst Spezialprogramme wie "ecoDMS" starteten sehr spät (mit Fortschrittsanzeige ähnlich wie LibreOffice), die Datenbank war anschließend nur noch schleppend zu bedienen.

Da habe ich mir, wie auch immer, wohl mein altes "home" zerschossen.
Anfangs hatte ich die SATA-SSD, die aber noch nicht so alt ist, im Verdacht - her fand ich weder im Dateisystem (ext4) noch auf den Speicherzellen selbst (Langtest mit smartctl) einen Fehler.

[KP97]

Das Startbild von LibreOffice mit dem Fortschrittsbalken lief beim alten User gefühlt eine halbe Minute lang,

Das kann man ausstellen, das braucht man nicht.
In /etc/libreoffice/sofficerc in Zeile 4 Logo=0 eintragen, als root natürlich, dann wird das nicht mehr ausgeführt und der Start geht schneller.

[Andreas O.]

Das Startbild von LibreOffice mit dem Fortschrittsbalken lief beim alten User gefühlt eine halbe Minute lang,

Das kann man ausstellen, das braucht man nicht.
In /etc/libreoffice/sofficerc in Zeile 4 Logo=0 eintragen, als root natürlich, dann wird das nicht mehr ausgeführt und der Start geht schneller.

Das Logo an sich war nicht das (Haupt-)Problem. Trotzdem danke.

[Andreas O.]

Nachdem nun plötzlich der neue User auch die gleichen Probleme hatte wie der alte, habe ich nun doch noch den Tipp von KP97 ausprobiert.
Ursprünglich dachte ich mir, wenn die Programme wieder ordentlich schnell laufen, spielt es für mich keine Rolle mehr, ob nun LO durch Deaktivieren des Logos ggf. nochmal um 1 oder 2 Sekunden schneller startet oder nicht.
Und siehe da, jetzt flutscht es sowohl beim neuen als auch beim alten User wieder.
Was das Deaktivieren des LO-Logos allerdings mit den Startproblemen der anderen Programme zu tun hatte, verstehe ich leider überhaupt nicht
Wie dem auch sei, ist von meiner Seite das Problem nun gelöst.