sleep: cannot read realtime clock: Invalid argument

[hferreira23]

IMPORTANT
Please read README and Known issues before creating the issue.

Please fill out the below information:
Describe the issue
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviroment:

• Windows build number: Microsoft Windows [Version 10.0.18362.592]
• Security Software: N/A
• WSL version 1
• ArchWSL version 19.11.16.0 fully updated via pacman
• ArchWSL Installer type zip
• Launcher version [e.g. 19030700] (Type Arch.exe version at a Command Prompt)

Additional context
When I try to do a sleep command on the console the following error pops up:

sleep: cannot read realtime clock: Invalid argument. It seems to be related with rtc devices on /dev.

This behavior doesn't happen on ubuntu wsl for example.

[joelazar]

Hi,

Same happened with me as well, but luckily I could localize the problem better as it started right after when I initiated a bigger pacman update.
The problem is caused by the new glibc:

[2020-02-12T14:14:43+0100] [ALPM] upgraded glibc (2.30-3 -> 2.31-1)
[2020-02-12T14:15:36+0100] [ALPM] upgraded lib32-glibc (2.30-3 -> 2.31-1)

When I downgraded it to the previous one it solved my problems (actually, for me not just sleep, but other packages which were based on rust were affected as well (ripgrep, fd etc.)).

downgrade glibc lib32-glibc

I hope it helps for you too.

[hferreira23]

That also worked for me. Thanks!

I'm curious if the behavior also happens on "standard" Arch.

[hferreira23]

It seems that on "standard" Arch the issue doesn't happen. Anyone able to confirm it?

It could be something WSL specific.

[dbz2k]

is htop broken for everyone also? when I try to use it I end up with just a black screen? The other question I got is how long can we keep glibc downgraded won't arch linux depend newer glibc soon?

EDIT: using just this command for downgrading glibc worked also
pacman -U https://archive.archlinux.org/packages/g/glibc/glibc-2.30-3-x86_64.pkg.tar.xz

than in /etc/pacman.conf I added IgnorePkg = glibc to ignore package section.

[nickspoons]

I was also affected by this, also on WSL 1 (although I didn't actually install WSL using this tool).

sleep, ripgrep, fd, htop all frozen/unresponsive.

Downgraded to 2.30-3 to get running.

[deadalnix]

Debian recently upgraded it's libc and I'm now running into the same problem. @yuk7 do you know if the build you mention is available yet? I do not wish to enable the insider program because I got pretty much as many regressions as I got improvements from it when I did and sometime it left me in tough spot when thing broke unexpectedly.

[shanoaice]

I've seen this problem in the microsoft/WSL issues. I can confirm it is a WSL 1 specific problem, but a fix isn't available for WSL 1 yet

[cdunford]

Is the glibc downgrade safe (ie it won't break other packages)?

[shanoaice]

Is the glibc downgrade safe (ie it won't break other packages)?

Unsure, but I haven't experienced any problem yet.

[nickspoons]

Nor have I, after 6 months of heavy WSL usage with this downgrade.

[deadalnix]

I ended up upgrading by rolling out a custom sleep executable and use to unlock the situation. This is relatively easy to do, even though I wouldn't recommend doing that road to anyone and everyone. If you need more instruction on how to do this, you probably don't want to be doing this.

[cdunford]

I rolled back glibc and have not had any issues with anything I used so far.

[enihcam]

glibc 2.30-3 conflicts with libxcrypt @yuk7

[cdunford]

@enihcam - I assume you're referring to a recent update to libxcrypt? I've noticed trying to do a package upgrade today it now fails because there is an update to libxcrypt which conflicts.

[cdunford]

Unfortunately this seems be a little more impactful now. I've had several packages that seem to have implicit dependencies on newer versions of glibc such that I basically can't run a pacman upgrade any longer. Are others experiencing the same thing?

[B3RR10]

I tried to update glibc a couple of weeks ago and stopped getting the error. I now have the latest version (2.32-4) and it works fine. Still using WSL1.

[cdunford]

@B3RR10 - thanks for the tip. I tried upgrading 2.32-4 as well; everything seems good 😄

[cdunford]

Issue has returned for me again. I am on glibc 2.32-5 now, but my Win10 was also upgraded from 1809 to 1909 which actually seems to be the cause somehow. I rolled back to glibc 2.32-4 and am still seeing this issue.

[escape0707]

I think as this issue has been fixed in the upstream: microsoft/WSL#4898 , and Windows 10 20H2 is available for upgrade it can be closed now.

[hferreira23]

@cdunford the issue is only fixed in Windows 20H2 version.

Closing this.