You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

I just attached the second DVD/CD-ROM drive to my machine. The `eject' command opens the second tray. The `eject -v /dev/sr0' command opens the first tray. The `eject -v /dev/sr1' command opens the second tray. I tried all those commands as a regular user (not root). I am sorry that my answer is not helpful but it seems that there is something wrong with your system and that is not some typical error.

Great, but on the other hand, suid should not be needed. I've seen that needed only in one instance, while testing the new hardware libraries in Trinity, but that (currently) is a development environment. Try some different desktop environments. If the problem disappears and other desktops handle device ejections with a normal 0755 /usr/bin/eject, then the problem is that particular desktop environment.

Recently I ran into the same suid problem. I can repeat your problem description here. All from the command line. I don't know why the problem occurs for some Slackware users and not others.

Do you know how to compile packages? If yes I ran across a patch that helps. If not I'll post a full package for Slackware 14.

The original patch is available here, but needs to be updated for Slackware. My updated version is here.

Please let me know. I want to see the patch work for a second person before nagging Pat.

Also, without the patch, try the following:

mount a CD/DVD
unmount the disk
eject -rv

If you see the following error message then the patch probably will help you:

eject: unable to eject, last error: Input/output error

By the way, I notice the eject failure occurs only after mounting and then unmounting an optical disk. Without mounting I can toggle my tray all day with or without the patch. I need the patch to eject after mounting/unmounting.

If you see the following error message then the patch probably will help you:

eject: unable to eject, last error: Input/output error

By the way, I notice the eject failure occurs only after mounting and then unmounting an optical disk. Without mounting I can toggle my tray all day with or without the patch. I need the patch to eject after mounting/unmounting.

@Woodsman

I was having this problem as well (-current, 32 bit).

I just confirmed that my problem matched your description of only failing after mount/umount.

I modified the slackbuild from current to apply your patch and confirm that it now works after mount/umount.

Well, the patch is not mine. I only tweaked the patch for Slackware --- but thanks.

I wish we knew why only some people are affected and not everybody.

Are you sure that only certain people are affected, or is it possible that only certain people are aware that they are affected?

In my own case, I do not often (ever) use the eject command directly on my main machine, a Toshiba laptop. But I have been setting up a newer desktop machine with -current and ran into the problem.

I noticed it on the desktop for several reasons:

1. The drive is a less convenient reach than the keyboard - so I eject instead pressing the button.
2. On the laptop my usage has tended to use cdrecord -eject instead. On the desktop I am not usually in a recording session so eject was more convenient.
3. I find optical media to be troublesome anyway, so if I had seen it happen before now I would likely have attributed it to the drive itself and pressed the button without further thought.

So if I had the problem before now I would not likely have recognized it. The coincidence of installing the new box and seeing this thread jolted the old brain cell into focus.

It affects me to, though I tend to just push the button on the front rather than type eject.

As for the root/non-root issues. On my system it seems like it works like this

eject -r only works when the tray is empty. It doesn't matter if you are root or not. If the tray has a disk in it (even if it has never been mounted) then I get a.

Code:

ioctl(3, CDROMEJECT, 0x6057bc) = -1 EIO (Input/output error)

If you don't specify the -r option, then after trying and failing the above, eject will fall through to the next mechanism it has available and try the scsi command instead (eject -s), but it looks like non-root users can't issue the scsi command and get a:

CDROM_LOCKDOOR lock or unlock door
usage:
int lock;
ioctl(fd, CDROM_LOCKDOOR, lock);
inputs:
Door lock flag, 1=lock, 0=unlock
outputs: none
error returns:
EDRIVE_CANT_DO_THIS Door lock function not supported.
EBUSY Attempt to unlock when multiple users
have the drive open and not CAP_SYS_ADMIN
notes:
As of 2.6.8.1, the lock flag is a global lock, meaning that
all CD drives will be locked or unlocked together. This is
probably a bug.
The EDRIVE_CANT_DO_THIS value is defined in <linux/cdrom.h>
and is currently (2.6.8.1) the same as EOPNOTSUPP

that seems to suggest that when run by root the unlock might not be safe as it won't care whether other users have the drive open or not.this bit is also interesting.

It all feels a bit messy, and there's a few things to think about here. Given this, I get the feeling that CDROM_LOCKDOOR is best avoided all-round. I wonder how easy it would be to patch this out of udev/udisks or whatever is leaving the lock enabled (which seems like a bug to me)

update:
After looking at how the udev code handles this sort of thing. it seems like 'eject' has pretty much been undermined (at least for use with cdroms). Seems one has to use:

Are you sure that only certain people are affected, or is it possible that only certain people are aware that they are affected?

You could be correct, especially after reading GazL's post.

Quote:

It affects me to, though I tend to just push the button on the front rather than type eject.

I use the physical button too, but I noticed the problem because my main office system case is several feet from my chair. Long ago I created a desktop shortcut to toggle the tray with eject -T. Yes, I still have to leave my chair to retrieve the disk, but the techie in me liked the idea of the eject shortcut. Moreso, programmatic ejection is important to me because I have an HTPC.

The eject -T command stopped working with Slackware 14.0 --- and remains broken. Slackware 14.0 was the first release without HAL, replaced by udisks(2).

I did not immediately update my systems to 14.0, doing so several months after the release. After I moved all of my systems to 14.0, I again noticed peculiarities with the eject command. I posted a query to find a way to determine the state of the tray. Pat responded with a short C snippet, after which you then responded to improve the crappy timeout method used in the original eject code.

The eject command breakage occurred with the transition away from HAL to udisks(2). I don't think the eject command sources are maintained anymore and like so much in free/libre software, most people no longer care.

As not all Slackers are using 14.0, that too probably contributes to people not noticing the breakage because previous releases have HAL, under which eject works.

Quote:

udisks --eject /dev/sr0

That command does not always work.

One example is the command is not a toggle like the original eject -T command. When there is no disk in an optical drive the udisks command fails with the following:

Eject failed: No media in drive

The command also does not work when the tray is open. Same error message. The udisks command is not a replacement for eject -T.

This thread prompted to investigate again because I use the Trinity desktop. Controlling removable devices in a HAL-less system required a new hardware detection method in Trinity, of which I am helping to test.

As a result of that testing, I probably am a tad more familiar with the eject breakage. I have tried several ways to dependably eject an optical disk or toggle the tray. The bottom line is the eject command is broken.

To replace the broken eject -T command, I now use a script wrapper around the basic C detection snippet Pat created. That wrapper script and C snippet work well, regardless of eject or udisks. Yet through my recent testing for Trinity I again stumbled across the fact that eject is broken in a HAL-less system. Without the patch the eject -T command now works only one way and no longer toggles. With the patch the eject -T command works both ways.

The only dependable method I found to fix the broken eject command is to suid /usr/bin/eject. Then the eject command works much better. Yet that is not the default installation permissions and along with my testing for Trinity and the above referenced thread, I again investigated.

The patch I found needed to be modified ever-so-slightly because of the patch you created to fix the eject command's tray detection status.

The patch linked in this thread works.

I don't know the appropriate strategy for handling the unlocking mechanism. I see the point in a multi-user system, but I am not concerned much about that in the broader scope because most Linux based systems these days, even with multiple users logged on to them, more than likely don't have such issues. That is, whoever is using the optical disk tray is the only person likely to want to eject the disk and not other users concurrently logged in. I understand the problem in a mainframe-like environment, but then again, optical drives are unlikely to be remotely used and controlled. I suppose somebody could SSH into a box, unlock a drive being used, and irritate the user, but discussing these corner cases seems academic.

In the end, the patch helps fix the eject command.

Conclusions?

* The eject command is funky in a HAL-less system.
* The udisks eject method works only when a disk is in the tray and is not a toggle.
* Setting /usr/bin/eject suid is an uncomfortable work-around.
* The patch in this thread helps avoid that work-around.
* My testing was not based upon any rigid scientific protocols.
* I'm no expert on any of this.