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 451104 - udev restart causes loss of access to pseudo terminals and eth interface loses IP address
Summary: udev restart causes loss of access to pseudo terminals and eth interface lose...
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-12 19:30 UTC by Kent Baxley
Modified: 2009-01-20 11:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-20 11:30:30 UTC

Attachments (Terms of Use)

Description Kent Baxley 2008-06-12 19:30:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5

Description of problem:
When I try and restart udev while the system is running I lose access to 
anything with a pts, and my network interface loses its ip at least.  I 
can still access the box via tty and an ifdown/ifup will bring the 
network interface back.

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

How reproducible:

Steps to Reproduce:
1. run /sbin/start_udev on an F9 system

Actual Results:
Loss of access to anything with a pseudo terminal...for example, if you are running konsole or gnome-terminal on the desktop, the terminals will go unresponsive after issuing the start_udev command.  Closing the terminal window and reopening it seems to restore functionality.

Network interface loses IP address, running ifdown/ifup will bring it back.

Expected Results:
Network interface should retain its IP address and pseudo terminals should continue to function.  

Additional info:
I'm not sure how related this is, but, I had SELinux enabled and also got this message in the SETroubleshooter when trying to reproduce the problem.  Running restorecon '/etc/sysconfig/keyboard' didn't seem to help.

SELinux is preventing loadkeys (loadkeys_t) "write" to /etc/sysconfig/keyboard

Detailed Description:

SELinux is preventing loadkeys (loadkeys_t) "write" to /etc/sysconfig/keyboard
(etc_t). The SELinux type etc_t, is a generic type for all files in the
directory and very few processes (SELinux Domains) are allowed to write to this
SELinux type. This type of denial usual indicates a mislabeled file. By default
a file created in a directory has the gets the context of the parent directory,
but SELinux policy has rules about the creation of directories, that say if a
process running in one SELinux Domain (D1) creates a file in a directory with a
particular SELinux File Context (F1) the file gets a different File Context
(F2). The policy usually allows the SELinux Domain (D1) the ability to write,
unlink, and append on (F2). But if for some reason a file
(/etc/sysconfig/keyboard) was created with the wrong context, this domain will
be denied. The usual solution to this problem is to reset the file context on
the target file, restorecon -v '/etc/sysconfig/keyboard'. If the file context
does not change from etc_t, then this is probably a bug in policy. Please file a
bug report ( against the
selinux-policy package. If it does change, you can try your application again to
see if it works. The file context could have been mislabeled by editing the file
or moving the file from a different directory, if the file keeps getting
mislabeled, check the init scripts to see if they are doing something to
mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v

Fix Command:

restorecon '/etc/sysconfig/keyboard'

Additional Information:

Source Context                unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c102
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc/sysconfig/keyboard [ file ]
Source                        loadkeys
Source Path                   /bin/loadkeys
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           kbd-1.12-31.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-55.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   mislabeled_file
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain
                              #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64
Alert Count                   1
First Seen                    Thu 12 Jun 2008 11:24:19 AM EDT
Last Seen                     Thu 12 Jun 2008 11:24:19 AM EDT
Local ID                      c38bcb0a-eff1-4940-be1a-712bf6d61e5a
Line Numbers                  

Raw Audit Messages            

host=localhost.localdomain type=AVC msg=audit(1213284259.868:1318): avc:  denied  { write } for  pid=27304 comm="loadkeys" path="/etc/sysconfig/keyboard" dev=sda5 ino=3383313 scontext=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file

host=localhost.localdomain type=SYSCALL msg=audit(1213284259.868:1318): arch=c000003e syscall=59 success=yes exit=0 a0=4021a8 a1=7fff518c3530 a2=7fff518c3680 a3=7f78498a2810 items=0 ppid=27288 pid=27304 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="loadkeys" exe="/bin/loadkeys" subj=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 key=(null)

Comment 1 Harald Hoyer 2008-06-13 06:13:50 UTC
You are _not_ supposed to run start_udev on a fully booted system :)

You may want "udevadm trigger" or "udevtrigger" followed by "udevsettle".

For the selinux messages, open a bug against selinux-policy or kbd.

$ rpm -qf /bin/loadkeys

Comment 2 Kent Baxley 2008-07-09 15:29:19 UTC
Ok. I've finally had a chance to go back and try the commands you suggested
instead of start_udev, and, although I'm not losing my IP Address information, I
am still losing control over my pseudo terminals.

If I run udevadm trigger or udevtrigger, the terminals (e.g. konsole,
gnome-terminal) will go unresponsive after issuing either command.  

The udev version I'm now running is:  udev-124-1.fc9.2

Running udevtrigger on an older release like RHEL5 does not reproduce this sort
of behavior.  

Also, is there any documentation anywhere on the proper way to restart udev, if
start_udev is not recommended?


Comment 3 Harald Hoyer 2009-01-20 11:30:30 UTC
# man udevadm

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