Bug 84053 - redhat-config-user cannot read user database
Summary: redhat-config-user cannot read user database
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: redhat-config-users
Version: phoebe
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-02-11 16:44 UTC by Harris Landgarten
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-11 19:38:51 UTC

Attachments (Terms of Use)

Description Harris Landgarten 2003-02-11 16:44:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030120

Description of problem:
redhat-config-user throws an exeption in mainwindow, refresh_user with no other
explanation. useradd, userdel etc all work properly.

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

How reproducible:

Steps to Reproduce:

Actual Results:  messagebox with "the user database cannot be read. Program will
exit now.

Expected Results:  If there is somthing wrong with /etc/passwd /etc/group this
gives no information of what to do. /etc/passwd, /etc/group, /etc/shadow all
exist and are readable and command line user utilities all work.

Additional info:

Problem seems have something to do with associating names with gids

Comment 1 Brent Fox 2003-02-11 17:15:50 UTC
Have you modified any of these files by hand?  This error is usually caused by
people deleting a user from /etc/passwd but not from /etc/shadow.  In this case,
the files are out of sync and this breaks libuser, which is the backend that
redhat-config-users uses.

Comment 2 Harris Landgarten 2003-02-11 18:45:33 UTC
As far as I remember users have only to added and taken away with useradd,
userdel. Both the /etc/passwd file and /etc/shadow file have the same number of

It is failing in the try block with the call to userEnt.get. 

def refresh_users(self):
        self.user_dict = {}
        self.gid_dict = {}

        # pull up information about users and store the objects in
	# a dictionary keyed by user name
        i = 0
        for user in self.get_user_list(self.get_filter_data()):
            i = i + 1
            if i >= self.service_interval:
                i = 0

            userName = user.get(libuser.USERNAME)[0]
            userEnt = self.ADMIN.lookupUserByName(userName)
            self.user_dict[user] = userEnt
            # try to get a name to associate with the user's primary gid,
            # and attempt to minimize lookups by caching answers
				gidNumber = userEnt.get(libuser.GIDNUMBER)[0]
                messageDialog.show_message_dialog(_("The user database cannot be
read.  Program will exit now."))

Comment 3 Brent Fox 2003-02-11 19:05:24 UTC
Try adding a print statement to /usr/share/redhat-config-users/mainWindow.py
file to show us which user name it's tripping up on.

In the refresh_users() function, add:

'print userName' after the 'userName = user.get(libuser.USERNAME)[0]

That should print out the user name of each user as it's processed.  What is the
last user name that it prints out?

Comment 4 Harris Landgarten 2003-02-11 19:27:56 UTC
I found a rogue user is /etc/shadow- . The problem on this machine is resolved
but the problem of poor error notification with no user direction remains. The
average user is not going to know what is wrong so he will call you. You can do

Comment 5 Brent Fox 2003-02-11 19:38:51 UTC
The problem is that the database can be broken in any number of ways.  There's
no way for redhat-config-users to know what the problem might be.  All it knows
is that the call to libuser fails.  Creating this error message was in response
to bug #73375, so the behavior has improved.

The majority of these bugs is caused by people who try to delete a user manually
by deleting them from /etc/passwd.  They forget to delete the user in
/etc/shadow, so the two files get out of sync.  I would argue that the "average
user", as you say, will not run into this problem because they don't modify
those files by hand.

But there's no way for me to give the user a set of steps to take because
there's no way to know in what way the files are corrupted.  Maybe there are
mismatched entries in the files.  Maybe there are invalid (non-ASCII) characters
in the files.  Maybe something else.  There's no way for redhat-config-users to

I think the current error message at least gives the user some indication that
something is wrong with the user and group database.  At any rate, I cannot
change the behavior at this point since we are past string freeze.  Resolving as
'notabug' since this is the expected behavior.

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