Bug 37724

Summary: autoeject always on
Product: [Retired] Red Hat Linux Reporter: Gordon Messmer <gordon.messmer>
Component: magicdevAssignee: John (J5) Palmieri <johnp>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: jkeck
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-25 17:14:22 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 Gordon Messmer 2001-04-26 04:34:08 UTC
I have an IDE CDROM attached as the secondary master drive (/dev/hdc). 
Since upgrading to Red Hat 7.1, the drive ejects every time the disc is
unmounted.  The autoeject feature has not been enabled locally:

$ cat /proc/sys/dev/cdrom/autoeject
0

Comment 1 Gordon Messmer 2001-04-28 03:25:36 UTC
Additionally, autoclose is not working, but:
$ cat /proc/sys/dev/cdrom/autoclose
1

Clearly, something is weird, so I tried reversing the value of autoeject (since
that's the one that's iritating me):
# echo 1 > autoeject

That didn't fix it, so I tried changing it back:
# echo 0 > autoeject

Now, autoeject is off, like it should be.  So, the following are true:
1) The system was originally behaving as if autoeject was "1", but reading
autoeject indicated that it as "0"
2) Changing the value of autoeject didn't turn off the autoeject behavior
3) Changing the value of autoeject back to "0" *did* turn off the autoeject
behavior

What has me confused is #1.  Doesn't reading from the files in /proc return
values from kernel memory?  Why would autoeject say 0 when it behaved like 1?

Comment 2 Arjan van de Ven 2001-04-28 08:08:52 UTC
Both the magicdev and autorun programs are known to cause these effects.
The /proc variables are "global" defaults, and can be overridden per device.
My bet is that "rpm -e magicdev" will fix this.

Comment 3 Gordon Messmer 2001-04-29 18:57:38 UTC
I disabled autorun/magicdev in the GNOME control panel and the problem hasn't
come back yet.  Since there's no indication that this will happen in the GNOME
control panel, should this be considered a bug?  Is there a way to turn it off?

If not, then I'll just carry on without them.  (I use automount for my removable
media, anyway...)

Comment 4 Arjan van de Ven 2001-04-29 19:19:56 UTC
I consider changing this behavior a bug. I'll assign to the magicdev package
to see if it can be fixed in that package.

Comment 5 Owen Taylor 2001-08-01 17:04:06 UTC
Magicdev doesn't touch the autoeject flags. It copied code from
autorun that did turn autoeject off, but I disabled that as
of the version in 7.1.

So, I don't think this explains the problem. 

There were some fairly serious non-workingness in the autoeject
functionality at one point. I sent a patch to Alan and Jens,
but I'm not sure if it made it in or not.


Comment 6 Owen Taylor 2001-08-01 18:44:08 UTC
The autoeject bug mentioned above is filed as #50627. Looking at
it again, it doesn't seem to be related. (Except as pretty good
evidence that autoeject isn't always on for most people with
magicdev, because with the bug in 50627, if you turn on
autoeject, you can't even close your drive door with magicdev
running.)

My only guess on this bug is that the version of magicdev being
tested here isn't actually the one from 7.1. (0.3.5-3)

What are the results when you:

 rpm -q magicdev
 rpm -q kernel


Comment 7 Gordon Messmer 2001-08-02 04:52:02 UTC
I can't tell you what version it was, unfortunately.  I am *currently* running
Ximian's GNOME, but I thought that I was not at the time.  If I thought the
problem was GNOME related, then I wouldn't have sent a bug report to you.  I
disabled autorun functions in the GNOME control panel, reset the global flags,
and haven't had the problem since.

I can't see bug 50627, but when you say "you can't even close your drive door
with magicdev running", it sounds like a symptom of the problem I had.  I could
manually close the CDROM tray, but not with software.  Neither 'eject -t' nor
'mount' would cause it to close.  IIRC.

BTW, is there a way to view the auto(eject|close) flags for individual devices?
 Seems like the kind of thing that should show up under
/proc/ide/ide1/hdc/settings for hdc...

Comment 8 John (J5) Palmieri 2004-08-25 17:14:22 UTC
Closing bug.  Magicdev has been removed in favor of
gnome-volume-manager in the development branch.