| View previous topic :: View next topic |
| Author |
Message |
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
 Posted: Sat Mar 29, 2014 9:28 pm Post subject: |
 |
|
A visible problem, though irrelevant; is this one, you might want to get that checked out if you need to use a SD card:
| Quote: | [ 8.462284] sdhci [sdhci_add_host()]: mmc0: Auto-CMD23 unavailable
[ 8.462312] sdhci: =========== REGISTER DUMP (mmc0)===========
[ 8.462364] sdhci: Sys addr: 0x00000000 | Version: 0x00000400
[ 8.462370] sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[ 8.462375] sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[ 8.462380] sdhci: Present: 0x01f20000 | Host ctl: 0x00000000
[ 8.462385] sdhci: Power: 0x00000000 | Blk gap: 0x00000000
[ 8.462390] sdhci: Wake-up: 0x00000000 | Clock: 0x00000000
[ 8.462395] sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[ 8.462400] sdhci: Int enab: 0x00ff0003 | Sig enab: 0x00ff0003
[ 8.462405] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 8.462410] sdhci: Caps: 0x01e032b2 | Caps_1: 0x00000000
[ 8.462416] sdhci: Cmd: 0x00000000 | Max curr: 0x00000040
[ 8.462418] sdhci: Host ctl2: 0x00000000
[ 8.462419] sdhci: =========================================== |
There is also later a reconnect going on with the wireless; it shouldn't be doing this, I've also tried to notice when the network starts as well as when it does the next thing.
| Quote: | [ 13.804338] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 31.117547] type=1006 audit(1396113786.891:2): pid=317 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=1 res=1 |
There's about a 18 seconds between that; so, I think the network is delaying part of your boot, unless you wait that much before logging in.
It still doesn't explain why GNOME is starting slower on the first run though, as the only jump later seen is this:
| Quote: | [ 39.514020] wlan0: Stopping Tx BA session for 74:44:01:2e:ed:de tid 0
[ 208.289426] wlan0: Open BA session requested for 74:44:01:2e:ed:de tid 6 |
Which is just network doing its thing.
I'm a bit confused why there's nothing visible about this. Did you extract this information after executing `startx`?
If so, I think that your Intel graphics module is having a hard time switching resolution the first time; why it is doing that, no idea...
Consider to file a bug upstream with them about this; besides that, trying a long term kernel release of a different branch (for example, 3.4.83) can help too see whether this is a regression in the kernel or the Intel module therein.
As a temporary measure, using `systemd-analyze blame` as well as `systemd-analyze critical-chain` as well as `/bin/dmesg -d | sort -nk4` after boot to pinpoint why the rest of your boot is slow can help; iotw, instead of fixing 12 seconds inside the graphical target, you could make the other part of your boot 12 seconds faster. |
|
| Back to top |
|
 |
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sat Mar 29, 2014 9:44 pm Post subject: |
|
|
| If it is issue with switching resolution by Intel, why it is happen only in gnome? In fluxbox it does not |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sat Mar 29, 2014 9:58 pm Post subject: |
|
|
| gentoo2x wrote: | | If it is issue with switching resolution by Intel, why it is happen only in gnome? In fluxbox it does not |
Eh, sorry, I'm again confusing your topic with another topic with something similar going on; we're both reading between the lines.
You might recall ulenrich's comment explaining this earlier in this topic, you could use a login manager instead of startx per this quote:
| ulenrich wrote: | cannot initialize any of logind, which is part of systemd. Because Gnome is not in any way configured to run without systemd (Gentoo maintainers follow a cosy and lazy approach here), it is probably timing out any systemd related expectation.
Also it is stated by systemd upstream they don't want to support "startx" in the near future any more. An alternative is to use a cheap DM replacement such as no-dm, but this is dead now. There is a similar project I have forgotten the name on github. |
The reason that startx might work right away the second time is because it knows not to timeout again; or in other words, it might have set something up in one or another directory (/run, /tmp or /var) that it can just reuse. |
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 8:02 am Post subject: |
|
|
I tried remove all from /tmp but nothing has changed. Behaviour is still the same.
I also tried to use GDM as login manager but then it is the same thing but the delay is before start GDM, and about 10 seconds after login to start Gnome.
I don't know what could I delete from /run or /var ? |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 30, 2014 8:37 am Post subject: |
|
|
| gentoo2x wrote: | | I tried remove all from /tmp but nothing has changed. Behaviour is still the same. |
Uhm, no, the files I was talking about actually help, as they remember what GNOME did such that its second launch works better; I just don't know where they are stored.
| gentoo2x wrote: | | I also tried to use GDM as login manager but then it is the same thing but the delay is before start GDM, and about 10 seconds after login to start Gnome. |
How do you start GDM? Using systemd? It might be waiting for another target to finish first, like the network; the 10 seconds after the login is harder.
First, try to enable GDM debugging by enabling debug/Enable in /etc/gdm/custom.conf; after that, reboot, start gdm and then your `journalctl -rb` output should contain much more information about GDM starting up (and I think GNOME shell too).
Second, if you want to go a step further. Programmers would usually debug this by attaching a tracer to the process; first `emerge dev-util/strace sys-process/procps`, then put the following in a script:
| Code: | | while true ; do if [[ $(pgrep gdm$) ]] ; then strace -f -p $(pgrep gdm$) -tt -s250 > /tmp/strace.log ; break ; fi ; done |
(The script sits in a loop, waits for the gdm process to exist; then it attaches the tracer to the gdm process, also tracing its forks (-f), outputting timestamps (-tt) and shows increased string size (-s250). When it is done it will break out of the loop.)
Then you can run that, after which you in another TTY can start gdm through systemctl; this will then attach as soon as it detects the gdm process. After which you can login, then come back to the TTY and copy the /tmp/strace.log file to a permanent location and then stop the command in the first terminal with CTRL+C.
If the slowdown is _after_ it switches to the GNOME shell, you could also try to only trace gnome-shell by replacing gdm$ by gnome-shell$; like this:
| Code: | | while true ; do if [[ $(pgrep gnome-shel$) ]] ; then strace -f -p $(pgrep gnome-shell$) -tt -s250 > /tmp/strace.log ; break ; fi ; done |
The trace goes into the details of the system calls; so, it requires some patience and research to read through it. Understanding mostly by the I/O related calls what it is doing at certain times; then finding the time where it hangs, which will reveal what it was waiting for (and sometimes you see it writing something to standard output or a log around that point).
| gentoo2x wrote: | | I don't know what could I delete from /run or /var ? |
Nothing, there is important stuff in there. |
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 9:58 am Post subject: |
|
|
I assumed that after removing everything from /tmp second run gnome should also take 40 seconds to load, but no it was 3 seconds. So your assumption that gnome caches sth in /tmp is incorrect.
I will try with GDM... and your suggestion |
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 10:09 am Post subject: |
|
|
With GDM by systemd:
Start to GDM took about 26 second.
Start to Gnome from GDM took 12 seconds
So pretty the same situation as from startx
thinkpad waksiu # systemd-analyze blame
6.831s systemd-udev-settle.service
6.250s NetworkManager.service
5.939s accounts-daemon.service
3.641s wpa_supplicant.service
3.640s systemd-logind.service
3.633s gdm.service
2.088s systemd-fsck-root.service
1.343s systemd-modules-load.service
1.147s mnt-dyskd.mount
1.094s kmod-static-nodes.service
1.047s polkit.service
915ms dev-hugepages.mount
889ms dev-mqueue.mount
833ms systemd-vconsole-setup.service
832ms sys-kernel-debug.mount
763ms tmp.mount
762ms systemd-sysctl.service
622ms user@105.service
609ms systemd-udev-trigger.service
564ms colord.service
406ms systemd-backlight@acpi_video0.service
263ms systemd-random-seed.service
237ms lvm2-activation-early.service
204ms gentoo-local-baselayout1.service
199ms udisks2.service
171ms systemd-tmpfiles-setup-dev.service
155ms var-lock.mount
141ms systemd-remount-fs.service
121ms systemd-user-sessions.service
119ms systemd-localed.service
112ms user@1000.service
100ms systemd-journal-flush.service
96ms home.mount
76ms systemd-udevd.service
72ms systemd-update-utmp.service
45ms dev-sda2.swap
43ms lvm2-activation-net.service
41ms systemd-tmpfiles-setup.service
40ms upower.service
32ms lvm2-activation.service
27ms rtkit-daemon.service
22ms sys-fs-fuse-connections.mount
21ms alsa-restore.service
5ms var-run.mount
5ms systemd-fsck@dev-sda6.service |
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 30, 2014 10:43 am Post subject: |
|
|
Most of the log seems to go fine (reading from the bottom up), as the seconds follow up on each other; but, there are two big jump here:
| Quote: | mar 30 11:00:30 thinkpad gnome-session[820]: (google-chrome-stable:1073): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-button-images after class was initialised
mar 30 11:00:22 thinkpad systemd-logind[310]: Removed session c1.
mar 30 11:00:10 thinkpad gnome-session[820]: Entering running state |
But 11:00:30 is your browser already; so, you might be able to remember what you did before launching the browser and know whether the 12 seconds delay was 10 seconds before starting the browser? It could very well also be a false positive if you switched to the TTY or so. I'm going to assume it is because of these thought.
So, I went to check when the last service started as well as when GNOME shell reports itself a loaded:
| Quote: | mar 30 10:59:45 thinkpad /usr/bin/dbus-launch[495]: Gjs-Message: JS LOG: GNOME Shell started at Sun Mar 30 2014 10:59:45 GMT+0200 (CEST)
mar 30 10:59:33 thinkpad systemd[1]: Started Locale Service. |
Ah, 12 seconds. 6 second seem lost here:
| Quote: | mar 30 10:59:44 thinkpad /usr/bin/dbus-launch[495]: gnome-session[495]: DEBUG(+): GsmDBusClient: obj_path=/org/gnome/SessionManager/Presence interface=org.freedesktop.DBus.Properties method=GetAll
mar 30 10:59:38 thinkpad gnome-session[495]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged |
That is some dbus talk between the proceses; so, maybe there's something going on with that. Did you follow the documentation when setting up GNOME?
There's another 2 seconds that seem lost here:
| Quote: | mar 30 10:59:36 thinkpad /usr/bin/dbus-launch[495]: gnome-session[495]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged
mar 30 10:59:34 thinkpad gnome-session[495]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged |
As for the remaining 4 seconds, these seem fine; it just seems as if there is some trouble going on between the processes, as around that time in the log it kinda repeats this a lot. To know what is happening between the processes, you'll need to use strace to see what they are doing; as the messages themselves don't say much about why the messages are sent, you could only tell that by checking what the I/O is doing around the time the message are send. Some of these separate processes don't log enough information to debug them without strace...
On a side note, at the top of the log there is a message flooding that you'll also want to look into, but you would need (with a fresh log) check what proces the pid 1543 number (but instead the number of the new log) corresponds to; see this:
| Quote: | | mar 30 11:01:29 thinkpad gnome-session[820]: unnamed app(1543) KMimeTypePrivate::ensureXmlDataLoaded: Missing <comment> field in "text/x-component.xml" |
|
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 11:03 am Post subject: |
|
|
With your:
while loop I get:
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Operation not permitted
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
unnamed app is chrome so ignore this errors. I should not start browser so fast, it obscures logs. |
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 11:14 am Post subject: |
|
|
sorry, your script works (after restart), but the file /tmp/strace.log is empty  after starting gdm |
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 11:20 am Post subject: |
|
|
| This gentoo instalation has about 3 years old, and I installed gnome by simple emerge, since I've updated my system by emerge --update world from time to time. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 30, 2014 11:38 am Post subject: |
|
|
| gentoo2x wrote: | | This gentoo instalation has about 3 years old, and I installed gnome by simple emerge, since I've updated my system by emerge --update world from time to time. |
Hmm, you'll want to follow the associated guides:
https://wiki.gentoo.org/wiki/Systemd
https://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide#Installation
Here are slowdowns I see in the new log:
| Quote: | mar 30 12:11:51 thinkpad gnome-session[2415]: (tracker-store:2574): Tracker-CRITICAL **: D-Bus service name:'org.freedesktop.Tracker1' is already taken, perhaps the daemon is already running?
mar 30 12:11:48 thinkpad gnome-session[2415]: Entering running state |
3 seconds to try to start tracker (but it service name is already taken)
| Quote: | mar 30 12:11:48 thinkpad gdm[2105]: AccountsService: ActUserManager: new user in accounts service with object path /org/freedesktop/Accounts/User0
mar 30 12:11:46 thinkpad gnome-session[2415]: Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. |
2 seconds for the new uer
| Quote: | mar 30 12:11:43 thinkpad goa[2529]: goa-daemon version 3.10.2 starting [main.c:117, main()]
mar 30 12:11:39 thinkpad colord[2234]: Profile added: icc-bf6a95f4cd6beb6c45c792659bda2af8 |
4 seconds to start the gnome online accounts daemon; if you don't need this, set -gnome-online-accounts in USE in make.conf and you might spare out 4 seconds.
| Quote: | mar 30 12:11:36 thinkpad gdm[2105]: GdmSessionWorker: trying to get updated username
mar 30 12:11:34 thinkpad gdm[2105]: GdmSessionWorker: received pam message of type 1 with payload 'Password: ' |
2 seconds to talk with PAM, I think that's still reasonable; though you might want to check out https://wiki.gentoo.org/wiki/Systemd#systemd-logind_.26_pam_systemd
| Quote: | mar 30 12:11:34 thinkpad gdm[2105]: GdmManager: trying to open reauthentication channel for user waksiu
mar 30 12:11:32 thinkpad gdm[2105]: AccountsService: ActUserManager: user root changed |
2 seconds to do some kind of reauthentication channel, nothing special to see here
Then there's a lot of seconds going on in the earlier dbus talk; as you can see, there's quite a jump of 9 seconds here:
| Quote: | mar 30 12:11:28 thinkpad /usr/bin/dbus-launch[2138]: gnome-session[2138]: DEBUG(+): GsmDBusClient: obj_path=/org/gnome/SessionManager/Presence interface=org.freedesktop.DBus.Properties method=GetAll
mar 30 12:11:19 thinkpad gnome-session[2138]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged |
and another 4 seconds here:
| Quote: | mar 30 12:11:19 thinkpad /usr/bin/dbus-launch[2138]: gnome-session[2138]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged
mar 30 12:11:16 thinkpad gnome-session[2138]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged |
Compared to all the other smaller seconds, it seems like the 4 seconds (goa) and the 13 seconds (dbus talk) take up a lot of time; so, we'll want to do the strace:
| gentoo2x wrote: | | sorry, your script works (after restart), but the file /tmp/strace.log is empty after starting gdm |
Yeah, sorry, it has been a while; it needs to be with -o instead of >:
| Code: | | while true ; do if [[ $(pgrep gdm$) ]] ; then strace -f -p $(pgrep gdm$) -tt -s250 -o /tmp/strace.log ; break ; fi ; done |
|
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 12:23 pm Post subject: |
|
|
fragment of strace.log
http://pastebin.com/zb131z9w
how can I send you the full file? it's too large to pastebin |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 30, 2014 3:09 pm Post subject: |
|
|
| You can send a mail at TomWij <at> gentoo.org; I see it is writing logs in /var/log/gdm/, feel free to tarball those and send them too. |
|
| Back to top |
|
|
gentoo2x
n00b
Joined: 23 Mar 2014
Posts: 20
|
| Posted: Sun Mar 30, 2014 5:26 pm Post subject: |
|
|
Here also we can see that 14 seconds:
systemctl status gdm
gdm.service - GNOME Display Manager
Loaded: loaded (/usr/lib64/systemd/system/gdm.service; disabled)
Active: active (running) since nie 2014-03-30 17:50:17 CEST; 34min ago
Main PID: 646 (gdm)
CGroup: /system.slice/gdm.service
├─646 /usr/sbin/gdm
├─649 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_0
└─653 /usr/bin/Xorg :0 -background none -verbose -logverbose 7 -core -auth /run/gdm/auth-for-gdm-XFA7QR/database -seat seat0 -nolisten tcp vt7
mar 30 17:50:56 thinkpad gdm[646]: AccountsService: ActUserManager: tracking user 'root'
mar 30 17:50:56 thinkpad gdm[646]: AccountsService: ActUserManager: loaded, so emitting user-added signal
mar 30 17:50:56 thinkpad gdm[646]: AccountsService: ActUserManager: no pending users, trying to set loaded property
mar 30 17:50:56 thinkpad gdm[646]: AccountsService: ActUserManager: already loaded, so not setting loaded property
mar 30 17:50:56 thinkpad gdm[646]: AccountsService: ActUserManager: user root changed
mar 30 17:51:10 thinkpad gdm[646]: AccountsService: ActUserManager: tracked user /org/freedesktop/Accounts/User0 removed from accounts service
mar 30 17:51:10 thinkpad gdm[646]: AccountsService: ActUserManager: no longer tracking user 'root' (with object path /org/freedesktop/Accounts/User0)
mar 30 17:51:10 thinkpad gdm[646]: AccountsService: ActUserManager: loaded, so emitting user-removed signal
mar 30 17:51:10 thinkpad gdm[646]: AccountsService: ActUserManager: user waksiu changed
mar 30 17:51:10 thinkpad gdm[646]: AccountsService: ActUserManager: user wax changed |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 30, 2014 5:55 pm Post subject: |
|
|
From your first post I based myself on this:
| Quote: | [ 39.764] (**) Option "xkb_layout" "pl"
[ 53.875] (II) intel(0): EDID vendor "LEN", prod id 16438 |
Used the range between these two and have them form a text range, removing everything before the xkb_layout (@ :21) and removing everything after the EDID vendor (@ :31).
Next, I look for case insensitive for the word warning or error (after having been bored scrolling through the file a few times not noticing a clear stall); what I notice is:
| Quote: | 830 13:06:22.529869 write(2, "<7>AccountsService: Error calling GetAll() when retrieving properties for /org/freedesktop/Accounts/User105: Operation was cancelled\n", 133 <unfinished ...>
830 13:06:22.529936 write(2, "<7>AccountsService: Error calling GetAll() when retrieving properties for /org/freedesktop/Accounts/User105: Operation was cancelled\n", 133) = 133 |
There are a lot of other dbus warnings and errors too; but the tricky thing there is, they are not always errors. On the other hand, the above looks somewhat worrying because an operation was cancelled, which caused properties retrieval to fail for User105 (which could be your user). It's doing something quite specific; so, for it to fail sounds bad.
When we put that in the context of your `systemctl status gdm` call, you'll notice again that AccountsService is playing a role here:
| Quote: | mar 30 17:50:56 thinkpad gdm[646]: AccountsService: ActUserManager: user root changed
mar 30 17:51:10 thinkpad gdm[646]: AccountsService: ActUserManager: tracked user /org/freedesktop/Accounts/User0 removed from accounts service |
If I look at that in my log, I see the first one happen (@ :21) not long before the operation gets cancelled.
This leads me to believe the AccountsService isn't functioning well; however, I can't find a specific error after the time break (as that's where the error would be supposed to be).
What I do find at random points is:
| Quote: | 849 13:06:25.402662 write(2, "\n** (at-spi2-registryd:849): WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files\n", 196 <unfinished ...>
849 13:06:25.402726 write(2, "\n** (at-spi2-registryd:849): WARNING **: Unable to register client with session manager\n", 88 <unfinished ...> |
| Quote: | 835 13:06:30.722854 writev(2, [{"gnome-session[835]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged\n", 131}], 1 <unfinished ...>
835 13:06:30.723967 writev(2, [{"gnome-session[835]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged\n", 131}], 1) = 131 |
Yeah, well, some different warning and errors every few seconds; we can also find when gnome-shell itself starts:
| Quote: | | 835 13:06:27.930118 writev(2, [{"gnome-session[835]: DEBUG(+): GsmAutostartApp: starting gnome-shell.desktop: command=gnome-shell --mode=gdm startup-id=107b986ad861cfc9af139617758591569400000008350000\n", 168}], 1 <unfinished ...> |
So, to summarize I see that @ :21 the last Xorg message before the gap kicks in as well as the last AccuntsService message, @ :22 AccountsService throws an error, @ :25 we get warnings from at-spi2, @ :27 gnome-shell starts and @ :30 there is some DBUS stuff going on. I kinda get the impression that there's no single big problem; but rather, there are smaller problems causing a bit of delay.
There are more warnings and errors going on outside that range; for instance, the following looks concerning (gnome-settings-daemon and gconf are somewhat more important, as well as at-spi2 again):
| Quote: | 856 13:06:51.486801 write(2, "\n(gnome-settings-daemon:856): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon: The connection is closed\n", 123 <unfinished ...>
1067 13:06:51.526173 write(2, "\n(process:1067): GConf-WARNING **: Got Disconnected from DBus.\n\n", 64 <unfinished ...>
1137 13:06:52.239544 write(2, "\n** (at-spi2-registryd:1137): WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files\n", 197 <unfinished ...>
1137 13:06:52.239605 write(2, "\n** (at-spi2-registryd:1137): WARNING **: Unable to register client with session manager\n", 89 <unfinished ...> |
It's hard to pinpoint something specific here; therefore I suggest you 1) make sure you did everything according to documentation (set a gnome and/or systemd profile with eselect, for example default/linux/amd64/13.0/desktop/gnome/systemd), 2) start from a new install or 3) file a bug upstream for the upstream developers to check your strace out.
The troubleshooting approach would be to go further and research every warning and error; but given not every warning or error is fatal, quite some time can get into that (days to weeks). At which point it is easier to check documentation, start clean and/or contact upstream. If needed, you can file a bug upstream at https://bugzilla.gnome.org/ |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
