Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1517487 - gdm will not start X (or work at all) if a UID is duplicated in /etc/passwd
Summary: gdm will not start X (or work at all) if a UID is duplicated in /etc/passwd
Alias: None
Product: Fedora
Classification: Fedora
Component: accountsservice
Version: 27
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-26 04:12 UTC by Doug McLaren
Modified: 2018-11-30 21:17 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-11-30 21:17:45 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Debian BTS 854792 None None None 2017-11-26 04:12:07 UTC
Red Hat Bugzilla 1147689 None CLOSED accounts-daemon misbehaves with duplicate UIDs 2018-11-05 16:41:25 UTC

Description Doug McLaren 2017-11-26 04:12:08 UTC
Description of problem:

If /etc/passwd (or NIS, LDAP, etc. equivalent I assume, but I didn't test these) has two lines with different usernames but the same UIDs, gdm will start but will not start X and gdm will not log anything particularly useful about what the problem actually is.

Version-Release number of selected component (if applicable):

Fedora 27

How reproducible:

At will.

Steps to Reproduce:

1. ssh into the host from another and make changes from there rather than doing it at the console of the box, because you'll be killing the X server and may have to log in remotely to fix it anyways, so you might as well be doing that the entire time.

2. Add these lines/users to /etc/passwd :

   echo "user1:x:9999:9999:DELETE ME ACCOUNT1:/dev/null:/dev/null" >> /etc/passwd
   echo "user2:x:9999:9999:DELETE ME ACCOUNT2:/dev/null:/dev/null" >> /etc/passwd

(You don't need /etc/shadow or home directories for this test case.)

3. Restart gdm (and kill X in the process, so be prepared for that.)

   killall -v gdm

4. Observe the lack of a login screen or X window system at all.

5. Remove those two lines from /etc/passwd with "vipw"

6. Restart gdm

   killall -v gdm

7. Note that you can log in again.

Actual results:

A blank screen, system logs or startup messages.

Expected results:

A gdm login page

Additional info:

This message will be logged by accountsservice when this is encountered :

Nov 25 21:48:50 okapia gdm-launch-environment][1013]: AccountsService: ActUserManager: new user in accounts service with object path /org/freedesktop/Accounts/User9999

gdm will not log anything useful when it happens, however if debug logging is enabled in /etc/gdm/custom.conf this will be the last thing that gdm logs before it just stops :

Nov 25 21:16:15 okapia gdm-launch-environment][3315]: AccountsService: ActUserManager: waiting for user manager to load before finding user 'gdm'

Debian bug 854792 -- -- covers the same issue in Debian.

Redhat Bugzilla Bug 1147689 – "accounts-daemon misbehaves with duplicate UIDs" has the same root cause, but it manifests in a different way.

The bug itself seems to be in the accountsservice component, but the gdm component is affected too.

The Debian bug report seems to not have the developers taking the report very seriously, but I do have to agree with the defect reporter -- this is not an uncommon configuration and even if we did decide that two users with the same UID is not permitted, some sort of error message that says exactly this would be far, far better than having gdm simply refuse to give you a login page.

Comment 1 Peter Robinson 2018-04-21 20:42:17 UTC
can you test the 0.6.46 release on it's way to F-27, if it doesn't fix it might be worth reporting upstream at too

Comment 2 Ben Cotton 2018-11-27 15:59:03 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Ben Cotton 2018-11-30 21:17:45 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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