## Deal with busy devices ##

[Author](authors.html): IvanVoras _FreeBSD_

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

----



### Concept ###

Understand what can cause a process to hang,
how to detect related processes, and how to fix the situation.


### Introduction ###

Occasionally there are situations where a userland process can completely hang due to kernel being stuck in the I/O path.
The most common way this could happen is by using `mount(8)` and `umount(8)` tools on unreliable and removable media (like USB and CD drives) and network devices (like *smbfs*).
In the general case, there's no reliable way to fix this situation except a reboot, but sometimes the system utilities can kill the stuck process and allow most of the system to continue running.

The first step is to identify the process that's stuck.
In most cases, this is obvious since it's the process the user has just started or is currently interfacing with.
But even in this case, it's useful to find out more information about the process for future reference and to help debug the problem.
A good starting point is the `ps(1)` utility. The command:

**ps axl**

will display a table containing (a)ll processes, even those without an attached terminal (x), together with (l)ock channels.
The last information is the same as the "STATE" field shown by the `top(8)` utility.

There are no fixed examples of which states inicate a "hung" process, but any debugging information submitted to developers should include the output of the above command for it, especially the MWCHAN field.

TODO: maybe cross-reference with [[View_and_configure_system_hardware]]?

fstat: identify active files

umount: unmount file systems

lsof: list open files

### Examples ###


### Practice Exercises ###


### More information ###

ps(1), fstat(1), kill(1), umount(8) and the third-party lsof utility
