Optical Drive powers/spins up when switching ttys/vts

pixxt · 2026-03-28 22:26:48

Hello! Installed Arch to bare metal last week for the first time in over a decade after testing in KVM/Qemu for several months hoping to make it my new daily driver over Slackware. I have an annoying problem that only happens on only Arch and other Arch based distros besides Artix I've tried.

When switching between ttys/vts my Blu-Ray RW drive spins up for a few seconds and there is a second or two pause with switching in the process.

Just to rule out Arch itself being the culprit I've installed and/or ran from live usb a few other distros in the last week to narrow down what could be going on.

Arch = Optical Drive spins up
CachyOS = Optical Drive spins up
EndeavourOS = Optical Drive spins up

Ubuntu = Perfectly fine
Fedrora = Perfectly fine
PopOS = Perfectly fine
Slackware Current = Perfectly fine
Artix with OpenRC and d-init = Perfectly fine

I searched for info about this annoyance and one other post I only could find was this asked several months ago on the Linux Questions forum.

https://www.linuxquestions.org/question … 175755055/

I am perplexed what could be causing this.

dimich · 2026-03-28 23:42:12

pixxt wrote:

When switching between ttys/vts my Blu-Ray RW drive spins up for a few seconds and there is a second or two pause with switching in the process.

For clarity, does this happen when you boot without GUI?
Does it spin up at boot time? (I suppose yes, due to hw initialization).
Does it spin up when you:
- switch from vt1 to vt2 by pressing Alt+F2?
- switch back to vt1 by presing Alt+F1?
- switch to already allocated vt2 again?
- switch with Alt + Left Arrow / Alt + Right Arrow keys instead of Alt+F1/Alt+F2?

Speculating, I could think about systemd implicitly opening drive's /dev/ node somehow.

frostschutz · 2026-03-29 09:22:51

Is that with a disc inside or not?

I have two optical drives and nothing spins up for me, but they're usually empty anyway... even if you try to access it, it will simply tell you no medium found.

Otherwise spin-ups can happen e.g. when something is searching for UUID. For example `findfs UUID=does-not-exist` scans all drives while searching in vain on all drives, partitions, etc...

One way to avoid that is to write /dev/disk/by-uuid/XYZ instead of UUID=xyz in /etc/fstab... then no scans other than those triggered by udev itself will take place.

Not quite sure how VT switches would trigger those, though.

Last edited by frostschutz (2026-03-29 09:24:47)

xerxes_ · 2026-03-29 10:36:52

You may try to find this in different ways:

journalctl -f
dmesg -w
dbus-monitor
udevadm cat
fuser -mv /dev/cdrom
lsof /dev/cdrom  # this may require tuning
lsfd | grep sr0
set|less

Last edited by xerxes_ (2026-03-29 11:16:36)

pixxt · 2026-03-29 21:36:15

dimich wrote:

pixxt wrote:
When switching between ttys/vts my Blu-Ray RW drive spins up for a few seconds and there is a second or two pause with switching in the process.
For clarity, does this happen when you boot without GUI?
Does it spin up at boot time? (I suppose yes, due to hw initialization).
Does it spin up when you:
- switch from vt1 to vt2 by pressing Alt+F2?
- switch back to vt1 by presing Alt+F1?
- switch to already allocated vt2 again?
- switch with Alt + Left Arrow / Alt + Right Arrow keys instead of Alt+F1/Alt+F2?
Speculating, I could think about systemd implicitly opening drive's /dev/ node somehow.

For clarity, does this happen when you boot without GUI? Yes
Does it spin up at boot time? (I suppose yes, due to hw initialization). Yes but all distros I've use do this at startup
Does it spin up when you:
- switch from vt1 to vt2 by pressing Alt+F2? Yes
- switch back to vt1 by presing Alt+F1? Yes
- switch to already allocated vt2 again? Yes
- switch with Alt + Left Arrow / Alt + Right Arrow keys instead of Alt+F1/Alt+F2? Yes

Speculating, I could think about systemd implicitly opening drive's /dev/ node somehow.

Maybe?

I ran htop on one of the the ttys and tabbed over to the i/o tab whilst switching though ttys and found (udev-worker) as the top process running and using i/o everytime I switched ttys, so I switched ttys a dozen times and everytime it triggered (udev-worker)

Last edited by pixxt (2026-03-29 21:49:13)

seth · 2026-03-29 22:21:05

Is this a USB drive?

pixxt · 2026-03-29 22:44:24

seth wrote:

Is this a USB drive?

No, It's Sata

dimich · 2026-03-29 22:56:49

pixxt wrote:

I ran htop on one of the the ttys and tabbed over to the i/o tab whilst switching though ttys and found (udev-worker) as the top process running and using i/o everytime I switched ttys, so I switched ttys a dozen times and everytime it triggered (udev-worker)

Does it spin up even if you aren't logged in? I.e. right after boot, when switch between VTs with login prompts.

In case of switching to or from logged-in vt it can be explained: systemd is trying to juggle with device permissions according to active "seat". I observe events emitted for video, audio and some other devices. We have to figure out what udev rule runs external or builtin program which touches the drive.
In case of non-logged-in vt I have no idea yet what events can be triggered.

Can you run "udevadm monitor" as root and watch what events are triggered by switching? If you have a chance, it's better to login remotely for monitoring to avoid interference.

frostschutz · 2026-03-29 23:10:01

OK, I can reproduce the issue with discs put into the drives - empty drives stay silent for me so I never noticed before. And like you say, it completely delays the switch.

There actually are udev change events for optical drives as you switch ttys (shown in `udevadm monitor --property`).

See if this workaround works for you:

Create an empty file /etc/udev/rules.d/70-uaccess.rules or copy /usr/lib/udev/rules.d/70-uaccess.rules to /etc and comment out the "optical drives" section. Follow up with `udevadm control --reload`, `udevadm trigger` (or reboot).

I removed the uaccess rules on a hunch (since the tag was shown in the monitor event), removing it seems to get rid of these change events and terminal switches no longer seem to affect the drives. I haven't traced it further as to the whats and whys of it. There might be a better solution...

pixxt · 2026-03-29 23:36:28

dimich wrote:

pixxt wrote:
I ran htop on one of the the ttys and tabbed over to the i/o tab whilst switching though ttys and found (udev-worker) as the top process running and using i/o everytime I switched ttys, so I switched ttys a dozen times and everytime it triggered (udev-worker)
Does it spin up even if you aren't logged in? I.e. right after boot, when switch between VTs with login prompts.
In case of switching to or from logged-in vt it can be explained: systemd is trying to juggle with device permissions according to active "seat". I observe events emitted for video, audio and some other devices. We have to figure out what udev rule runs external or builtin program which touches the drive.
In case of non-logged-in vt I have no idea yet what events can be triggered.
Can you run "udevadm monitor" as root and watch what events are triggered by switching? If you have a chance, it's better to login remotely for monitoring to avoid interference.

Yes it spins up on all ttys logged on or not, even on the vt with an X.org session running

pixxt · 2026-03-29 23:38:06

frostschutz wrote:

OK, I can reproduce the issue with discs put into the drives - empty drives stay silent for me so I never noticed before. And like you say, it completely delays the switch.
There actually are udev change events for optical drives as you switch ttys (shown in `udevadm monitor --property`).
See if this workaround works for you:
Create an empty file /etc/udev/rules.d/70-uaccess.rules or copy /usr/lib/udev/rules.d/70-uaccess.rules to /etc and comment out the "optical drives" section. Follow up with `udevadm control --reload`, `udevadm trigger` (or reboot).
I removed the uaccess rules on a hunch (since the tag was shown in the monitor event), removing it seems to get rid of these change events and terminal switches no longer seem to affect the drives. I haven't traced it further as to the whats and whys of it. There might be a better solution...

Thanks I'll try this out in the next half day or so.

dimich · 2026-03-29 23:38:53

frostschutz wrote:

Create an empty file /etc/udev/rules.d/70-uaccess.rules or copy /usr/lib/udev/rules.d/70-uaccess.rules to /etc and comment out the "optical drives" section.

Or create new rule to run after 70-uaccess.rules (e.g. /etc/udev/rules.d/99-no-uaccess.rules) with

ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG-="uaccess"

May be related: https://github.com/systemd/systemd/issues/40223

Last edited by dimich (2026-03-29 23:39:25)

frostschutz · 2026-03-30 07:48:24

dimich wrote:

May be related: https://github.com/systemd/systemd/issues/40223

Well, some mysterious third-party daemon takes the blame there... not sure what it could be, I tried to terminate everything and it still happens.

The access itself seems to go through /usr/lib/udev/{ata,cdrom}_id. It runs `/usr/lib/udev/ata_id --export /dev/sr0` which in turn runs cdrom_id.

Removing the executable flag with `chmod -x /usr/lib/udev/cdrom_id` also works around the issue (but breaks wanted identifications).

There's a rule in 60-persistent-storage.rules that runs this... not sure how to skip this for "unnecessary" change events, or if that's even the root cause of it.

I'm unable to dig deeper here, so I pretty much give up at this point.

Last edited by frostschutz (2026-03-30 08:06:34)

seth · 2026-03-30 08:09:44

Well, some mysterious third-party daemon takes gets the blame there...

Random guess: https://github.com/systemd/systemd/comm … f0ce3d465b

xerxes_ · 2026-03-30 11:38:48

Maybe this:
In file /usr/lib/udev/rules.d/60-persistent-storage.rules in part:

# probe filesystem metadata of optical drives which have a media inserted
KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \
  IMPORT{builtin}="blkid --hint=session_offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"

comment/hash line like this:

#KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \
  IMPORT{builtin}="blkid --hint=session_offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"

to test if it works.

dimich · 2026-03-30 15:34:10

pixxt wrote:

Yes it spins up on all ttys logged on or not

Interesting. I can reproduce spin up with USB DVD drive, but only if logged in at least at one of VTs. When neither of VTs are logged in, no any event reported by udevadm monitor during switch.
Also the drive spins up after login and logout, expectedly.
By the way, there is no observable delay of switch. Maybe because the drive is USB, not SATA.

As a workaround, I would exclude specific drive or all drives of this class from uaccess and nail permissions to specific user or group (e.g. "optical", like the good old days). Of course, it's quite insecure in multi-user environment: one allowed user can use a drive while another user is logged in locally, or read disk inserted during another user session.

pixxt · 2026-04-02 00:46:52

xerxes_ wrote:

Maybe this:
In file /usr/lib/udev/rules.d/60-persistent-storage.rules in part:

# probe filesystem metadata of optical drives which have a media inserted
KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \
  IMPORT{builtin}="blkid --hint=session_offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"

comment/hash line like this:

#KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \
  IMPORT{builtin}="blkid --hint=session_offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"

to test if it works.

Thanks for the suggestion but this caused a timeout at boot as it was scanning all disks by uuid and could and error about not finding any disks and I was kicked into emergency mode shell prompt. I went ahead and hashed out the following line and it did nothing either.

pixxt · 2026-04-02 00:48:56

dimich wrote:

frostschutz wrote:
Create an empty file /etc/udev/rules.d/70-uaccess.rules or copy /usr/lib/udev/rules.d/70-uaccess.rules to /etc and comment out the "optical drives" section.
Or create new rule to run after 70-uaccess.rules (e.g. /etc/udev/rules.d/99-no-uaccess.rules) with
ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG-="uaccess"
May be related: https://github.com/systemd/systemd/issues/40223

frostschutz wrote:

OK, I can reproduce the issue with discs put into the drives - empty drives stay silent for me so I never noticed before. And like you say, it completely delays the switch.
There actually are udev change events for optical drives as you switch ttys (shown in `udevadm monitor --property`).
See if this workaround works for you:
Create an empty file /etc/udev/rules.d/70-uaccess.rules or copy /usr/lib/udev/rules.d/70-uaccess.rules to /etc and comment out the "optical drives" section. Follow up with `udevadm control --reload`, `udevadm trigger` (or reboot).
I removed the uaccess rules on a hunch (since the tag was shown in the monitor event), removing it seems to get rid of these change events and terminal switches no longer seem to affect the drives. I haven't traced it further as to the whats and whys of it. There might be a better solution...

Thanks! Both these suggestions worked for me. No more disk spins and delay when switching ttys.

As I said in the OP that only Arch and Arch Based distros with systemd had this annoyance but I also just tried out OpenSuse tumbleweed and it too had the same problem, so I'm guessing theres something strange in newer releases of systemd and/or udev?

In testing I just wondering all distros I tested with systemd also spawns about 40 (udev-worker) processes/pids each and every-time I switch ttys? But thats a minor curiosity.

Thanks to all that helped with this!

seth · 2026-04-02 07:43:30

As I said in the OP that only Arch and Arch Based distros with systemd

Which systemd version do the other OS run?
https://github.com/systemd/systemd/comm … 6c167177a9 introduced in 258 seems to have cause massive device accesses.

I suspect the same cause is the reason for https://bbs.archlinux.org/viewtopic.php?id=309989 and friends

pixxt · 2026-04-13 09:14:33

seth wrote:

As I said in the OP that only Arch and Arch Based distros with systemd
Which systemd version do the other OS run?
https://github.com/systemd/systemd/comm … 6c167177a9 introduced in 258 seems to have cause massive device accesses.
I suspect the same cause is the reason for https://bbs.archlinux.org/viewtopic.php?id=309989 and friends

According to Distrowatch

Distro : systemd version

Pop!_OS : 255.4

Fedora : 258

Ubuntu : 257.9

OpenSUSE Tumbleweed : 259.5 < --- Behaves like Arch during tty switch.

seth · 2026-04-13 12:05:10

Wdym "according to distrowatch" - the question is which were actually in use (though the only outlier here would be fedora) not what's currently shipped.

Arch Linux

#1 2026-03-28 22:26:48

Optical Drive powers/spins up when switching ttys/vts

#2 2026-03-28 23:42:12

Re: Optical Drive powers/spins up when switching ttys/vts

#3 2026-03-29 09:22:51

Re: Optical Drive powers/spins up when switching ttys/vts

#4 2026-03-29 10:36:52

Re: Optical Drive powers/spins up when switching ttys/vts

#5 2026-03-29 21:36:15

Re: Optical Drive powers/spins up when switching ttys/vts

#6 2026-03-29 22:21:05

Re: Optical Drive powers/spins up when switching ttys/vts

#7 2026-03-29 22:44:24

Re: Optical Drive powers/spins up when switching ttys/vts

#8 2026-03-29 22:56:49

Re: Optical Drive powers/spins up when switching ttys/vts

#9 2026-03-29 23:10:01

Re: Optical Drive powers/spins up when switching ttys/vts

#10 2026-03-29 23:36:28

Re: Optical Drive powers/spins up when switching ttys/vts

#11 2026-03-29 23:38:06

Re: Optical Drive powers/spins up when switching ttys/vts

#12 2026-03-29 23:38:53

Re: Optical Drive powers/spins up when switching ttys/vts

#13 2026-03-30 07:48:24

Re: Optical Drive powers/spins up when switching ttys/vts

#14 2026-03-30 08:09:44

Re: Optical Drive powers/spins up when switching ttys/vts

#15 2026-03-30 11:38:48

Re: Optical Drive powers/spins up when switching ttys/vts

#16 2026-03-30 15:34:10

Re: Optical Drive powers/spins up when switching ttys/vts

#17 2026-04-02 00:46:52

Re: Optical Drive powers/spins up when switching ttys/vts

#18 2026-04-02 00:48:56

Re: Optical Drive powers/spins up when switching ttys/vts

#19 2026-04-02 07:43:30

Re: Optical Drive powers/spins up when switching ttys/vts

#20 2026-04-13 09:14:33

Re: Optical Drive powers/spins up when switching ttys/vts

#21 2026-04-13 12:05:10

Re: Optical Drive powers/spins up when switching ttys/vts

Board footer