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): udev-120-5.20080421git.fc9 How reproducible: Always Steps to Reproduce: 1. run /sbin/start_udev on an F9 system 2. 3. 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. Summary: SELinux is preventing loadkeys (loadkeys_t) "write" to /etc/sysconfig/keyboard (etc_t). 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 (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) 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 '/etc/sysconfig/keyboard' Fix Command: restorecon '/etc/sysconfig/keyboard' Additional Information: Source Context unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c102 3 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 2.6.25.3-18.fc9.x86_64 #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)
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 kbd-1.12-31.fc9.i386
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? Thanks.
# man udevadm