ttyUBS0 very busy

[ffusion]

Good morning! I've been progamming an aplication that needs to open /dev/ttyUSB0. Sometimes it does it properly but most of the time I need to run it with sudo. It's a big deal because I have to use it in a ROS(robotic operating system) where I can't sudo.

I used fuser to see who's using the port and it's opened by lots of processes like update-notifier, gnome procceses and so on.

Is there any way to fix it? Maybe modifying some premission tables or something similar.

Thx in advance.

[Mudgen]

Sounds like a udev rule might sort it. man udev

[Rubberman]

You are having problems with this on your workstation, and haven't tried it on the ROS, correct? If so, then it is to be expected that it would be accessed by gnome, et al because it and other processes are configured to respond to hardware events on USB ports, such as plugging in discs, etc. My guess is that some sort of "something was connected to this USB port" event occurred, and gnome et al are trying to see if it is a disc to auto-mount, a webcam to configure, etc. As Mudgen suggested, perhaps a udev rule can be configured to stop this behavior on this specific port.

[ffusion]

Thanks, I'll search information about these solutions. It happens the same with ROS, sometimes works but sometimes It works just fine. In fact when is not working I force it using sudo and then I run it without sudo and it works, it's some kind of unlocking the device. This is not a valid solution, though.

EDIT: I just checked how udev rules work but I can't access the workstation till monday. Anyway I'm unsure about what kind of rules might help:

Rename a device node from the default name to something else
Provide an alternative/persistent name for a device node by creating a symbolic link to the default device node
Change permissions and ownership of a device node

Or maybe you were suggesting any other option which is not listed here.

[Mudgen]

You'd be looking to create a rule that gave your user permissions on the node. There are reports of difficulty in getting that to work by setting something like mode 660 and a group to which the user belongs. It appears that just using mode 666 works in every case, and is probably safe on an embedded environment like this. First Google result for "udev ttyusb" is a quick tutorial:Udev

On some distros/versions the "udevinfo" command shown there is implemented as "udevadm info".