Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 463784 - x11-base/xorg-server: gnome-base/gdm-3.8 will not restart with /etc/int.d/xdm restart
Summary: x11-base/xorg-server: gnome-base/gdm-3.8 will not restart with /etc/int.d/xdm...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo X packagers
URL: https://bugzilla.gnome.org/show_bug.c...
Whiteboard:
Keywords:
: 475696 (view as bug list)
Depends on: 471016 475194
Blocks: gnome-3.8
  Show dependency tree
 
Reported: 2013-03-30 01:51 UTC by Harris Landgarten
Modified: 2013-09-28 08:37 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
gdm-3.8.0.ebuild.diff (gdm-3.8.0.ebuild.diff,443 bytes, patch)
2013-03-30 07:27 UTC, iGentoo
Details | Diff
xdm-init.diff (xdm-init.diff,658 bytes, patch)
2013-05-26 19:13 UTC, Pacho Ramos
Details | Diff
xdm-init.diff (xdm-init.diff,654 bytes, patch)
2013-05-26 19:17 UTC, Pacho Ramos
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Harris Landgarten 2013-03-30 01:51:49 UTC
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.
Comment 1 iGentoo 2013-03-30 05:14:42 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?
Comment 2 iGentoo 2013-03-30 07:27:04 UTC
Created attachment 343702 [details, diff]
gdm-3.8.0.ebuild.diff
Comment 3 Pacho Ramos gentoo-dev 2013-03-31 18:38:44 UTC
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?
Comment 4 Harris Landgarten 2013-03-31 18:45:54 UTC
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?
Comment 5 Pacho Ramos gentoo-dev 2013-03-31 19:17:31 UTC
(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"
Comment 6 Pacho Ramos gentoo-dev 2013-04-06 10:31:22 UTC
(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
Comment 7 Pacho Ramos gentoo-dev 2013-05-12 19:26:03 UTC
Probably systemd is controlling gdm processes in some way, not sure if it's possible to control processes launched by gdm with openrc :/
Comment 8 Pacho Ramos gentoo-dev 2013-05-13 05:32:21 UTC
OK, it can be killed running "kill -- -<pid>"... but not sure how to end running that using start-stop-daemon :/
Comment 9 Pacho Ramos gentoo-dev 2013-05-15 18:16:31 UTC
(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)
Comment 10 C. Wijtmans 2013-05-24 17:21:21 UTC
symlink /var/run > /run
Comment 11 Pacho Ramos gentoo-dev 2013-05-26 19:13:39 UTC
Created attachment 349294 [details, diff]
xdm-init.diff
Comment 12 Pacho Ramos gentoo-dev 2013-05-26 19:15:17 UTC
(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.
Comment 13 Pacho Ramos gentoo-dev 2013-05-26 19:17:03 UTC
Created attachment 349296 [details, diff]
xdm-init.diff

Ooops, this uses /run instead of relying on /var/run symlink ;)
Comment 14 Chí-Thanh Christopher Nguyễn gentoo-dev 2013-05-26 19:46:05 UTC
> +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.
Comment 15 Pacho Ramos gentoo-dev 2013-05-27 06:45:10 UTC
(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
Comment 16 Alexander Vershilov (RETIRED) gentoo-dev 2013-05-27 08:15:33 UTC
(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.
Comment 17 William Hubbs gentoo-dev 2013-05-27 14:11:24 UTC
(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.
Comment 18 Pacho Ramos gentoo-dev 2013-05-27 20:39:40 UTC
(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? :/
Comment 20 Alexander Vershilov (RETIRED) gentoo-dev 2013-06-22 21:38:54 UTC
(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.
Comment 21 William Hubbs gentoo-dev 2013-06-24 16:44:25 UTC
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
Comment 22 Pacho Ramos gentoo-dev 2013-06-24 18:54:07 UTC
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...)
Comment 24 Fabio Erculiani (RETIRED) gentoo-dev 2013-06-24 19:12:18 UTC
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...
Comment 25 Alexander Vershilov (RETIRED) gentoo-dev 2013-06-24 19:54:47 UTC
(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.
Comment 26 William Hubbs gentoo-dev 2013-06-25 14:35:55 UTC
(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.
Comment 27 Pacho Ramos gentoo-dev 2013-06-25 16:53:55 UTC
Looks really promising, thanks a lot!
Comment 28 Pacho Ramos gentoo-dev 2013-06-29 10:05:04 UTC
(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?
Comment 29 Alexander Vershilov (RETIRED) gentoo-dev 2013-06-29 17:35:10 UTC
(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.
Comment 30 Alexander Vershilov (RETIRED) gentoo-dev 2013-06-29 18:49:16 UTC
(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.
Comment 31 Pacho Ramos gentoo-dev 2013-06-30 07:24:50 UTC
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
Comment 32 Pacho Ramos gentoo-dev 2013-07-04 18:22:39 UTC
*** Bug 475696 has been marked as a duplicate of this bug. ***
Comment 33 Pacho Ramos gentoo-dev 2013-07-14 13:19:35 UTC
+*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).
+
Comment 34 drunkenbatman 2013-07-17 08:49:20 UTC
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?
Comment 35 Fabio Erculiani (RETIRED) gentoo-dev 2013-07-17 09:41:27 UTC
That's life, upstream GNOME decided that systemd is now mandatory.
Comment 36 drunkenbatman 2013-07-17 18:08:49 UTC
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*
Comment 37 Harris Landgarten 2013-07-17 18:15:29 UTC
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.
Comment 38 Pacho Ramos gentoo-dev 2013-08-08 16:45:42 UTC
*** Bug 480270 has been marked as a duplicate of this bug. ***
Comment 39 Pacho Ramos gentoo-dev 2013-08-08 16:58:31 UTC
(Strictly this is WONTFIX as will require systemd and init.d/xdm won't be fixed)
Comment 40 Harris Landgarten 2013-08-08 17:12:53 UTC
was fixed by migration to systemd. You can mark it thus
Comment 41 Chí-Thanh Christopher Nguyễn gentoo-dev 2013-08-14 10:37:00 UTC
Well it's a problem with the xdm init script which still exists.
Comment 42 Pacho Ramos gentoo-dev 2013-08-14 10:51:39 UTC
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
Comment 43 Ian Stakenvicius (RETIRED) gentoo-dev 2013-09-27 21:48:54 UTC
New init.d/xdm has been committed to the tree for xorg-server-1.14.3-r1
Comment 44 Pacho Ramos gentoo-dev 2013-09-28 08:37:09 UTC
+*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.
+