You are not logged in.
Pages: 1
I've got a new laptop recently (Thinkpad T420) and just installed archlinux for 3 days (dual boot with windows 7).
My CD/DVD Tray has automatically opened since the 2nd day I used archlinux, and whenever I try to close it, it'll re-opens immediately. But when I boot to windows 7, it works normally.
I use i3-gaps as my windows manager.
I hope someone can help me with this weird behavior.
Thank you!.
Offline
Does it open during the boot process or only after login?
I'd say some rogue script calling /usr/bin/eject in a loop?
Offline
Does it open during the boot process or only after login?
It only open after login at random time (immediately after login or hours after that)
I'd say some rogue script calling /usr/bin/eject in a loop?
I've just installed arch for a few days so I don't think I have any scripts like that.
Offline
And how did you install arch?
Also you started another thread last september, so how can have "just installed arch for a few days"?
What processes actually do run?
What if you replace /usr/bin/eject w/ a script that logs its invocation?
Offline
And how did you install arch?
I installed arch by following this guide.
Also you started another thread last september, so how can have "just installed arch for a few days"?
I was using my HP Compaq laptop when I started that thread, you can confirm it in the output of dmesg in that thread.
What processes actually do run?
It doesn't happen right now so I can't tell.
What if you replace /usr/bin/eject w/ a script that logs its invocation?
I've just rename /usr/bin/eject to /usr/bin/oldeject and replace with this script:
#!/usr/bin/bash
echo "eject `ps -o arg= $PPID`" >> /home/endlesslove/cdtray.log
oldeject
When it happens again, I will check the log file and reply.
P/s: I ran the eject command before replacing it with the script and my cd tray opened, and I no longer can eject it even when pressing the eject button of the cd tray lol
Last edited by Endless Love (2018-03-30 12:32:38)
Offline
So the cd tray just got opened now but this time it didn't re-open when I close it.
No log file was created. Any guesses about what the problem is?
Offline
The drives tend to eject (in hardware) if there's a bad/unreadable/undetectable disc in them - but if they're empty, even "sudo mount /dev/sr0 /mnt" should just report there's no disc.
Offline
The drives tend to eject (in hardware) if there's a bad/unreadable/undetectable disc in them - but if they're empty, even "sudo mount /dev/sr0 /mnt" should just report there's no disc.
There is no discs in the drive.
and
sudo mount /dev/sr0 /mnt
output
mount: /mnt: no medium found on /dev/sr0
Offline
Might you be pressing the eject button without noticing? As in when moving the mouse around and hitting the eject button without noticing.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Might you be pressing the eject button without noticing?
I read somewhere in the forum about this, so I did notice if I was pressing the eject button when I tried to close the tray.
As in when moving the mouse around and hitting the eject button without noticing.
I only use the mouse when browsing, but the cd tray started to open when I was coding or just after logging in, too.
Today, I notice that, when I've resumed from suspending for about one minute, the cd tray is automatically opened.
Offline
Well something™ will call the drive to eject, what brings us back to the question: what processes do actually run (notably when this happens)?
Offline
I only asked because it happens to one of my friends, it drives him mad
Something must be ejecting the cd tray, probably something you have running that issues the eject command directly.
What's the output of 'grep . /proc/sys/dev/cdrom/*'?
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Well something™ will call the drive to eject, what brings us back to the question: what processes do actually run (notably when this happens)?
Here is the proc list when it happened (removed firefox's content processes): https://pastebin.com/S0Du5pan
What's the output of 'grep . /proc/sys/dev/cdrom/*'?
Here is it:
/proc/sys/dev/cdrom/autoeject:0
/proc/sys/dev/cdrom/check_media:0
/proc/sys/dev/cdrom/debug:0
/proc/sys/dev/cdrom/info:CD-ROM information, Id: cdrom.c 3.20 2003/12/17
/proc/sys/dev/cdrom/info:drive name: sr0
/proc/sys/dev/cdrom/info:drive speed: 24
/proc/sys/dev/cdrom/info:drive # of slots: 1
/proc/sys/dev/cdrom/info:Can close tray: 1
/proc/sys/dev/cdrom/info:Can open tray: 1
/proc/sys/dev/cdrom/info:Can lock tray: 1
/proc/sys/dev/cdrom/info:Can change speed: 1
/proc/sys/dev/cdrom/info:Can select disk: 0
/proc/sys/dev/cdrom/info:Can read multisession: 1
/proc/sys/dev/cdrom/info:Can read MCN: 1
/proc/sys/dev/cdrom/info:Reports media changed: 1
/proc/sys/dev/cdrom/info:Can play audio: 1
/proc/sys/dev/cdrom/info:Can write CD-R: 1
/proc/sys/dev/cdrom/info:Can write CD-RW: 1
/proc/sys/dev/cdrom/info:Can read DVD: 1
/proc/sys/dev/cdrom/info:Can write DVD-R: 1
/proc/sys/dev/cdrom/info:Can write DVD-RAM: 1
/proc/sys/dev/cdrom/info:Can read MRW: 1
/proc/sys/dev/cdrom/info:Can write MRW: 1
/proc/sys/dev/cdrom/info:Can write RAM: 1
/proc/sys/dev/cdrom/lock:1
--
Also, I found something in the output of "journalctl -b 0" at line 1206 and 1410: https://pastebin.com/cPV6Wd0t
Last edited by Endless Love (2018-04-01 03:51:18)
Offline
root 241 0.0 0.1 88192 8552 ? Ss 09:15 0:00 /usr/lib/systemd/systemd-udevd
...
root 4162 0.0 0.0 88192 5316 ? S 10:15 0:00 /usr/lib/systemd/systemd-udevd
root 4164 0.0 0.0 70468 3260 ? D 10:15 0:00 /usr/lib/udev/cdrom_id --eject-media /dev/sr0
So there's a second systemd-udevd process and a (of course systemD'ohhh needs a custom eject tool) related eject call waiting for I/O response.... looks kinda shady to me ;-)
Why is there a second udevd process? It seems started 1h after the original one. Do they increment?
Offline
root 241 0.0 0.1 88192 8552 ? Ss 09:15 0:00 /usr/lib/systemd/systemd-udevd ... root 4162 0.0 0.0 88192 5316 ? S 10:15 0:00 /usr/lib/systemd/systemd-udevd root 4164 0.0 0.0 70468 3260 ? D 10:15 0:00 /usr/lib/udev/cdrom_id --eject-media /dev/sr0
So there's a second systemd-udevd process and a (of course systemD'ohhh needs a custom eject tool) related eject call waiting for I/O response.... looks kinda shady to me ;-)
Why is there a second udevd process? It seems started 1h after the original one. Do they increment?
I don't know.
So udev run the command for "eject button press event" even when the eject button wasn't pressed?
The cd tray just opened right now, but when I re-checked the process list, I didn't see the command to eject the cd drive anymore, but the command to lock:
/usr/lib/udev/cdrom_id --lock-media /dev/sr0
Hmm, I'm thinking about whether I should completely disable the cd/dvd drive...
Last edited by Endless Love (2018-04-01 13:41:32)
Offline
What if you replace cdrom_id by a script, like you did to eject, to check what is calling it? If it was me I would rather get to the bottom of this than disable the hardware.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
There should not be two udevd processes running, so i'd focus on where the additional one's coming from.
The timing is suspicious, so would certainly be even more udev daemons (if they run along the tray interaction)
You should also try the behavior for a different user login and w/o i3bar (random blame since i believe it runs all sorts of sub-scripts?) - though the daemon and eject are root owned, it might still be induced by something specific to your setup.
Offline
What if you replace cdrom_id by a script, like you did to eject, to check what is calling it? If it was me I would rather get to the bottom of this than disable the hardware.
I've replaced the cdrom_id like you said:
#!/usr/bin/bash
echo "[`date`] cdrom_id `ps -o arg= $PPID`" >> /home/endlesslove/cdroom_id.log
oldcdrom_id "$@"
It's been almost two days since then, the CD Tray didn't open anymore, but sometimes I still heard the sound of it (the sound that emits before the cd tray opens), and the cd tray's light flash at the same time (like it's about to open but somehow it just doesn't)
The script file has execute permission but there is no log file created:
$ ls -l /usr/lib/udev/cdrom_id
-rwxr-xr-x 1 root root 113 Apr 1 21:40 /usr/lib/udev/cdrom_id
There should not be two udevd processes running, so i'd focus on where the additional one's coming from.
The timing is suspicious, so would certainly be even more udev daemons (if they run along the tray interaction)
I just logged another processes list before replace cdrom_id and the time the new udev process spawns isn't extractly 1 hour after old udev process. So the time thing is maybe just coincidental (I don't know if I choose correct word here)
https://pastebin.com/M18V9gAA
You should also try the behavior for a different user login and w/o i3bar (random blame since i believe it runs all sorts of sub-scripts?) - though the daemon and eject are root owned, it might still be induced by something specific to your setup.
My arch setup is exactly like the Installation guide.
Application specific config is pull from my github here: https://github.com/endless-love/dotfiles
there is nothing about cd/dvd or udev things in it .....
Offline
You could add pstree (maybe 'pstree -p') to the script, that might help catch what calls cdrom_id.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I disabled the eject button by following this thread and the cd/dvd tray no longer auto opens. And somehow the eject button still works fine lol
Offline
Pages: 1