'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

Ledti · 2015-08-15 09:48:07

You can try adding the following snippet to the systemd PKGBUILD (at the beginning of the prepare() function), and rebuilding:

# https://github.com/systemd/systemd/issues/867
git revert -n -m 1 7189be2

It works for me. Not sure if that's a sane way to revert a single commit, but I didn't feel like making a patch.

Harey · 2015-08-15 12:00:11

FWIW, I have my system on various encrypted partitions (root,var,swap,home,data) and all of them (execpt for root) throw this error at shutdown... Reverting to systemd 222 and all is back to normal.

Last edited by Harey (2015-08-15 12:00:35)

hoschi · 2015-08-16 16:37:50

The "Failed umounting /run/user/..." disappeared for several reboots, but is now back again.

Last edited by hoschi (2015-08-16 17:14:33)

TheRinger · 2015-08-17 12:39:24

Harey wrote:

FWIW, I have my system on various encrypted partitions (root,var,swap,home,data) and all of them (execpt for root) throw this error at shutdown... Reverting to systemd 222 and all is back to normal.

Any version conflicts to watch out for before downgrading systemd? I have the same problem and would like to test this.

EDIT: Can confirm that the shutdown issue disappears on downgrading systemd, but not from journalctl. I don't have any encrypted partitions, but perhaps the systemd upgrade simply caught an issue that hadn't been caught before? Regardless, there's no issue shutting down, just the error.

For references sake, this thread talks about a similar problem, writing it off as something to ignore:
https://bbs.archlinux.org/viewtopic.php?pid=1554049
(relevant post):

djgera wrote:

Do not worry, /var is unmounted right after pivot_root into a tmpfs, systemd-shutdown is executed again here.
shutdown hook is deprecated since mkinitcpio-16 (mkinitcpio-generate-shutdown-ramfs.service does the work at shutdown)

And this thread also introduces the possibility that this is a non-issue, especially for those of us who have no problem shutting down save for the admittedly unnerving failure messages:
https://bbs.archlinux.org/viewtopic.php?id=177732
(relevant post):

brain0 wrote:

Despite the messages, the partitions actually get unmounted. After systemd killed all processes, it replaces itself with a shutdown tool that tries hard to unmount everything and (at least in my case) eventually succeeds (it's that thing that spams your console with many messages before shutting off - use 'halt' instead of 'shutdown' to see the messages).

Both of the quoted users happen to be developers by the way, so I suspect they know what they're talking about. Should be able to upgrade back to systemd-224 on your next -Syu and just ignore the shutdown messages.

Last edited by TheRinger (2015-08-17 12:55:02)

Harey · 2015-08-17 17:35:22

TheRinger wrote:

Harey wrote:
FWIW, I have my system on various encrypted partitions (root,var,swap,home,data) and all of them (execpt for root) throw this error at shutdown... Reverting to systemd 222 and all is back to normal.
Any version conflicts to watch out for before downgrading systemd? I have the same problem and would like to test this.

I downgraded both my systems without any further conflicts. Can't say more though.

TheRinger wrote:

EDIT: Can confirm that the shutdown issue disappears on downgrading systemd, but not from journalctl. I don't have any encrypted partitions, but perhaps the systemd upgrade simply caught an issue that hadn't been caught before? Regardless, there's no issue shutting down, just the error.

You should try to configure your journald to use

Storage=volatile

in /etc/systemd/journald.conf.

BTW, I prefer to wait for upstream to adress this error. The thread you quoted is fairly old in comparison to systemd's quick devopment...

Greets
Harvey

Last edited by Harey (2015-08-17 17:37:38)

toketin · 2015-08-17 19:12:42

I can confirm it on my arch up to date, i've made a backup today on my new SSD from the previous arch's partition on HHD, where i didn't see this bug.

hoschi · 2015-08-19 13:15:10

In my eyes something like a "none issue" doesn't exist, if it is labeled failed, warning, error or in similiar fashion. Either the message is wrong (lucky but annoying) or your in some kind of trouble.

betseg · 2015-08-19 14:25:28

Happens to me sometimes, not always. If it happens, .bash_history disappears.

tiresiaselciego · 2015-08-25 15:37:30

SOLUTION (sorry i dont speak english)

check etc/group:

autologin:x:1000:tiresias

solved edit etc/passwd:

tiresias:x:1000:100:tiresias,,,,:/home/tiresias:/bin/bash

por:

tiresias:x:1000:1000:tiresias,,,,:/home/tiresias:/bin/bash

permissions issue =0

I Solved my problem

juego · 2015-08-25 15:55:07

Have the same problem.
Have an updated arch. No gdm of any sort. Openbox as Wm.
I'm user 1000.
I can see that I'm the owner of /run/user/1000
This is the content of the folder:

$ ls -la /run/user/1000
total 0
drwx------ 6 juego juego 120 25 aoû 09:05 .
drwxr-xr-x 3 root  root   60 25 aoû 08:55 ..
drwx------ 2 juego juego  60 25 aoû 10:09 dconf
dr-x------ 2 juego juego   0 25 aoû 08:55 gvfs
drwx------ 2 juego juego  80 25 aoû 08:55 pulse
drwxr-xr-x 2 juego juego  80 25 aoû 08:55 systemd

in /etc/passwd, I'm set to 1000:1000 and my group also.

lokesh987 · 2015-09-04 09:57:08

Hello,

Any update on this issue? I am having the same experience (so far not "trouble") as described in the previous posts.

Just to extend the error message: when two users are logged in, then the shutdown message reports the failure of both users with their corresponding user-id, e.g.:

failed to unmont run/user/1000
failed to unmount /run/user/1001

I did find an explanation somewhere saying that the unmounting (not only of the above but also the home directories) is being done anyway, so this "failure" notification could safely be ignored. However, I prefer to consider error messages as warnings that should be taken serious.

Lokesh

lokesh987 · 2015-09-04 10:01:15

Question to the moderators: why is this thread in the newby corner? Experts may not look into issues reported here, and apparently it is not that easy to explain.

BlueYoshi · 2015-09-06 19:58:51

Same issue here, happens every couple shutdowns.

Checked /etc/group and /etc/passwd, my user is 1000, and /run/user/1000 belongs to my user as well. I don't understand what's causing this at all.

Martinsos · 2015-09-09 13:46:33

I am also having this problem, since I updated arch yesterday, and have everything the same like @BlueYoshi. My user is member of groups wheel and bumblebee (I have wheel enabled in sudoers).

remingtontonpon · 2015-09-11 02:34:40

I want to see the output of "lsof" command (Just to be sure, run as root).

# lsof /run/user/1000

Would you paste it?

juego · 2015-09-11 03:47:55

remingtontonpon wrote:

I want to see the output of "lsof" command (Just to be sure, run as root).
# lsof /run/user/1000
Would you paste it?

$ sudo lsof /run/user/1000
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
COMMAND    PID  USER  FD   TYPE DEVICE SIZE/OFF   NODE NAME
at-spi-bu 3607 juego DEL    REG   0,39           19623 /run/user/1000/dconf/user
pulseaudi 3684 juego DEL    REG   0,39           22022 /run/user/1000/orcexec.6zOXwY
thunderbi 6039 juego mem    REG   0,39        2 188999 /run/user/1000/dconf/user

Ledti · 2015-09-18 20:11:23

If somebody else wants to test if reverting a specific commit fixes the problem for them as well, you can follow these steps (run from terminal):

This will build and install systemd 226 (currently in testing), while reverting commit 7189be2.

sudo pacman -S subversion --asdeps
svn checkout --depth=empty svn://svn.archlinux.org/packages
cd packages
svn update -r245605 systemd
cd systemd/trunk
sed -i 's/debug/!debug/g' PKGBUILD
sed -i '33i \ \ git revert -n -m 1 7189be2' PKGBUILD
makepkg -sic

(reboot)

Now test to see if you can reproduce the error during subsequent reboot/shutdowns.

flannelhead · 2015-09-23 06:47:01

I'm able to confirm Ledti's findings. I saw those errors, although they didn't appear consistently on every shutdown. The errors disappeared when the mentioned comment was reverted. It's systemd's job to unmount remaining filesystems on shutdown, but it seems to start too early. I reported about my findings in the issue tracker.

andmars · 2015-10-08 05:51:32

I've guild systemd 227 from the abs PKGBUILD and haven't seen this error ever since.

mark as [SOLVED]?

Last edited by andmars (2015-10-09 16:41:23)

juego · 2015-10-23 14:14:51

andmars wrote:

I've guild systemd 227 from the abs PKGBUILD and haven't seen this error ever since.
mark as [SOLVED]?

+1

hoschi · 2015-10-27 09:27:44

Seems fixed for me, too.

This is actually expected: we keep journald running till the very end of the system, it's not killed during the normal shutdown phase, but only in the final killing spree.

Killing spree...

Mox · 2015-11-15 13:38:18

Hi,

I'm experiencing similar issues. However, I got the suspiction, they might be related to the system running out of RAM. My rig uses an SSD, got 16GB of ram but no SWAP file to protect the SSD. Now, when I manage to get to the point where the system kills processes because it runs out of RAM, it will later on fail to unmount my home folder.
Could anyone check, if their problems are affected by a shortage of RAM as well?

Best Regards,
mox

Minbari · 2015-11-23 11:35:33

I can confirm that editing the /etc/passwd solved the issue.
from:

minbari:x:1000:100::/home/minbari:/bin/zsh

to:

 minbari:x:1000:1000::/home/minbari:/bin/zsh

Matipa456 · 2022-10-25 22:31:03

Hi! Well, I have the same problem, and nothing here seems to work. The directory is owned by user matias (me) and group users, my UID is 1000, my GID is 984 and the GID of users is also 984. However, there's something interesting I found out...

$ ls -l /run/users/1000/
drwx------ 2 matias users  60 Oct 25 15:43 at-spi
srw-rw-rw- 1 matias users   0 Oct 25 15:42 bus
drwx------ 3 matias users  60 Oct 25 15:42 dbus-1
drwx------ 2 matias users  60 Oct 25 15:43 dconf
dr-x------ 2 matias users   0 Dec 31  1969 doc
srwxr-xr-x 1 matias users   0 Oct 25 15:43 eww-server_e077df8212d0bce6
drwx------ 2 matias users  60 Oct 25 15:42 gcr
drwx------ 2 matias users 140 Oct 25 15:42 gnupg
dr-x------ 2 matias users   0 Oct 25 15:43 gvfs
drwx------ 2 matias users  40 Oct 25 15:43 gvfsd
drwx------ 2 matias users  80 Oct 25 15:47 keyring
drwxr-xr-x 2 matias users  60 Oct 25 15:42 p11-kit
srw-rw-rw- 1 matias users   0 Oct 25 15:42 pipewire-0
-rw-r----- 1 matias users   0 Oct 25 15:43 pipewire-0.lock
drwx------ 2 matias users  60 Oct 25 15:43 polybar
drwx------ 2 matias users  80 Oct 25 15:43 pulse
-rw------- 1 matias users   4 Oct 25 16:33 rofi.pid
drwxr-xr-x 5 matias users 140 Oct 25 15:42 systemd

Do you see the permissions of both the doc and the gvfs directories? They don't have writing permissions... idk if it's related, but my theory is this is the cause of the problem. However, I can't see if it's true because I can't change the permissions by any mean... If someone knows a way to do it on a tmpfs without risk, let me (and us) know. Maybe it's a minor problem with no side effects, but it can also be a symptom of a bug or vulnerability we don't know of yet

cfr · 2022-10-26 02:40:02

Matipa456, please start a new thread and link to this one if you think it is relevant. systemd has changed a lot in 7 years!

Arch Linux

#26 2015-08-15 09:48:07

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#27 2015-08-15 12:00:11

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#28 2015-08-16 16:37:50

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#29 2015-08-17 12:39:24

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#30 2015-08-17 17:35:22

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#31 2015-08-17 19:12:42

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#32 2015-08-19 13:15:10

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#33 2015-08-19 14:25:28

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#34 2015-08-25 15:37:30

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#35 2015-08-25 15:55:07

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#36 2015-09-04 09:57:08

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#37 2015-09-04 10:01:15

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#38 2015-09-06 19:58:51

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#39 2015-09-09 13:46:33

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#40 2015-09-11 02:34:40

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#41 2015-09-11 03:47:55

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#42 2015-09-18 20:11:23

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#43 2015-09-23 06:47:01

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#44 2015-10-08 05:51:32

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#45 2015-10-23 14:14:51

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#46 2015-10-27 09:27:44

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#47 2015-11-15 13:38:18

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#48 2015-11-23 11:35:33

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#49 2022-10-25 22:31:03

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

#50 2022-10-26 02:40:02

Re: 'Failed unmounting /run/user/1000' whenever i shutdown or reboot.

Board footer