Bug 1466526 - Graphical login fails after upgrade to FC26 beta--seahorse terminates with sig11
Graphical login fails after upgrade to FC26 beta--seahorse terminates with sig11
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
26
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Rui Matos
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-29 17:59 EDT by Matthew Saltzman
Modified: 2017-07-21 06:23 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-21 06:23:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Excerpt from /var/log/messages covering an attempt to GDM login. (23.56 KB, text/plain)
2017-06-29 17:59 EDT, Matthew Saltzman
no flags Details
Excerpt from /var/log/messages with GDM debug enabled. (19.06 KB, text/plain)
2017-07-17 11:48 EDT, Matthew Saltzman
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 775463 None None None 2017-07-21 06:23 EDT

  None (edit)
Description Matthew Saltzman 2017-06-29 17:59:37 EDT
Created attachment 1292993 [details]
Excerpt from /var/log/messages covering an attempt to GDM login.

Description of problem:
Logging in via GDM, prompted for passwrd, then login screen reappears.

Version-Release number of selected component (if applicable):
seahorse-3.20.0-4.fc26.x86_64

How reproducible:
Always, on one machine. On another machine, the update to FC26 beta worked fine.

Steps to Reproduce:
1. Upgrade to FC26 beta
2. Log in via GDM
3.

Actual results:
Login fails after password prompt

Expected results:
Login succeeds.

Additional info:
Command-line or ssh logins succeed.

I'm not sure if seahorse is in fact the right component, but the logs show that seahorse is terminating with a sig11, so I decided to start here. The log excerpt is attached.
Comment 1 Matthew Saltzman 2017-06-30 19:18:45 EDT
Moving keyring files to .local/share/keyrings doesn't help. Deleting the keyring files login.keyring and user.keystore doesn't help.
Comment 2 Adam Williamson 2017-07-10 18:25:29 EDT
seahorse isn't really the problem here. The logs show dozens of components crashing, and seahorse isn't actually the one that takes the session down either time.
Comment 3 Florian Müllner 2017-07-14 08:26:48 EDT
(In reply to Adam Williamson from comment #2)
> seahorse isn't really the problem here. The logs show dozens of components
> crashing, and seahorse isn't actually the one that takes the session down
> either time.

Agreed, there are various required components that fail to (re)start. Now the reason *may* be that gnome-shell is failing without a trace (at least in the logs), but it's impossible to tell without further information. For now, let's reassign to gnome-settings-daemon, which is what shows up in the logs ...
Comment 4 Rui Matos 2017-07-14 10:29:26 EDT
Not enough info, please edit /etc/gdm/custom.conf and enable debug output then attach a full system log of a failed login attempt.
Comment 5 Matthew Saltzman 2017-07-14 18:56:37 EDT
I thought it would be useful to see if a virgin userid exhibited the same problem, so I created one using system-config-users. Not only does that userid work fine (modulo a separate issue with the graphical display) but now so does my own userid. So unfortunately, the problem appears to no longer be reproducible.

Maybe the fact that userid creation is correlated with the cure will provide some insight, but unfortunately, at this point, I can't add information on this issue. Will reopen or refile if I hit the issue again.
Comment 6 Matthew Saltzman 2017-07-17 11:48 EDT
Created attachment 1299922 [details]
Excerpt from /var/log/messages with GDM debug enabled.
Comment 7 Matthew Saltzman 2017-07-17 11:49:45 EDT
I just upgraded another machine and encountered the same issue. I am attaching an excerpt of /var/log/messages with GDM debug enabled. I can also report that removing saved sessions in ~/.config/gnome-session/saved-session seems to have cleared the problem, so this may be related to Bug #775463.
Comment 8 Rui Matos 2017-07-17 12:17:44 EDT
(In reply to Matthew Saltzman from comment #6)
> Created attachment 1299922 [details]
> Excerpt from /var/log/messages with GDM debug enabled.

This was either captured without gdm debug enabled or it's not a full log.

You need to reboot or at least restart gdm.service after editing /etc/gdm/custom.conf to ensure the former and capture all the output of "sudo journalctl -b" for the latter.
Comment 9 Matthew Saltzman 2017-07-17 19:53:50 EDT
(In reply to Rui Matos from comment #8)
> (In reply to Matthew Saltzman from comment #6)
> > Created attachment 1299922 [details]
> > Excerpt from /var/log/messages with GDM debug enabled.
> 
> This was either captured without gdm debug enabled or it's not a full log.
> 
> You need to reboot or at least restart gdm.service after editing
> /etc/gdm/custom.conf to ensure the former and capture all the output of
> "sudo journalctl -b" for the latter.

Ah, sorry, didn't have the instructions for getting the full log. Will see if I can get another example.
Comment 10 Matthew Saltzman 2017-07-20 18:51:51 EDT
OK I am out of machines to upgrade and haven't hit the failure again. Is there a way to create an artificial .config/gnome-session/saved-session file that I could try?
Comment 11 Rui Matos 2017-07-21 06:23:28 EDT
See https://bugzilla.gnome.org/show_bug.cgi?id=775463 . Please follow up upstream.

Note You need to log in before you can comment on or make changes to this bug.