Bug 132902

Summary: Deleting user you are logged in as creates huge problems.
Product: [Fedora] Fedora Reporter: Brian "netdragon" Bober <netdragon>
Component: system-config-usersAssignee: Nils Philippsen <nphilipp>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 2   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-23 11:50:18 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Brian "netdragon" Bober 2004-09-18 23:19:39 EDT
Description of problem:
I created an account in the Fedora Core 2 installer and then deleted
my account in system-config-users, and then re-created it with a
different user ID, and when I re-logged in, I got an error "An error
occured while loading or saving configuration information or gs.  Some
of your configuration settings may not work properly." with the dialog
box titled "Gnome settings daemon"

It's hard to close the dialogs coming up, because they keep on coming.

How reproducible:


Steps to Reproduce:
1. Install FC2
2. Log in on first boot with the non-root user name you created
3. Delete the user you are logged in as, with erasing the user's home
directory selected, and then re-create it with a different user-id
4. Log out, then try to log in again
  
Actual results:
Repeated error messages shown above

Expected results:
No error messages

Additional info:
No matter how many times you re-create it, and reboot with the user
deleted, you still get the errors. If you run "startx" while logged in
as that user it gives all kinds of errors.
Comment 1 Brian "netdragon" Bober 2004-09-18 23:22:27 EDT
You might want to investigate if the same thing happens if you use the
"userdel" tool. Perhaps this is a problem with gnome-settings-daemon,
but still, no user deletion tool should work while you are logged in
as that user. A simple check would fix that.
Comment 2 Brian "netdragon" Bober 2004-09-19 23:07:19 EDT
Btw, the error messages given by the x server on the command line when
I ran startx as user boberb said something about /tmp/glockd-boberb or
something like that.

Here's a workaround: I deleted user boberb, then I went to init 3
deleted everything in /tmp, then deleted /var/spool/mail/boberb, then
deleted /var/run/sudo/boberb, and everything was fine after that...
But shouldn't the graphical user tool not let you delete a user who's
logged in?

Besides that, there also seems to be a bug in X Windows, as even if I
did do that, it should still let me log back in if I re-create the
user. It seems to be some kinda lock file issue?
Comment 3 Nils Philippsen 2004-11-10 10:58:51 EST
I can see no (easy, reliable) way to determine which user originally
called s-c-users, but I can check for running processes of the user
about to be deleted. Code that does that is in current CVS.
Comment 4 Brian "netdragon" Bober 2004-11-10 13:11:26 EST
So if a user is logged on, they should have at least one running
process (if even just the shell) , and then system-config-users would
deny deletion of that user until they are logged of. That sounds like
a good solution.
Comment 5 Nils Philippsen 2004-11-11 03:01:04 EST
It wouldn't directly deny it, but put a very prominent warning in the
dialog, e.g.:

"""
There are currently processes running that are owned by 'test1'!  This
user is probably still logged in.  Do you really want to remove the
user 'test1'?
"""

The first sentence is in bold. I think that should cut it.
Comment 6 Nils Philippsen 2004-11-18 12:44:24 EST
Update is on the way... Should hit the repositories in the next day or so.
Comment 7 Brian "netdragon" Bober 2004-11-18 21:56:28 EST
Thank you :-)
Comment 8 Tim Powers 2005-05-19 17:39:59 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-440.html