Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Udisks trying to mount unavailable smb share freezes the desktop momentarily #1323

Open
cyberpunkrocker-zero opened this issue Oct 15, 2024 · 3 comments

Comments

@cyberpunkrocker-zero
Copy link

Arch Linux recently moved to udisks2. Now, I have a separate server hosting a Samba service, which server is currently down for hardware reasons. Udisks is periodically, in every 10 minutes or so, trying to mount the unavailable smb share, as seen from the journal:

loka 14 20:43:06 neverwinter systemd[1]: mnt-smbshare.automount: Got automount request for /mnt/smbshare, triggered by 1942 (awesome)
loka 14 20:43:06 neverwinter systemd[1]: Mounting /mnt/smbshare...
loka 14 20:43:06 neverwinter kernel: CIFS: enabling forceuid mount option implicitly because uid= option is specified
loka 14 20:43:06 neverwinter kernel: CIFS: enabling forcegid mount option implicitly because gid= option is specified
loka 14 20:43:06 neverwinter kernel: CIFS: Attempting to mount //192.168.1.10/share
loka 14 20:43:12 neverwinter mount[61982]: mount error(113): could not connect to 192.168.1.10Unable to find suitable address.
loka 14 20:43:12 neverwinter systemd[1]: mnt-smbshare.mount: Mount process exited, code=exited, status=32/n/a
loka 14 20:43:12 neverwinter systemd[1]: mnt-smbshare.mount: Failed with result 'exit-code'.
loka 14 20:43:12 neverwinter systemd[1]: Failed to mount /mnt/smbshare.
loka 14 20:43:12 neverwinter kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
loka 14 20:43:12 neverwinter kernel: CIFS: VFS: cifs_mount failed w/return code = -113

I suppose this is as it should work, but... the real issue with this is that EVERY time this is run, the whole desktop freezes for a few seconds!!! I was running journalctl -f on a terminal to verify the simultaneousity of the mount/freeze events. This kind of thing shouldn't be happening!

The process 1942 (awesome) mentioned in the above excerpt is my window manager's (Awesome WM) process. I don't understand why it would be the triggering process, and why udisks is allowed to freeze it?

I had to temporarily comment out the smb share entry in /etc/fstab to make desktop to run smoothly again.

Arch Linux
linux-lts-6.6.56
udisks2-2.10.1
Awesome WM running on X server

@vojtechtrefny
Copy link
Member

Hi, I don't think this is our fault -- we support mounting only for block devices, not for network devices (and even for block devices we don't mount anything automatically, just when explicitly asked by the DE).

The mounting here is done by systemd and not udisksd so it looks like it's from a mount unit generated from fstab.

@cyberpunkrocker-zero
Copy link
Author

cyberpunkrocker-zero commented Oct 16, 2024

Ok, thanks for the info and for your patience. I'll go bothering the systemd people, then :)

@tbzatek
Copy link
Member

tbzatek commented Oct 22, 2024

EVERY time this is run, the whole desktop freezes for a few seconds!!!

Sounds like a bad programming practice, waiting for I/O synchronously. Unrelated to UDisks, your desktop needs to be fixed.

Anyway, the 10 minutes interval equals to UDisks housekeeping interval. The state cleanup thread is checking mounts and related block devices. There might be a chance that some of the calls will trigger autofs mount.

If you kill/mask udisksd, does the issue go away?

@tbzatek tbzatek reopened this Oct 22, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants