Error at shutdown: "remove ioctl on home failed"
 

My laptop has an SSD and a traditional SATA drive. Each drive has a LUKS volume, which in turn has an LVM volume inside. The LVM on the SSD contains the / and swap mount points, and the LVM on the SATA drive contains the /home mount point.

When I shutdown, one of the last things that happens is I get several lines (maybe 15 or so) of the following error:
It seems to happen when it's trying to close the /home mount point. It doesn't happen for any of the others. After about a half a screen of this, it continues on and shuts down. I haven't seen where this has caused any problems, and it doesn't seem to be affecting anything that I'm aware of.

However, it's kind of bugging me that I don't know what it is, so I'm wondering what's going on and is there any way to clear it up?

I think I might have made a little progress on this one.

After more research, it seems that this error indicates a file or process is open or in use on this volume, which seems completely reasonable.

Some more reading lead me to the lsof and fuser commands, which I hadn't encountered yet. They both seem to indicate that a bash process is in use on /home, and trying to close the volume manually yielded similar results, so I'm guessing that's the culprit.

However, I'm not sure if having bash in use on /home is normal behavior, it strikes me kinda odd but might be totally expected.

Still haven't figured out the best way to deal with this yet, I thought about maybe trying to manually kill it with the rc.local_shutdown script, but that doesn't seem like a very elegant solution.

Is there a better way?

An active bash process having open files in /home would indicate a logged-in user or process. It could be a cron job, a script related to some process running in the background or something entirely different.

You should find out exactly what that process is and what it does. lsof | grep /home should point you in the right direction. The third column shows the user name running the process in question.

(FWIW, on my Slackware system "lsof | grep /home" returns nothing unless I'm logged in as a non-root user.)

Please accept my sincerest apologies for not getting back to this thread for so long.

Ser Olmy, you were exactly right that when I run lsof | grep /home as a non-root user, I get a few results, but running it as root returns nothing. However, if I log in as root and shutdown, I still get the exact same message, so I guess there must be something else going on?

One other detail I noticed, is the line directly preceding this error indicates that it is attempting to lock the LUKS volume, which I believe it can't due to /home still being mounted. I'm still thinking that the problem is that /home can't be unmounted for some reason, but I thought I would mention it.

If anyone else has any ideas on what I could look into, it would be greatly appreciated.

OK, interesting update. I've been looking around inside the rc.6 script, and I noticed that just prior to the cryptsetup volumes being closed, the script turns off swap, unmounts local file systems, and then re-mounts root as read only, in that order.

This makes me think that it's root being mounted that's causing the problem. I'm tempted to comment out the line that remounts it as read-only, but I don't know what the consequences of that might be? Does root need to be mounted until a certain point in the shutdown process?

Well, the first thing you should consider is whether the problem is actually a problem. Part of the reason for the gymnastics in rc.6 is that it's not always possible for one reason or another to actually umount a partition on shutdown with the standard sequence. But if they're closed, made read-only, and synced, it's more or less the same thing. It's not uncommon to see this issue with LVM or luks (and especially with a combination of the two). Add RAID to the mix and it's almost assured that some "error" or another will be kicked out at shutdown.

You might be able to figure out the magic order to shut down whatever combination of things you're using without hitting any errors. But it's unlikely that there are any real problems with what's happening now, and if you get your fix wrong, there could be. I see the same thing here on my own encrypted /home, by the way.

Thanks for the reply Pat! I couldn't see where it was causing any issues, but I didn't know if there was something happening that wasn't obvious, and I thought it would be a good exercise to learn a little more about the system.

I'll probably let this one go for now, at least until I get enough experience to go tinkering with it.