Why root user is not getting "Device or resource busy" response?

Question

I am working with GSM modem and using /dev/ttyUSB2 device.

Device is having proper rights:

$ ls -alh /dev/ttyUSB2
crw-rw---- 1 root dialout 188, 2 May 25 19:44 /dev/ttyUSB2

I am in dialout group and I can send AT command to this modem only once. After sending "ATD" command (echo -e -n "ATD ...;\r" > /dev/ttyUSB2), according to lsof /dev/ttyUSB2 process ModemManager opens this very file and if I send another AT command I get message:

bash: /dev/ttyUSB2: Device or resource busy

OK, so for some reason ModemManager is holding this file busy, but when this happens I can still send commands the same way, but from root user.

I've got two questions:

1. Why root user can override this "Device or resource busy" lock?
2. What rights / other settings regular user should have to bypass it like root user.

Answer 1

I recently ran into a similar error using wvdial on Gentoo (with a properly configured kernel, usb_modeswitch set up, wvdial settings verified to work on another system, etc.). Just as you described, root could easily initialize the modem and connect to the Internet, whereas a user in the dialout group would get an error message very much like yours. The relevant device file was:

$ ls -l /dev/ttyUSB2
crw-rw---- 1 root dialout 188, 2 Apr  6 01:43 /dev/ttyUSB2

The problem turned out to be that wvdial could not create a necessary lock file under /run/lock, which is owned by root:uucp on my system. After adding my regular user to uucp, the lock file could be created:

$ ls -la /run/lock
drwxrwxr-x  2 root uucp  80 Apr  6 01:43 .
drwxr-xr-x 10 root root 520 Apr  6 01:44 ..
-rw-r--r--  1 foo  foo   11 Apr  6 01:43 LCK..ttyUSB2
[...]

and the user was able to connect successfully, just like root. (In case you are wondering, find / -group uucp does not return anything other than that folder.)

I am not acquainted with ModemManager (nor used to writing to/reading from the device file directly), but given the similarity of our descriptions I suspect you might need to add your regular user to one more supplementary group. Try establishing a connection as root and check what additional files ModemManager touches; one of them (or a parent directory) may be at the root of the problem.

Answer 2

If you look at the code of the tty_reopen() function in the Linux kernel sources, itself called by tty_open_current_tty() itself called by tty_open() which is registered as the open function for tty file operations:

    if (test_bit(TTY_EXCLUSIVE, &tty->flags) && !capable(CAP_SYS_ADMIN))
        return -EBUSY;

EBUSY is returned if the tty has been marked with TTY_EXCLUSIVE (via a ioctl(TIOCEXCL)) and the process is not capable of CAP_SYS_ADMIN.

It's documented in the tty_ioctl man page:

Exclusive mode

TIOCEXCL void
Put the terminal into exclusive mode. No further open(2) operations on the terminal are permitted. (They fail with EBUSY, except for a process with the CAP_SYS_ADMIN capability.)

TIOCGEXCL int *argp
(since Linux 3.8) If the terminal is currently in exclusive mode, place a nonzero value in the location pointed to by argp; otherwise, place zero in *argp.

TIOCNXCL void
Disable exclusive mode.

So here, ModemManager likely opened the device and called ioctl(TIOCEXCL) on it, so no other process other than those running as root (or have the CAP_SYS_ADMIN capability) may open it.

You can see it doing that ioctl() in its port_connected() function in the code with this comment:

    /* When the port is connected, drop the serial port lock so PPP can do
     * something with the port.  When the port is disconnected, grab the lock
     * again.
     */