GNOME Bugzilla – Bug 780801
starting gnome after login causes endless loop
Last modified: 2017-06-24 10:43:21 UTC
what florian suggested here: Bug774774 does not work any more now. putting # start graphical UI on login to tty1 if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session fi ends with an endless loop. the error beeing in the lines of "ignoring child process ..." "cannot init inotify ..." when launching it from the command line after logging in the error is Activating service name='org.freedesktop.systemd1' Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 described here: https://github.com/systemd/systemd/issues/5247 what changed in gnome-shell resp how can it be configured to do what it did 2 months ago? or is this systemd? (mark critical for running without gdm, but not critical otherwise i guess ...)
(In reply to soloturn from comment #0) > what changed in gnome-shell resp how can it be configured to do what it did > 2 months ago? or is this systemd? No idea. You are basically implementing your own login manager which is perfectly fine, but it means you'll have to figure out stuff yourself.
(In reply to Florian Müllner from comment #1) > (In reply to soloturn from comment #0) > > what changed in gnome-shell resp how can it be configured to do what it did > > 2 months ago? or is this systemd? > > No idea. You are basically implementing your own login manager which is > perfectly fine, but it means you'll have to figure out stuff yourself. i guess i do not understand, i am just using the standard /lib/systemd/system/getty\@.service to log in. gdm does the same isn't it? how do you start gnome-shell currently from the command line? or, what does gdm call when i log in?
i googled what this inotify error means, and increased the max_user_watches from 8000: echo fs.inotify.max_user_watches=524288 | sudo tee /etc/sysctl.d/40-max-user-watches.conf && sudo sysctl --system
I suspect that the issue is caused by the `dbus-run-session` process somehow sourcing `.bash_profile` (`.zprofile` in my case) again, so each message indicates a exec. I avoided this issue by appending && [[ -z $XDG_SESSION_TYPE ]] to the condition.
closing, thanks for the comment yu!