| Summary: | x11-base/xorg-server: gnome-base/gdm-3.8 will not restart with /etc/int.d/xdm restart | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Harris Landgarten <harrisl> |
| Component: | New packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | drunkenbatman, gnome, hasufell, lxnay, markpariente, openrc, vampireofsengir |
| Priority: | Normal | ||
| Version: | 10.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugzilla.gnome.org/show_bug.cgi?id=700152 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 471016, 475194 | ||
| Bug Blocks: | 463242 | ||
| Attachments: |
gdm-3.8.0.ebuild.diff
xdm-init.diff xdm-init.diff |
||
|
Description
Harris Landgarten
2013-03-30 01:51:49 UTC
(In reply to comment #0) > gdm-3.8 does not work properly with /etc/init.d/xdm from xorg-server. First > the pid file is created in /run/gdm/gdm.pid but the xdm init.d file > references /var/run/gdm.pid. > > I also could not kill /usr/bin/gdm even with kill -9 once started. > > While gdm does start with /etc/init.d/xdm start it does not stop or restart. Add --with-pid-file="${EPREFIX}"/var/run/${PN}.pid configure option? Created attachment 343702 [details, diff]
gdm-3.8.0.ebuild.diff
I am unsure about if we should keep adapting to unchanged xdm init.d script or adapt script to gdm3:
gdm|gnome)
EXE=/usr/bin/gdm
[ "${RC_UNAME}" != "Linux" ] && NAME=gdm-binary
PIDFILE=/var/run/gdm.pid
;;
-> Currently we are needing to symlink to get /usr/bin/gdm, and /var/run is deprecated in favor of /run
The problem is how to deal with old gdm
@gnome, do you have any ideas?
while you are looking at GDM. I have in issue with it changing the order of monitors when it starts. Do you want a new bug? (In reply to comment #4) > while you are looking at GDM. I have in issue with it changing the order of > monitors when it starts. Do you want a new bug? Yes, but please note there how are you starting gdm and it it behaves in the same way when running "/etc/init.d/xdm start" or "gdm" (In reply to comment #2) > Created attachment 343702 [details, diff] [details, diff] > gdm-3.8.0.ebuild.diff It neither works because it kills gdm pid, but all gnome-shell stuff keeps running and, then, it fails when restarting Probably systemd is controlling gdm processes in some way, not sure if it's possible to control processes launched by gdm with openrc :/ OK, it can be killed running "kill -- -<pid>"... but not sure how to end running that using start-stop-daemon :/ (In reply to comment #8) > OK, it can be killed running "kill -- -<pid>"... but not sure how to end > running that using start-stop-daemon :/ Other option would be to enhance /etc/init.d/xdm to be able to run custom stop commands (well... I even think we should have one init script per dm like very other distro does... but) symlink /var/run > /run Created attachment 349294 [details, diff]
xdm-init.diff
(In reply to Pacho Ramos from comment #11) > Created attachment 349294 [details, diff] [details, diff] > xdm-init.diff @x11, please review this diff against current init.d xdm script to allow it to work with new gdm, this will require to be bumped on all major xorg-server versions (due bug 464848 and bug 356915) together with fixed gdm-3.8 once openrc team releases an openrc version with fixed cgroups support. Created attachment 349296 [details, diff]
xdm-init.diff
Ooops, this uses /run instead of relying on /var/run symlink ;)
> +MY_XDM=$(echo "${DISPLAYMANAGER}" | tr '[:upper:]' '[:lower:]')
> +if [ ${MY_XDM} == gdm ] || [ ${MY_XDM} == gnome ]; then
> + rc_cgroup_cleanup="yes";
Does that really have to be set in global scope? If yes then at least don't call tr in global scope but use ${DISPLAYMANAGER,,} or similar.
(In reply to Chí-Thanh Christopher Nguyễn from comment #14) > > +MY_XDM=$(echo "${DISPLAYMANAGER}" | tr '[:upper:]' '[:lower:]') > > +if [ ${MY_XDM} == gdm ] || [ ${MY_XDM} == gnome ]; then > > + rc_cgroup_cleanup="yes"; > > Does that really have to be set in global scope? If yes then at least don't > call tr in global scope but use ${DISPLAYMANAGER,,} or similar. Will let openrc people to confirm if it's really needed to export rc_cgroup_cleanup at global scope (In reply to Pacho Ramos from comment #15) > (In reply to Chí-Thanh Christopher Nguyễn from comment #14) > > > +MY_XDM=$(echo "${DISPLAYMANAGER}" | tr '[:upper:]' '[:lower:]') > > > +if [ ${MY_XDM} == gdm ] || [ ${MY_XDM} == gnome ]; then > > > + rc_cgroup_cleanup="yes"; > > > > Does that really have to be set in global scope? If yes then at least don't > > call tr in global scope but use ${DISPLAYMANAGER,,} or similar. > > Will let openrc people to confirm if it's really needed to export > rc_cgroup_cleanup at global scope Really in should be set at the moment of 'stop' end. So any place than will guarantee this should work, e.g. it's safe to set it in stop() function. I really doesn't like using concrete program names and logic switches based on them in init script itself, as it can end-up in a messy init script. And it's safe to set in in conf.d and update conf.d only in user installs gdm. However if you think that init.d in more appropriate place for it I have no objections. (In reply to Alexander Vershilov from comment #16) > (In reply to Pacho Ramos from comment #15) > > (In reply to Chí-Thanh Christopher Nguyễn from comment #14) > > > > +MY_XDM=$(echo "${DISPLAYMANAGER}" | tr '[:upper:]' '[:lower:]') > > > > +if [ ${MY_XDM} == gdm ] || [ ${MY_XDM} == gnome ]; then > > > > + rc_cgroup_cleanup="yes"; > > > > > > Does that really have to be set in global scope? If yes then at least don't > > > call tr in global scope but use ${DISPLAYMANAGER,,} or similar. > > > > Will let openrc people to confirm if it's really needed to export > > rc_cgroup_cleanup at global scope > > Really in should be set at the moment of 'stop' end. So any place than will > guarantee this should work, e.g. it's safe to set it in stop() function. I haven't tested something like this, but it may work. I would tend to set it in global scope though to be safe. (In reply to William Hubbs from comment #17) > (In reply to Alexander Vershilov from comment #16) > > (In reply to Pacho Ramos from comment #15) > > > (In reply to Chí-Thanh Christopher Nguyễn from comment #14) > > > > > +MY_XDM=$(echo "${DISPLAYMANAGER}" | tr '[:upper:]' '[:lower:]') > > > > > +if [ ${MY_XDM} == gdm ] || [ ${MY_XDM} == gnome ]; then > > > > > + rc_cgroup_cleanup="yes"; > > > > > > > > Does that really have to be set in global scope? If yes then at least don't > > > > call tr in global scope but use ${DISPLAYMANAGER,,} or similar. > > > > > > Will let openrc people to confirm if it's really needed to export > > > rc_cgroup_cleanup at global scope > > > > Really in should be set at the moment of 'stop' end. So any place than will > > guarantee this should work, e.g. it's safe to set it in stop() function. > > I haven't tested something like this, but it may work. > I would tend to set it in global scope though to be safe. If it's safer... no problem. In that case, I guess we won't lose anything using ${DISPLAYMANAGER,,} instead of "tr", no? :/ Fabio is needing this patch in openrc too: https://raw.github.com/Sabayon/sabayon-distro/master/sys-apps/openrc/files/0001-Filter-the-systemd-cgroup-from-the-current-process.patch (In reply to Pacho Ramos from comment #19) > Fabio is needing this patch in openrc too: > https://raw.github.com/Sabayon/sabayon-distro/master/sys-apps/openrc/files/ > 0001-Filter-the-systemd-cgroup-from-the-current-process.patch can we have a separate bug on this? As this is quite orthogonal to current problem. I have a talk with William where he argued that he want openrc process to be in service cgroup for a reason. As for me I don't like any systemd or any other tool hardcoding in openrc, at least in runscript. There are better solutions. It seems pretty clear where upstream gnome is going on this issue. If you are using gnome >=3.8 systemd is a requirement because logind is not supported on non-systemd hosts [1]. After discussion with the gnome team it seems they are going to go that way as well, so do I need to do anything more on this bug? [1] http://bugs.freedesktop.org/show_bug.cgi?id=66018#C9 Who you talked from gnome team about Gnome 3.8? The idea was to try to support logind without systemd at least for Gnome 3.8 as Debian/Ubuntu are doing. Also, sticking with consolekit for the rest of stuff will also lead to problems as it's now completely dead from upstream (Debian people were taking care of that, but now that they are moving to logind + upstart...) I wrote a systemd-shim ebuild here: https://github.com/Sabayon/systemd-love/tree/master/sys-apps/systemd-shim It needs this patch in the systemd ebuild though: https://raw.github.com/Sabayon/systemd-love/master/sys-apps/systemd/files/0002-Wrap-org.freedesktop.systemd1-dbus-service-using-sys.patch With the systemd ebuild in the systemd-love overlay (and its dependencies from there, namely: udev-init-scripts and systemd-shim), you can use systemd as device manager and still boot the system with openrc, have logind (with the sys-apps/openrc ebuild from systemd-love as well) and hibernate/suspend/poweroff/reboot (through systemd-shim) working. I have no problem if gnome@ decide to make systemd a hard requirement but at least, with my "naive" patches and fixes everything works with GNOME 3.8... (In reply to Fabio Erculiani from comment #24) > With the systemd ebuild in the systemd-love overlay (and its dependencies > from there, namely: udev-init-scripts and systemd-shim), you can use systemd > as device manager and still boot the system with openrc, have logind (with > the sys-apps/openrc ebuild from systemd-love as well) and > hibernate/suspend/poweroff/reboot (through systemd-shim) working. > > I have no problem if gnome@ decide to make systemd a hard requirement but at > least, with my "naive" patches and fixes everything works with GNOME 3.8... Correct solution will be to add a configuration option that will set default hierarchy for each controller. Possible options will be: none # set nothing, default service # set process inside openrc_service top # set service to root of the controller so for logind it will be: controller_group="systemd:top" This will solve an issue and will be scalable. I'll work on the patches on this week. Is it really related to this bug? Other options and better names are weclome. (In reply to Alexander Vershilov from comment #25) > (In reply to Fabio Erculiani from comment #24) > > With the systemd ebuild in the systemd-love overlay (and its dependencies > > from there, namely: udev-init-scripts and systemd-shim), you can use systemd > > as device manager and still boot the system with openrc, have logind (with > > the sys-apps/openrc ebuild from systemd-love as well) and > > hibernate/suspend/poweroff/reboot (through systemd-shim) working. > > > > I have no problem if gnome@ decide to make systemd a hard requirement but at > > least, with my "naive" patches and fixes everything works with GNOME 3.8... > > Correct solution will be to add a configuration option that will set default > hierarchy for each controller. Possible options will be: > > none # set nothing, default > service # set process inside openrc_service > top # set service to root of the controller > > so for logind it will be: > > controller_group="systemd:top" > > This will solve an issue and will be scalable. > > I'll work on the patches on this week. > > Is it really related to this bug? Other options and better names are weclome. I have a patch I'm about to commit to OpenRc which does the following: 1. Services are always added to the /sys/fs/cgroup/openrc cgroup so that we can track them. 2. Also, if a /sys/fs/cgroup/systemd cgroup exists, it adds each service to the systemd/system cgroup to mirror how system is currently behaving. Looks really promising, thanks a lot! (In reply to Pacho Ramos from comment #27) > Looks really promising, thanks a lot! After talking with Fabio, looks like that approach fails, while applying: https://github.com/Sabayon/systemd-love/blob/master/sys-apps/openrc/files/0001-Filter-the-systemd-cgroup-from-the-current-process.patch solves this Can you look at this? (In reply to Pacho Ramos from comment #28) > (In reply to Pacho Ramos from comment #27) > > Looks really promising, thanks a lot! > > After talking with Fabio, looks like that approach fails, while applying: > https://github.com/Sabayon/systemd-love/blob/master/sys-apps/openrc/files/ > 0001-Filter-the-systemd-cgroup-from-the-current-process.patch > > solves this > > Can you look at this? we already have https://github.com/OpenRC/openrc/commit/2391ddff772ce541bc2237c89a2792a0b85e076c that solves current solution as is better. That solution is also a workaround but I will go unless we will have correct solution. (In reply to Pacho Ramos from comment #28) > (In reply to Pacho Ramos from comment #27) > > Looks really promising, thanks a lot! > > After talking with Fabio, looks like that approach fails, while applying: > https://github.com/Sabayon/systemd-love/blob/master/sys-apps/openrc/files/ > 0001-Filter-the-systemd-cgroup-from-the-current-process.patch > > solves this > > Can you look at this? First. I've see a problem with current approach in current approach we move process to /systemd/system while we need to move it to /systemd. Changes path can fix problem. Second. About lxnays solution, I will not say anything against it if it will use some sort of function from rc-cgroup.sh to hide all cgroups stuff there. E.g. create cgroups_relocate function and there check if systemd cgroup exists and relocate it there. Third. As openrc has other related problems we have to extend cgroup creation process and that extension will fix current situation I can try to create proof-of-concept in the nearest feature. I've explained a solution on #openrc channel and if it's needed then I can create a bug report with description and will attach code there. Ah, I was looking to: http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git instead of: https://github.com/OpenRC/openrc/commits/master :S *** Bug 475696 has been marked as a duplicate of this bug. *** +*gdm-3.8.3.1 (14 Jul 2013) + + 14 Jul 2013; Pacho Ramos <pacho@gentoo.org> +gdm-3.8.3.1.ebuild: + Version bump, use more upstream stuff (like exherbo pam.d files, systemd + units), systemd is required as upstream only cares about it (#463784) and we + will need systemd for other Gnome 3.8 parts (also, logind cannot be run + without systemd from >= 205). + On generic unstable, this is wanting syss-fs/udev and openrc-settings to go bye-bye, which is a pretty dramatic commitment. I knew systemd had been making lots of offers, but I wasn't aware gentoo'd let it put a ring on its finger just yet? That's life, upstream GNOME decided that systemd is now mandatory. OK, so as of right now, the gentoo position is if you want to run gnome 3.8.3+, you'll be dumping openrc & udev from your system in favor of systemd due to GUI suspend and other aspects expecting it? I'm not trying to be pedantic, and not asking anyone to whip up patches on my behalf, but want to be clear for others finding this as: - 3.8 is fairly far into its life cycle - It's a sea change from the documentation and conventional wisdom about the gentoo approach to the openrc/udev situation & systemd - Considering ^^, a lot of people/systems are going to hit this - I have a fondness for openrc/udev, and since they don't fit standard casket sizes I should get my order in now *gives the horns* I did the migration to systemd. Just be aware that you have to uninstall udev before systemd with install which which break some stuff like gvim. Fortunately vim still works. I had lots of problems until I attached to systemd-love overlay. I understand lots of that overlay is being merged. It a pain learning a new init system but overall I would say gnome-3.8 is more stable and once all the units are written for gentoo the issues should fade away. *** Bug 480270 has been marked as a duplicate of this bug. *** (Strictly this is WONTFIX as will require systemd and init.d/xdm won't be fixed) was fixed by migration to systemd. You can mark it thus Well it's a problem with the xdm init script which still exists. https://bugs.gentoo.org/attachment.cgi?id=349296 Will need to be applied in a revbump for involved xorg-server versions and a blocker against older gdm versions will need to be put on them New init.d/xdm has been committed to the tree for xorg-server-1.14.3-r1 +*gdm-3.8.4-r1 (28 Sep 2013) + + 28 Sep 2013; Pacho Ramos <pacho@gentoo.org> +gdm-3.8.4-r1.ebuild: + >=openrc-0.12 and xdm init.d script from >-x11-base/xorg-server-1.14.3-r1 + supports gdm-3.8 restarting (#463784 by Ian Stakenvicius, Chí-Thanh + Christopher Nguyễn, Alexander Vershilov, William Hubbs...). Handle + accessibility in a different way (#479516): xevie support disabled as it's + obsolete and broken, drop deps not needed for a long time due upstream + progressively dropping their support, remaining deps are only for fallback + greeter. Regarding orca.desktop autostart, it will only be started (confirmed + by me just now) when screen-reader-enabled gsetting is true. + |
