Yes, this is how GDM works now. Is there anything wrong with this behavior?

Hello Jasper!
Thanks for your response. This looks like a bug and a security issue for all users, furthermore a second TTY is lost. As you told us, this is not the case, but at least it is extremly bewildering even for people who don't know what a TTY is and just jump accidentally to the TTY with the login-screen.

Furthermore it looks like the gdm-screen is responsive to my inputs (correct?). I hesitate to push enter after entering my password, because of graphic corruptions.

I assume with GNOME 3.18 and the default switch to Wayland GDM and the GNOME-Session will run on on TTY again? Maybe you can "blank" the GDM-Screen in the meantime.

Furthermore there is at least another bug with graphic corruptions and complete hang of the system, which is maybe connected:
https://bugzilla.gnome.org/show_bug.cgi?id=747708

Thanks for your work Jasper
Bye

... will run on *one* TTY again?..

GDM's behavior was changed in 3.16 so that instead of running one X server on the login screen which is then transformed into the user's session, we now start a new X session from within the user's session, which means that we need to start the user's session on another TTY/VT.

Note that when using fast user switching, you effectively got this behavior as well, with each user on a different TTY/VT. We just extended it to the first user to log in as well.

How is it a security issue?

I don't know why users who are unaware of what a TTY is would be bewildered by the new behavior. How would they run into this behavior in the first place?

It cannot be a security issue. You have already described that this is intentionally!

I just descirbed with "looks like" my first feeling "Wow! The login screen is visible. This must be accidentally happened. What happens if some stranger could access this!?". I assume Jeff has the same gut feeling. GDM is just using the possibilieties of the TTYs here, but it is rather uncommon and new.

Basically I would suggest that the release notes should mention such a change in behaviour. What do you think?

Considering you can choose to launch the login screen from the screen lock prompt itself since 3.0, I didn't think it would come across as a security issue, nor a major change in behavior.

The main issue about this behavior is that gdm uses 120MB of ram here for literally nothing. That's a lot.

I agree with Clement. In terms of resources i actually have double load.
I didnt even noticed another tty before I started to google why i'm lacking the resources with new gdm.

Combined with some memory leaks (particularly with nvidia), this behavior means that an extra GIG of memory is used for no reason at all.

A fresh reboot has a separate gdm sitting at 291 MB. I realize that you guys often have design decisions that conflict with what users would want but this is really something that should be addressed: Even with a perfect scenario of having zero memory leaks (good luck with that), having a 100 MB process that does absolutely *nothing* is the exact opposite of optimization and usability.

What exactly is this supposed to accomplish? What use-cases is this supposed to fill? This also removes a flicker-free experience due to switching TTYs.

Add me to the list, resources are hogged because of this.

Arch users are reporting this issue: https://bbs.archlinux.org/viewtopic.php?id=196776

I have some weird effects I believe are related to this. When at the GDM login screen, if I switch to tty2 or tty3 it automatically forces me back to the login screen. Then after logging in, if I try to go to tty3 it forces me back to the login screen, though switching to tty2 still has my running gnome session. If I login again at the login screen it then puts gnome on tty4 or tty5 seemingly randomly. 

It is incredibly annoying to not be able to get to a sane tty session. Gdm isn't even limiting itself to tty1/2. It's jumping all over the place!

Having gdm repeatedly yank me back to the login screen each time I try to switch to a different tty is really annoying. Honestly, this new feature in 3.16 seems really unstable and unintuitive

Created attachment 303631 [details]
Kill Me

Just a few days of usage. I'm using a lot of swap now.

Jeez. I've never seen GNOME rise up to such a size. Are you using the NVIDIA proprietary drivers by any chance?

I am on my desktop. Gnome has consistently gotten this large on all Nvidia cards that I've run - I realize that it's the price that is paid and I fully accept the fact that these garbage drivers are not nearly as awesome as intel. My needs sadly dictate those drivers on the desktop.

My laptops run intel and are more under control, but it's still using at least 100 MB - perhaps not the end of the world but the occasional leak can raise it up quite a bit higher.

All in all, I've had to switch to lightdm because of this: I really like GDM's cohesiveness and simplicity but I cannot afford to spend an awful lot of resources on something that I use once every few weeks.

Please consider switching this behavior back. I can guarantee you that all NVIDIA users are suffering from this. I really hate NVIDIA and I fully intend on switching away from them in the future but the reality of the matter is that a lot of the world runs on the blobs they ship. Besides, if you want to combat the accusations of the world that Gnome is bloated, I don't think this is the way to go about this!

Thanks so much for your work, Jasper. Despite the disgruntled tone in here we really appreciate your work on this.

That's actually quite useful for us, believe it or not. An NVIDIA contact previously told us the high memory usage was due to a specific architecture quirk in the driver that stored memory pixmaps in the Composite client, but that can't be true for the gdm instance, since there are no windows being created and redirected on the login screen. I'll see if I can grab NVIDIA's attention again and perhaps we'll solve the high memory usage problem for everyone.

But doesn't this underlie the fact that this behavior is just bringing up issues for no gain? Like #10 says, so what if you can get this under ~200 MB? It's still an awful lot of bloat for a gain that still has yet to be announced. All this is doing is adding more resource consumption! It's a totally backwards way of thinking! Who on earth needs an instant TTY switch to a login screen that's sitting there all day, using up memory?

On a side note, I'm not confident in Nvidia's bug-fixing capabilities. Look at this year-old bug that has plagued users for over a year now:

https://devtalk.nvidia.com/default/topic/729908/linux/-gt-334-21-redrawing-problems-in-gnome-3-10-3-12-gtx-580/1/

The above is not just quirky bug, it's a *serious* one that really kills the desktop experience with a sickening thud.

Please, tell us why this change happened in the first place. It denigrates the otherwise-excellent release of GNOME 3.16!

Mikhail, can you run $ cat /proc/$(pidof gnome-shell)/maps ?

Let me explain a bit more about why we did this.

Previously, we launched one X server as root, and then when you logged in, we "morphed" it into the session X server. If you went to fast user switching, we then launched a second X server on-demand.

For security reasons, and Wayland porting reasons, we now launch the X server and Wayland server within the user's session, instead of starting one as root.

The way that we do this is that we launch two X servers, one for the gdm greeter session, and for the session user.

It would be entirely possible to tear-down the greeter after we've switched to the user session, it just requires a bit more code, but unfortunately it wouldn't be possible to put both the greeter session and the user session on VT1, since we'd have to launch the user session first, and then tear down the greeter session, and we can't be in that intermediate state while there are two X servers on the same VT at the same time.

I just forgot about the resource issues around keeping around two gnome-shell instances. I'll have a chat with Ray to see if we want to tear down the greeter session and then launch it on demand for user switching / logout to save on resources.

The NVIDIA issue is unrelated, and I have an NVIDIA employee investigating now.

Thank you for clarifying the position. Now the intention makes complete sense.

I do hope that some sort of implementation of loading resources on the fly could be implemented - that's a great idea!

I've re-enabled gdm but it's "only" at 200 MiB memory consumption right now: let me know if you need me to upload another output when it gets larger.

Created attachment 303727 [details]
cat /proc/472/maps

I will also point out another issue with this new paradigm: One must restart either GDM or the computer in order to use any new desktop environments that have been installed.

that sounds like a separate bug, mind filing it in a new report?

Created attachment 304007 [details]
cat /proc/472/maps (some days later)

Filed: https://bugzilla.gnome.org/show_bug.cgi?id=749899

Also, Here's another output of the same GDM session that's slowly grown over time: It's now at 715 MiB. GDM is my #1 process taking up RAM, followed by Gnome shell (the shell would have been much larger than it is now had I not restarted it a few days ago).

the gdm process? or the gnome-shell process used by the login screen?

that's the GDM process (PID 472) on both uploads.

apologies, it's the gnome-shell process owned by the gdm user. Sorry for the spam.

> The NVIDIA issue is unrelated, and I have an NVIDIA employee investigating now.

Is there a bug tracking this issue given it's unrelated?  I just had GDM use 10 GB of RAM yesterday for some reason.  I only noticed it because the system start to become unstable (luckly I didn't have any swap for it to churn).  I am using NVIDIA's proprietary drivers*.

* I don't actually need them, but nouveau would randomly crash the X server every ~30 min last time I tried :(.

*** Bug 750904 has been marked as a duplicate of this bug. ***

Some of the pitfalls of caching are:

1) Caching the same pixmap resources over and over again instead of reading them from cache. This is a common mistake that many OpenGL games suffer from. For example, every time you load the same track in a car racing game, the memory usage increases by an additional 200 MB. I don't think gnome-shell suffers from this one because after the initial memory increase of 120MB when I click "Activities -> Show Applications", subsequent "Activities -> Show Applications" operations don't result in another 120MB memory increase.

2) Not invalidating objects that are no longer in use. I think gnome-shell may suffer from this one. If I update some applications then click "Activities -> Show Applications", there is around 120MB additional memory increase 
(so initial 90MB + 120MB for first load + 120MB after updating apps =330MB total).
It should invalidate and purge the first 120MB of obsoleted cached pixmaps from memory then cache the new pixmaps.

Another issue I have have found that can be tracked to this bug is Bluetooth audio device support. Bug 749208 goes into this in more detail. I just thought I would draw you attention to the issue

Any updates on this? The gdm instance of gnome-shell keeps eating 50+ MB an hour which is not good on a system with only 4GB ram. That means I have to log off and log back on every few hours.
Is there at least a way to restart the gdm instance of gnome-shell without logging off?

logging off doesn't restart the gdm instance of gnome-shell, so it's weird that logging off would fix it.  Maybe it's the user instance of gnome-shell that's growing for you?

Do we agree that the following is what we want to do:

(In reply to Jasper St. Pierre from comment #20)
> It would be entirely possible to tear-down the greeter after we've switched
> to the user session, it just requires a bit more code

> I'll have a chat with Ray to see if we want to tear
> down the greeter session and then launch it on demand for user switching /
> logout to save on resources.

That would incidentally fix the bug where the screenshield appears over the greeter

Yes please...

(In reply to Ray Strode [halfline] from comment #34)
> logging off doesn't restart the gdm instance of gnome-shell, so it's weird
> that logging off would fix it.  Maybe it's the user instance of gnome-shell
> that's growing for you?

Both, sorry. The gdm instance of gnome-shell starts around 65MB then gradually grows close to ~180MB within three hours then slows down a lot afterwards.

The user instance of gnome-shell starts around 90MB. clicking activities gets it up to ~105 to 120MB. Then clicking 'show applications' brings it up to ~220MB. It starts growing slowly after that till around 300MB then even slower afterwards.

This all happens with negligible increase in Xorg memory usage.

However, on an offtopic note, Xorg suddenly jumps from 30MB to 380MB when I ctrl+alt+f2 then ctrl+alt+f3 back to gnome (subsequent ctrl+alt+f2/ctrl+alt+f3 don't cause visible memory increase). I posted the last observation in nvidia forums since this one appears to be their fault. http://pastebin.com/qmyu32G7

At least from my view, the user instance of gnome-shell can be easily restarted if its memory usage becomes an issue without interrupting my work.
The gdm instance of gnome-shell is really the problem since it cannot be restarted to save resources without logging off and restarting gdm.

Thank you for investigating.

Hi,

> Do we agree that the following is what we want to do:
> > It would be entirely possible to tear-down the greeter after we've switched
> > to the user session, it just requires a bit more code

I think doing something like that makes sense, but I think it's going to require Xwayland fixes first (or mutter changes to not require Xwayland).  I believe anyway, it's been a while since I played around with it.

Interesting observation: If I disable swap, both gnome-shell instances slow down eating memory when 2.9GB/3.9GB ram is full (around 70% full).
Firefox appears to do the same.

I tried running valgrind but gnome-shell exit very quickly.

==14077== Memcheck, a memory error detector
==14077== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14077== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==14077== Command: gnome-shell
==14077== Parent PID: 13612
==14077== 
==14077== Syscall param writev(vector[...]) points to uninitialised byte(s)
==14077==    at 0x7EF252D: ??? (in /usr/lib/libc-2.21.so)
==14077==    by 0x11F50CCA: ??? (in /usr/lib/libxcb.so.1.1.0)
==14077==    by 0x11F510C0: ??? (in /usr/lib/libxcb.so.1.1.0)
==14077==    by 0x11F51144: xcb_writev (in /usr/lib/libxcb.so.1.1.0)
==14077==    by 0xA05718D: _XSend (in /usr/lib/libX11.so.6.3.0)
==14077==    by 0xA057681: _XReply (in /usr/lib/libX11.so.6.3.0)
==14077==    by 0xF38B61C: XCompositeGetOverlayWindow (in /usr/lib/libXcomposite.so.1.0.0)
==14077==    by 0x605B14A: meta_screen_new (in /usr/lib/libmutter.so.0.0.0)
==14077==    by 0x604BCD8: meta_display_open (in /usr/lib/libmutter.so.0.0.0)
==14077==    by 0x605495B: meta_run (in /usr/lib/libmutter.so.0.0.0)
==14077==    by 0x40208C: main (in /usr/bin/gnome-shell)
==14077==  Address 0x1c58a590 is 32 bytes inside a block of size 16,384 alloc'd
==14077==    at 0x4C2C080: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14077==    by 0xA0474E1: XOpenDisplay (in /usr/lib/libX11.so.6.3.0)
==14077==    by 0xA3A6BE5: _gdk_x11_display_open (gdkdisplay-x11.c:1424)
==14077==    by 0xA382CC5: gdk_display_manager_open_display (gdkdisplaymanager.c:463)
==14077==    by 0x64C829F: gtk_init_check (gtkmain.c:1000)
==14077==    by 0x6071C1C: meta_ui_init (in /usr/lib/libmutter.so.0.0.0)
==14077==    by 0x6054776: meta_init (in /usr/lib/libmutter.so.0.0.0)
==14077==    by 0x401DDA: main (in /usr/bin/gnome-shell)
==14077== 
==14077== Invalid read of size 4
==14077==    at 0xB7EC496: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB73B91D: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB739667: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0x1CAB10B0: ???
==14077==    by 0xB7B3EAA: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB52025A: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB5176CC: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB518760: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB520167: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB5176CC: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB62A694: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB517764: ??? (in /usr/lib/libmozjs-24.so)
==14077==  Address 0xfffffffffffffffc is not stack'd, malloc'd or (recently) free'd
==14077== 
==14077== 
==14077== Process terminating with default action of signal 11 (SIGSEGV)
==14077==  Access not within mapped region at address 0xFFFFFFFFFFFFFFFC
==14077==    at 0xB7EC496: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB73B91D: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB739667: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0x1CAB10B0: ???
==14077==    by 0xB7B3EAA: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB52025A: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB5176CC: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB518760: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB520167: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB5176CC: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB62A694: ??? (in /usr/lib/libmozjs-24.so)
==14077==    by 0xB517764: ??? (in /usr/lib/libmozjs-24.so)
==14077==  If you believe this happened as a result of a stack
==14077==  overflow in your program's main thread (unlikely but
==14077==  possible), you can try to increase the size of the
==14077==  main thread stack using the --main-stacksize= flag.
==14077==  The main thread stack size used in this run was 8388608.
==14077== 
==14077== HEAP SUMMARY:
==14077==     in use at exit: 33,839,884 bytes in 83,731 blocks
==14077==   total heap usage: 627,746 allocs, 544,015 frees, 2,311,889,863 bytes allocated
==14077== 
==14077== LEAK SUMMARY:
==14077==    definitely lost: 41,183 bytes in 492 blocks
==14077==    indirectly lost: 5,348 bytes in 129 blocks
==14077==      possibly lost: 506,603 bytes in 2,449 blocks
==14077==    still reachable: 33,118,430 bytes in 79,734 blocks
==14077==         suppressed: 0 bytes in 0 blocks
==14077== Rerun with --leak-check=full to see details of leaked memory
==14077== 
==14077== For counts of detected and suppressed errors, rerun with: -v
==14077== Use --track-origins=yes to see where uninitialised values come from
==14077== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 0 from 0)

(In reply to Ray Strode [halfline] from comment #40)
> Hi,
> 
> > Do we agree that the following is what we want to do:
> > > It would be entirely possible to tear-down the greeter after we've switched
> > > to the user session, it just requires a bit more code
> 
> I think doing something like that makes sense, but I think it's going to
> require Xwayland fixes first (or mutter changes to not require Xwayland).  I
> believe anyway, it's been a while since I played around with it.

Anything like that planned for maybe gnome 3.20?
"gnome-shell --mode=gdm" is using 223.2 MB after only 13 hours of uptime.


I also can't figure out how to restart the gdm's instance of gnome-shell without logging off my user and restarting gdm (any idea on that too?).
Thank you.

Here is an interesting observation:
ctrl+alt+f1 then pressing escape to remove the 'curtain' completely stops the memory increase of gdm's gnome-shell instance for a few minutes.
This may be worth taking a look at.

We have an issue with that change under XSpice.

When we launch GDM on XSpice we use a TCP port (not a tty) and we can't launch another xserver on the same port.

David, do you mind filing another bug report?

Yes, I just opened #754765

(In reply to Hussam Al-Tayeb from comment #44)

Sounds like the time-dependent background might be at fault.

You could try setting static images by running "gsettings set org.gnome.desktop.screensaver picture-uri file:///path/to/image.jpg" and "gsettings set org.gnome.desktop.background picture-uri file:///path/to/image.jpg" as GDM.

(In reply to Jan Alexander Steffens (heftig) from comment #48)
> (In reply to Hussam Al-Tayeb from comment #44)
> 
> Sounds like the time-dependent background might be at fault.
> 
> You could try setting static images by running "gsettings set
> org.gnome.desktop.screensaver picture-uri file:///path/to/image.jpg" and
> "gsettings set org.gnome.desktop.background picture-uri
> file:///path/to/image.jpg" as GDM.

How would you run a command as gdm? machinectl shell?

I can't use gdm unless this issue is resolved... So I switched to lightdm for now :( I hope something will be planned for 3.20.

(In reply to Hussam Al-Tayeb from comment #49)
Yes, that seems to work. You get access to the ca.desrt.dconf bus service.

Jasper, this change has caused ripple effects in bluetooth audio support in Gnome as well. Can you please take a look at bug749208? I am not against this change, but now it has been a full year and I am having to still manually hack fixes to use my bluetooth headset because of this gdm tty change

Months from the original report, this is just getting worse. I am using Arch with nvidia proprietary drivers and gdm 3.18 and now after I log in I just see a blank screen with gdm background and the cursor. I have to switch to tty2 manually after login to get to my gnome session. Please give us some love, this isn't a needed behaviour, lxdm and lightdm work fine. Thanks.

(In reply to Gabriele Musco from comment #53)
> Months from the original report, this is just getting worse. I am using Arch
> with nvidia proprietary drivers and gdm 3.18 and now after I log in I just
> see a blank screen with gdm background and the cursor. I have to switch to
> tty2 manually after login to get to my gnome session. Please give us some
> love, this isn't a needed behaviour, lxdm and lightdm work fine. Thanks.

likely bug 754814

*** Bug 757490 has been marked as a duplicate of this bug. ***

Can we have some infos on this please.
Thank you.

jeemy9856: Do you have a specific question? 
"Some info" is in the comments of this task.

(In reply to André Klapper from comment #57)
> jeemy9856: Do you have a specific question? 
Is there something actually made to fix this like said in #20 #35 #40 to avoid having 2 gnome-shell session ? If it's the case do you think it be fixed for Gnome 3.20 ?

Is Nvidia is really doing something about the high memory consumption like said in #20 ?

Since we basically don't know what is done a little bit of information can't hurt ;)

Thank you.

I do hope that something is done about this bug. This does impact the viability of Gnome negatively.

I'm using Archlinux with Gnome 3.18
I can't get it, why user gdm run XWayland, gvfs, and pulseaudio. Why GDM need XWayland? Isn't GDM fully support Wayland? XWayland eats >15MB of my RAM.

Anyone can explain me why GDM need a lot of memory just for login greeter?

It seems that like the memory consomption problem (bug 735705, bug 701230, etc...) nothing will be done...

Ray, the main gdm developer, has been on leave for a few months now. He'll be back next year.

(In reply to Jasper St. Pierre from comment #62)
> Ray, the main gdm developer, has been on leave for a few months now. He'll
> be back next year.

Ok, I hope he will take care of this and take a look at this bug 753615 ;)
Thanks !

I compiled the GDM 3.14 branch against 3.18 and the old (sane?) behavior is back. I don't see any obvious issue so far. The downside is that Xorg is running as root now. :(

The issue is that even with gnome-shell 3.18.3 and gdm 3.18.2, the gdm version of gnome-shell keeps eating CPU unless I ctrl+alt+f1 and ctrl+alt+f2 every 10 minutes. I worked around it by enabling autologin which means only one gnome-shell process.

The leaks don't help but the main issue is the CPU usage. My core2duo 2.9GHZ is simply not enough for the gdm version of gnome-shell to keep eating 20% CPU.
The user version of gnome-shell barely uses 5% CPU.

Sadly, I don't think there is a unified api and configuration file for display managers (autologin settings, etc...) so it is not possible to use another display manager as a drop in replacement while still allowing gnome to configure it. I understand this is not something people want to hear but I feel the design of Linux desktops is not very complete.

In over 15 years of using Linux desktops, I have never had to enable autologin.

I noticed the CPU usage of gnome-shell almost always exactly corresponds to the Xorg process CPU usage. Is Wayland expected to lower the CPU usage or is that mostly up to the display driver?

That's bizarre -- I have never seen gnome-shell eat CPU when VT switched away. Maybe this is another artifact of NVIDIA.

(In reply to Jasper St. Pierre from comment #66)
> That's bizarre -- I have never seen gnome-shell eat CPU when VT switched
> away. Maybe this is another artifact of NVIDIA.

I think bug 753891 isn't really fixed.

*** Bug 748039 has been marked as a duplicate of this bug. ***

Is Ray, the main gdm developer, back ?
We really need some improvement here :D

i'm back, but not currently looking at this bug. It's on my radar though, just behind other things.

(In reply to Ray Strode [halfline] from comment #70)
Welcome back ! It's nice to know that even if you are not currently looking at this bug, it's on your radar.
Thanks !

Is there a way to disable this "feature"? I'm the only user on my computer and I usually use only up to 2 tty's, one with console and one with GUI. I don't like how one tty is being "wasted" for a lock screen as it is just sitting there taking up valuable resources.

(In reply to wiiliamchung360 from comment #72)
> Is there a way to disable this "feature"? I'm the only user on my computer
> and I usually use only up to 2 tty's, one with console and one with GUI. I
> don't like how one tty is being "wasted" for a lock screen as it is just
> sitting there taking up valuable resources.
If this is a private computer at home, enabling auto-login does so.

Unfortunately, the resource consumption still remains a problem, particularly when paired with the memory leaks gdm appears to have. I'm not particularly enthused about keeping 250 MB of ram dedicated to something that does literally nothing all day. Pair that with a second gdm process that's leaking and we have a bit of a resource consumption problem :)

Please folks, stop complaining in this bug, it doesn't help anything. We know running the login screen twice is a problem and agreed to fix it, somebody just needs to find time to do so.

@jeremy9856: Please refrain from adding comments to a bug report when your comment does not offer any additional information. Every comment creates notifications that someone has to read (who cannot write or fix code in that time), and advocacy is not welcome.

I just noticed that Ray Strode added a configure option in gdm master branch to restore the old behavior of using one VT with gdm running as root. I guess this means it is possible again to have only one gnome-shell instance running.
Thank you.

*** Bug 785950 has been marked as a duplicate of this bug. ***

Hi,
Sorry to come on this also, but for me, this new GDM behaviour is worth than expected.
I'm working as "IT" on company computers, try to go on with debian stretch. The problem is that we do use software that hard codding use DISPLAY :0.0.
This NEW GDM behaviour make user DISPLAY :1.0 and then our software can not work.

If you have any solution for my "small" problem, thanks.

Rgds

A.

Sorry - this task is not a general support forum. Also see comment 75.

For another datapoint - on my Ubuntu nvidia/intel hybrid system, having the greeter run a perpetual X server prevents the discrete card from being powered off.

On such a hybrid system, nvidia-settings has a button to switch between the nvidia and intel cards; this performs the update-alternatives dance to switch the libGL, DDX, and such so that the *next* X server started will use the Intel card. Since the greeter continues running, though, there's always an X server running on the nvidia card which prevents it from being powered off.

As a workaround, install and configure lightdm until GDM gets fixed.
Inconvenient as it is to type down the user name everytime, 
tty1-tty6 are free as before and xserver is running on tty7.

https://bugzilla.gnome.org/show_bug.cgi?id=782832 another workaround by a member of manjaro linux team if you want to continue using GDM

*** Bug 782832 has been marked as a duplicate of this bug. ***

So, as of GNOME 3.28, gdm user has a memory footprint of over 300 mb on my 2gb ram, obviously single user, netbook.
Now gdm has even its own gnome-shell process.

I have no idea what you're talking about. i don't see any claims being made or any assertions about relative knowledge being made. Anyway this isn't a discussion forum, please keep the bug report technical.

@fmneto: Regarding your comment 89, either follow https://wiki.gnome.org/Foundation/CodeOfConduct or comment somewhere else. Thanks.

@fmneto:
using wayland saves you from using a display manager at all, just make executable this code:

#!/bin/bash

XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session

Hans, you're working on this?

Hi,

(In reply to Michael Catanzaro from comment #94)
> Hans, you're working on this?

Yes as part of the GNOME performance hackfest I've written a set of patches to stop the greeter session after login and to start it again when necessary:

https://github.com/jwrdegoede/gdm/commits/stop-chooser-after-login

I finished this patch-set yesterday evening and consider it ready for review / merging now.

Ray, can you review these please?

Regards,

Hans

Hi,there i'm happy to test this patch in Manjaro with our community if you agree

Best
Stefano Capitani

(In reply to Stefano from comment #96)
> Hi,there i'm happy to test this patch in Manjaro with our community if you
> agree

It is a patch-set of 6 (small) patches. I've ran a bunch of tests myself and it works well for me. Some wider testing would definitely be welcome.

thanks for looking into this, will review your patches soon.

Done GDM with patch is in our repo ( Manjaro ) :)

Cheers 
Stefano

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdm/issues/222.