2

I would like to ask about the impact of a process stuck in the 'D' uninterruptible sleep state on a Linux system when an user logs out.

Is ending an user session by logout (not shutdown or restart) even possible in case of a lingering unkillable user process in disk sleep or would the system freeze/crash on logout attempt? If logout is successful despite the stuck process, what happens to the process? Does it get orphaned and reparented? Does it carry on to the next user session? Also, if the process was accessing a shared memory segment before entering the uninterruptible sleep, what happens to that shared memory and other processes using it? Are they also be affected? How does a Linux system handle such situations?

This state is hard to reproduce on purpose so I cannot figure out a way to test it myself in order to know the answer.

I apologize if a similar question was answered before somewhere; I have tried searching various Linux websites and message boards for answers to these questions but most pages seem to only explain what the uninterruptible sleep is and how to prevent/fix the problem. I did not manage to find any resources explaining what happens to such process when an user session ends without rebooting the system. Most sources just recomment to restart the system to get rid of it.

  • Have you tried setting up two virts, one as a NFS server and then have the other virt hard mount a directory off of that server? Then turn off the NFS server with the client virt still running and see what happens to a process with file handles open to that mount point. – thrig Jun 5 '17 at 14:09
  • Depends on distro, if systemd is used, what settings are in place. systemd changes behavior that folks are used to. The process will still be in D state, but system will reap any other user processes and eventually they should be able to log out. What have you tested thus far? – Aaron Jun 5 '17 at 16:52
0

A 'D' process is unkillable, the common scenario being a stale NFS file handle. If the process is backgrounded then a logout can occur, but it will have no effect on the sleeping process.

0

First of all, thanks everyone for the answers! I have made some tests so I will try to answer my own question.

I tested the handling of uninterruptible processes on logout by systemd (on Ubuntu) and upstart (on Chromium OS). I have found that the easiest way to cause an arbitrary user process to enter the 'D' sleep state is by putting it in the freezer cgroup subsystem and changing the freezer.status to FROZEN. (https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt) After this I tried to end the user session by logging out. As far as I can tell, the expected behavior on logout for both systemd and Chromium OS flavor of upstart is that all non-root processes should be killed before the session manager exits.

What happened on logout was that user session exited cleanly and in case of Chromium OS, cryptohome also seems to have unmounted without problems (I haven't found anything in system logs suggesting unmount failure). As expected, the frozen process survived logout in both cases and was still visible in top. It did not use any resources and wasn't accessible in any way after relogging into the account. There were also no problems or errors when relogging into the account. The process disappeared as soon as I changed the freezer.status from FROZEN to THAWED. I am not sure if this behavior is different when the process enters the 'D' state for different reasons, like being blocked trying to access the NFS etc. but I would expect the results to be similar.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.