Cinnamon: Sometimes screen remains black after GUI login.

[glesialo]

Bug instance 01

System:    Host: Linux-1 Kernel: 5.0.0-31-generic x86_64 bits: 64 Desktop: Cinnamon 4.2.4 
           Distro: Linux Mint 19.2 Tina 
Machine:   Type: Desktop System: MSI product: MS-7885 v: 1.0 serial: <root required> 
           Mobo: MSI model: X99S SLI PLUS (MS-7885) v: 1.0 serial: <root required> 
           UEFI: American Megatrends v: 1.E0 date: 06/15/2018 
CPU:       Topology: 6-Core model: Intel Core i7-5820K bits: 64 type: MT MCP L2 cache: 15.0 MiB 
           Speed: 1200 MHz min/max: 1200/3600 MHz Core speeds (MHz): 1: 1201 2: 1200 3: 1201 
           4: 1258 5: 3594 6: 1200 7: 1200 8: 1300 9: 1200 10: 1202 11: 3595 12: 1200 
Graphics:  Device-1: NVIDIA GM204 [GeForce GTX 970] driver: nvidia v: 430.40 
           Display: x11 server: X.Org 1.19.6 driver: nvidia 
           unloaded: fbdev,modesetting,nouveau,vesa resolution: 1920x1080~60Hz 
           OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 430.40 
Audio:     Device-1: NVIDIA GM204 High Definition Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.0.0-31-generic

Issue:
Sometimes (random, about once every 20 log-ins) screen remains black after GUI
login. Mouse pointer is visible and can be moved around. Music plays ('audacious'
is started automatically, see below). Started happening after upgrading to
Linux Mint 19.2.

Last time the bug happened I switched to tty1 and killed 'cinnamon-session' process:
  lightdm --session-child 13 20
   \_ cinnamon-session --session cinnamon
I then successfully logged-in (GUI) again.

Files attached:
  2019_10_17.log              # User's log.
  /var/log/Xorg.0.log         # Successful log-in after failed log-in.
  /var/log/Xorg.0.log.old     # Failed log-in.
  $HOME/.xsession-errors      # Successful log-in after failed log-in.
  $HOME/.xsession-errors.old  # Failed log-in.
  /var/log/syslog             # Relevant part.

Notes:
- Commands/applications are launched automatically after GUI login. I have been using
  the same scheme, without any problems, for many years.
- There is a 'Waiting for graphical session to stabilize's loop (until 'wmctrl -d'
  -list of workspaces- reaches a stable output) before launching the above
  commands/applications. In failed log-ins 'Waiting for graphical session to stabilize'
  exits after a single wait (It is 2..4 for normal log-ins).
- Application 'MainMenuAndNetTraffic' uses 'wmctrl' to send a hint to the window manager
  requesting that 'MainMenuAndNetTraffic's window is made 'sticky' (appears in all
  workspaces). To do that 'MainMenuAndNetTraffic's window is temporarily renamed and
  'wmctrl -l' used until the new name is in the list of windows. In a buggy log-in,
  waiting for the new name timeouts as can be seen in the following '$HOME/.xsession-errors'
  error message:
    (Class)Main.(Method)main: {
      Warning!: Exception: (Class)HintsToWindowManager.(Method)sendChangeWindowPropertiesHints: {
        Exception: (Class)HintsToWindowManager.(Method)runWindowManagerController: {
          Timeout waiting for frame window to appear in active windows list.
          Hints will not be sent to Window Manager.
        }
      }
    }
- In file '2019_10_17.log' you can see:
  Failed GUI session. Starts with:
    2019/Oct/17 17:39:01: GraphicalSessionAutostart: Starting new graphical session for user: 'manolo'.
  Killing of Cinnamon session:
    2019/Oct/17 17:42:30: cinnamon-session killed
  Successful GUI session. Starts with:
    2019/Oct/17 17:42:47: GraphicalSessionAutostart: Starting new graphical session for user: 'manolo'.
- Let me know if you want any more details of '2019_10_17.log's contents.

.xsession-errors.log
.xsession-errors.old.log
2019_10_17.log
Xorg.0.log
Xorg.0.log.old.log
syslog.log

[icarter09]

@glesialo are you still experiencing this issue?

[glesialo]

@icarter09 I guess I am. It doesn't happen very often.

[icarter09]

@glesialo are you able to log into your computer or does it remain black after powering on? I realized I do have a laptop that does this quite often, I just don't use it that much. I'm 100% sure it's related specifically to that laptop because I have never experienced it on any other machine before or after.

[glesialo]

Bug instance 02

@icarter09. I get 'lightdm' login screen all right. It is after login that the screen goes black (and remains black).

It has happened again.
Note 'MainMenuAndNetTraffic' error message in '.xsession-errors.old':
(Class)Main.(Method)main: {
  Warning!: Exception: (Class)HintsToWindowManager.(Method)sendChangeWindowPropertiesHints: {
    Exception: (Class)HintsToWindowManager.(Method)runWindowManagerController: {
      Timeout waiting for frame window to appear in active windows list.
      Hints will not be sent to Window Manager.
    }
  }
}

In file '2019_11_10.log' you can see:
  Failed GUI session. Starts with:
    2019/Nov/10 08:30:19: GraphicalSessionAutostart: Starting new graphical session for user: 'manolo'.
  Killing of Cinnamon session:
    2019/Nov/10 08:34:03: cinnamon-session process killed with 'kill -9 13156'
  Successful GUI session. Starts with:
    2019/Nov/10 08:34:17: GraphicalSessionAutostart: Starting new graphical session for user: 'manolo'.

Files attached:
  2019_11_10.log              # User's log.
  /var/log/syslog             # Relevant part (syslog.1 + syslog).
  /var/log/Xorg.0.log         # Successful log-in after failed log-in.
  /var/log/Xorg.0.log.old     # Failed log-in.
  $HOME/.xsession-errors      # Successful log-in after failed log-in.
  $HOME/.xsession-errors.old  # Failed log-in.

EDIT: Notes:

• I logged the killing of 'cinnamon-session' process including its PID: 13156. You can search for that PID in 'syslog'.
• 'audacious' was running in the failed log-in session (I could hear the music) but its icon wasn't loaded (no 'Adding systray: audacious (24x24px)' in '.xsession-errors.old'). 'audacious' icon is loaded in successful log-in sessions (check '.xsession-errors').

.xsession-errors.log
.xsession-errors.old.log
2019_11_10.log
syslog.log
Xorg.0.log
Xorg.0.log.old.log

[icarter09]

@glesialo not sure why you weren't getting email updates. Thanks for the update and the updated log files. I'll look them over.

[glesialo]

@icarter09 Thank you. It was GMail that considered the updates spam. Fixed now :-)

[icarter09]

@glesialo the next time this happens can you try...
1) switching to tty1 and run sudo start lightdm
2) see if there is any logs in /var/log/lightdm

I see in the syslog where this...
Nov 10 08:34:03 Linux-1 manolo:CommonLog[20645]: DmSession_CommonCleanup_manolo: Forcing end of session: dbus process killed.
...matches up the the time for when this occurred in the 2019_11_10.log 2019/Nov/10 08:34:03: cinnamon-session process killed with 'kill -9 13156'

Problem is probably not related to the lightdm, but curious what the above provides.

[glesialo]

@icarter09 Will do that next time, but what happens is perfectly normal. When I installed Cinnamon 19.1, I found a (well known) bug. Here are my notes about it:

After GUI logging out desktop processes remain alive
Related issue: after logging out, a tmpfs remains
  mounted at /run/user/<numeric-user-id>.
!!Forbidden solution (because it also kills normal user's subprocesses of 'CommonDaemon common' & 'CommonCron'):
  Edit /etc/systemd/logind.conf changing 'KillUserProcesses=no' to
    KillUserProcesses=yes
!! Solved: Killing processes in '/etc/DmSession_CommonCleanup' (SystemLinks) which is run by lightdm's
  hook 'session-cleanup-script=/etc/DmSession_CommonCleanup' in '/etc/lightdm/lightdm.conf' (SystemLinks).

'DmSession_CommonCleanup' was needed to unmount an encrypted ('/home/user') FileSystem for some users and I just added a few lines to kill the desktop processes, still running after log-out, before unmounting (only for some users - not for user 'manolo' in this bug instance) the encrypted FS. The sequence was as follows:

I switched to tty1 and ran 'kill -9 13156; echo "cinnamon-session process killed with 'kill -9 13156'" | CommonLog'
(In a previous bug instance I tried 'kill' without -9 and it didn't work).

Killing 'cinnamon-session' forced a log-out: I was switched to a new 'lightdm' session in tty7.

Logging out forced running 'DmSession_CommonCleanup' which, in this case, only killed the remaining desktop processes.

The same scheme was running with Cinnamon 19.1 and there was no bug then. I can post 'DmSession_CommonCleanup' if you want.

EDIT: I have extracted 'lightdm' (file with date 2019/11/10 - same as last instance of the bug) from '/var/log/lightdm/lightdm.log.2.gz' and attached it as 'lightdm.log'.
There is no time-stamp in the logs but the bug happened at the first log-in of the day so failed log-in session's logs should be at the top.

EDIT2: I realized that 2019/11/10 logs are split in '/var/log/lightdm/lightdm.log.1.gz' & '/var/log/lightdm/lightdm.log.2.gz'. I have merged the files, including what I think is the transition 2019/11/09 -> 2019/11/10, in 'lightdm.log'.

EDIT3: I am a fool. It should be '/var/log/lightdm/lightdm.log.3.gz' & '/var/log/lightdm/lightdm.log.2.gz'. I have updated 'lightdm.log'.

lightdm.log

[glesialo]

Bug instance 03

Another failed log-in. Switched to tty1, ran (as requested) 'sudo service lightdm restart' & logged-in (GUI) again, successfully.

Files attached:
  2019_12_08.log                # User's log. Search for: 'psl >ps.log', 'sudo service lightdm restart' & 'psl >ps_2.log'.
  $HOME/.xsession-errors.old    # Failed log-in.
  ps.log                        # 'ps -Ao ni,user,ppid,pid,args --forest' in failed log-in session.
  $HOME/.xsession-errors        # Successful log-in (after failed log-in).
  ps_2.log                      # 'ps -Ao ni,user,ppid,pid,args --forest' in successful (after failed) log-in session.
  /var/log/lightdm/lightdm.log  # In successful log-in session (after failed log-in).
  /var/log/Xorg.0.log.old       # Failed log-in.
  /var/log/Xorg.0.log           # Successful log-in (after failed log-in).
  /var/log/syslog               # Relevant part. Search for: 'psl >ps.log', 'sudo service lightdm restart' & 'psl >ps_2.log'.

.xsession-errors.log
.xsession-errors.old.log
2019_12_08.log
lightdm.log
ps.log
ps_2.log
syslog.log
Xorg.0.log
Xorg.0.log.old.log

EDIT: '/var/log/lightdm/lightdm1.log' attached.

lightdm1.log

[icarter09]

@glesialo glad that worked for you.
Comparing Xorg.0.log and Xorg.0.log.old.log I noticed this line in the failed log file..

NVIDIA(0): ONKYO Corporation HT-R393 (DFP-1) does not have an EDID, or NVIDIA(0): its EDID does not contain a maximum image size; cannot NVIDIA(0): compute DPI from ONKYO Corporation HT-R393 (DFP-1)'s NVIDIA(0): EDID.

Not sure if that points to the issue at hand or not. I'm also thinking that this isn't a Cinnamon issue since it looks to be a problem with lightdm not properly starting during the kernel's init process. Thoughts?

[leigh123linux]

@icarter09 Looks like the monitor supplies an invalid EDID

[glesialo]

'ONKYO Corporation HT-R393' is an AudioVideoReceiver. I use an USB controlled power strip to power my monitor (a Samsung TV) on. At boot the AVR is in standby with an HDMI pass-through and the monitor is powered off. After boot a script powers on the monitor which in turn wakes up the AVR. That's probably the reason for the 'does not have an EDID' message.

I have been using the same set up with Cinnamon 17 and 19.1 without any problems.

Here is a 'common' log, which includes Starting_up/Shutting_down, where you can check when the monitor (TV) was powered on, this morning, when the failed log-in took place.

Look for:

2019/Dec/08 09:52:03: root: CommonSystemStartUp: 'OnOff_Monitor': OnOffMainsSocket04(-on): off -> on

2019_12_08.log

EDIT: If you search for 'Adding systray' in '.xsession-errors.old.log' (failed log-in) you won't find any. If you search in '.xsession-errors.log' (successful log-in) you'll find a few (adding icons for all the applications started).

EDIT2: I have a '/etc/X11/Xsession.d/20-nvidia.conf' file (I can post it) that includes 'Option "AllowEmptyInitialConfiguration" "true"' so that X starts even if the monitor is not on. The bug doesn't appear very often, the same set up allows many successful log-ins.

EDIT3: Your comment: 'with lightdm not properly starting during the kernel's init process'. I started the failed session by logging-in in the 'lightdm's screen and in 'ps.log' (processes in failed log-in) you can see:

0 root      1251  1940  \_ lightdm --session-child 13 20
0 manolo    1940 22610      \_ cinnamon-session --session cinnamon

[glesialo]

Bug instance 04

Failed again. This time I have waited 5 minutes before re-starting 'lightdm'.

Files attached:
  2019_12_11.log                # User's log. Search for: 'psl >ps.log', 'sudo service lightdm restart' & 'psl >ps_2.log'.
  $HOME/.xsession-errors.old    # Failed log-in.
  ps.log                        # 'ps -Ao ni,user,ppid,pid,args --forest' in failed log-in session.
  $HOME/.xsession-errors        # Successful log-in (after failed log-in).
  ps_2.log                      # 'ps -Ao ni,user,ppid,pid,args --forest' in successful (after failed) log-in session.
  /var/log/lightdm/lightdm.log  # In successful log-in session (after failed log-in).
  /var/log/lightdm/lightdm1.log # In '/var/log/lightdm/lightdm.log.1.gz'.
  /var/log/Xorg.0.log.old       # Failed log-in.
  /var/log/Xorg.0.log           # Successful log-in (after failed log-in).
  /var/log/syslog               # Relevant part. Search for: 'psl >ps.log', 'sudo service lightdm restart' & 'psl >ps_2.log'.

.xsession-errors.log
.xsession-errors.old.log
2019_12_11.log
lightdm.log
lightdm1.log
ps.log
ps_2.log
syslog.log
Xorg.0.log
Xorg.0.log.old.log

[glesialo]

Bug instance 05

I upgraded to Cinnamon 19.3 on 18/12/2019 and I am currently using kernel 5.0.0-37.

After failed log-in (screen always goes black, for a few seconds, after a lightdm log-in. Stays black in failed log-in) I switched to tty1, ran (as requested) 'sudo service lightdm restart' & logged-in (GUI) again, successfully.

Files attached:
  2019_12_20.log                # User's log. Search for: 'psl >ps.log', 'sudo service lightdm restart' & 'psl >ps_2.log'.
  $HOME/.xsession-errors.old    # Failed log-in.
  ps.log                        # 'ps -Ao ni,user,ppid,pid,args --forest' in failed log-in session.
  $HOME/.xsession-errors        # Successful log-in (after failed log-in).
  ps_2.log                      # 'ps -Ao ni,user,ppid,pid,args --forest' in successful (after failed) log-in session.
  /var/log/lightdm/lightdm.log  # In successful log-in session (after failed log-in). lightdm.log.1.gz + lightdm.log
  /var/log/Xorg.0.log.old       # Failed log-in.
  /var/log/Xorg.0.log           # Successful log-in (after failed log-in).
  /var/log/syslog               # Relevant part. Search for: 'psl >ps.log', 'sudo service lightdm restart' & 'psl >ps_2.log'.

Monitor was powered on (obviously) before lightdm log-in:

2019/Dec/20 08:49:19: root: CommonSystemStartUp: 'OnOff_Monitor': OnOffMainsSocket04(-on): off -> on

.xsession-errors.log
.xsession-errors.old.log
2019_12_20.log
lightdm.log
ps.log
ps_2.log
syslog.log
Xorg.0.log
Xorg.0.log.old.log

[glesialo]

Hello,
I thought this issue had been solved in some Cinnamon update but it happened again today. :-(

Perhaps it just a coincidence but the issue has reappeared after an update to kernel 5.3.0-45 (30/03/2020).