Bug 179011
Summary: | Remove pam_console_apply from init script | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel Walsh <dwalsh> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | nalin, rvokal |
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: | 2006-01-31 21:31:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Daniel Walsh
2006-01-26 15:51:16 UTC
What happens if you have unclean shutdown, and there's a leftover console lock entry when udev runs on startup? The pam_console_apply helper doesn't clean up the lock; rc.sysinit will continue to clear the lock, and udev will function as it does now. But calling pam_console_apply to reset permissions on devices which the user might have owned when the reset button was pressed became unnecessary when we made /dev non-persistent. What I'm trying to say is that the lock is there *when udev starts on boot* from before the reset button was pressed - is udev using this stale information when it recreates the devices? Oh, I see what you mean now. I don't see any calls to udev in the mkinitrd script. Are we still calling udev before rc.sysinit, or am I missing part of the boot process? It's at the top of rc.sysinit, but it's before the read/write remount of /, so there could be leftover cruft in /var. I'll test this, just need to get in front of a machine of recent enough vintage. Yeah, you can't remove it because there could be a stale console.lock file when udev runs. |