eza
eza copied to clipboard
eza-community
bug: eza crashes when using --long --color-scale=age to show contents of root(/) directory under any user (root or non-root)
- The version of eza:
v0.17.0 [+git] - The command-line arguments you are using:
--long --color-scale=age
-` nikel@archhost
.o+` --------------
`ooo/ OS: Arch Linux x86_64
`+oooo: Host: A35S
`+oooooo: Kernel: 6.6.9-arch1-1
-+oooooo+: Uptime: 19 mins
`/:-:++oooo+: Packages: 1487 (pacman)
`/++++/+++++++: Shell: bash 5.2.21
`/++++++++++++++: Resolution: 3456x2160
`/+++ooooooooooooo/` DE: GNOME 45.2
./ooosssso++osssssso+` WM: Mutter
.oossssso-````/ossssss+` WM Theme: gradience-shell
-osssssso. :ssssssso. Theme: Adwaita [GTK2/3]
:osssssss/ osssso+++. Icons: Adwaita [GTK2/3]
/ossssssss/ +ssssooo/- Terminal: gnome-terminal
`/ossssso+/:- -:/+osssso+- CPU: AMD Ryzen 7 5800H with Radeon Graphics (16) @ 4.463GHz
`+sso+:-` `.-/+oso: GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series
`++:. `-/+/ Memory: 4358MiB / 15340MiB
.` `/
Error:
$ RUST_BACKTRACE=1 RUST_BACKTRACE=full /sbin/eza --long --color-scale=age /
thread 'main' panicked at library/std/src/sys/unix/time.rs:77:9:
assertion failed: tv_nsec >= 0 && tv_nsec < NSEC_PER_SEC as i64
stack backtrace:
0: 0x55b90c244bef - <unknown>
1: 0x55b90c1e95dc - <unknown>
2: 0x55b90c2161ec - <unknown>
3: 0x55b90c24618f - <unknown>
4: 0x55b90c245d73 - <unknown>
5: 0x55b90c246d2a - <unknown>
6: 0x55b90c246828 - <unknown>
7: 0x55b90c2467b6 - <unknown>
8: 0x55b90c2467a1 - <unknown>
9: 0x55b90c182f34 - <unknown>
10: 0x55b90c183102 - <unknown>
11: 0x55b90c1ab588 - <unknown>
12: 0x55b90c1b57c5 - <unknown>
13: 0x55b90c1b6c32 - <unknown>
14: 0x55b90c1d9782 - <unknown>
15: 0x55b90c1d765a - <unknown>
16: 0x55b90c1d6c65 - <unknown>
17: 0x55b90c1d30bd - <unknown>
18: 0x55b90c18a603 - <unknown>
19: 0x55b90c1dc213 - <unknown>
20: 0x7fe9e0eeacd0 - <unknown>
21: 0x7fe9e0eead8a - __libc_start_main
22: 0x55b90c189c85 - <unknown>
23: 0x0 - <unknown>
Aborted (core dumped)
Successful execution when trying to color-scale by size. For me it looks like the error may be coming from 1 Jan 1970 when eza compares dates taken from mounted fat32 partitions (/boot, /efi)
$ RUST_BACKTRACE=1 RUST_BACKTRACE=full /sbin/eza -M --long --color-scale=size /
lrwxrwxrwx - root 18 Sep 2023 bin -> usr/bin
drwxr-xr-x - root 1 Jan 1970 boot [/dev/nvme0n1p7 (vfat)]
drwxr-xr-x - root 5 Jan 16:28 dev [dev (devtmpfs)]
drwxr-xr-x - root 1 Jan 1970 efi [/dev/nvme0n1p1 (vfat)]
drwxr-xr-x - root 5 Jan 16:28 etc
drwxr-xr-x - root 5 Dec 2022 home [/dev/nvme0n1p8 (btrfs)]
drwxr-xr-x - root 20 Dec 2023 kaliroot [/dev/nvme0n1p2 (ext4)]
drwxr-xr-x - root 5 Dec 2022 keybase
lrwxrwxrwx - root 18 Sep 2023 lib -> usr/lib
lrwxrwxrwx - root 18 Sep 2023 lib64 -> usr/lib
drwxr-xr-x - root 27 Sep 2023 mnt
drwxr-xr-x - nikel 3 Jan 07:55 nikel_big_downloads
drwxr-xr-x - root 4 Jan 16:09 opt
dr-xr-xr-x - root 5 Jan 16:28 proc [proc (proc)]
drwxr-x--- - root 20 Dec 2023 root
drwxr-xr-x - root 5 Jan 16:30 run [run (tmpfs)]
lrwxrwxrwx - root 18 Sep 2023 sbin -> usr/bin
drwxr-xr-x - root 5 Dec 2022 srv
dr-xr-xr-x - root 5 Jan 16:29 sys [sys (sysfs)]
drwxrwxrwt - root 5 Jan 16:50 tmp [tmpfs (tmpfs)]
drwxr-xr-x - root 5 Jan 16:25 usr
drwxr-xr-x - root 5 Jan 16:28 var
My mounted partitions if this matters:
$ sudo mount | column -t
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=7814968k,nr_inodes=1953742,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p4 on / type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1531)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)
/dev/nvme0n1p8 on /home type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@home)
/dev/nvme0n1p2 on /kaliroot type ext4 (rw,noatime,stripe=32)
/dev/nvme0n1p5 on /var/lib/docker type ext4 (rw,noatime,stripe=32)
/dev/nvme0n1p7 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/nvme0n1p1 on /efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1570828k,nr_inodes=392707,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
obsidian-bin-1.5.3-x86_64.AppImage on /tmp/.mount_obsidirPZmFL type fuse.obsidian-bin-1.5.3-x86_64.AppImage (ro,nosuid,nodev,relatime,user_id=1000,group_id=1000)
This is related to #666 and #735 and needs a fix in the standard library (https://github.com/rust-lang/rust/issues/108277)
Is there anything I can do to fix this or to help with fixing it if I don't know rust?
What we've seen before (you can have a look through the other reports if you like) is that it's usually a single file that causes the problem and it's often in the btime field (file creation time, only supported on some file systems). If you can find the problematic file and re-create it, the issue should go away.
Unfortunately because the code that causes eza to panic and exit is part of Rust itself, there's nothing we can do about it. We need to wait for someone to update the standard code to at least return an error for invalid timestamps rather than panicking. If you wanted to get into Rust you could help with that (see the latest comments in the Rust bug report) but it won't be simple!
There are no files only directories in my root (except few links, which are probably technically files, pointing to directories)
ls -la --time=birth shows me a list of directories and links and now i discard my previous suspects in favor of a new ones, which have ? in place of birthtime
total 36
drwxr-xr-x 1 root root 198 Dec 5 2022 .
drwxr-xr-x 1 root root 198 Dec 5 2022 ..
drwxr-xr-x 1 nikel nikel 10 Jan 5 16:59 _
lrwxrwxrwx 1 root root 7 Sep 24 07:19 bin -> usr/bin
drwxr-xr-x 1 root root 8 Dec 5 2022 boot
drwxr-xr-x 19 root root 4160 Jan 5 16:28 dev
drwxr-xr-x 1 root root 0 Jan 6 2023 efi
drwxr-xr-x 1 root root 4310 Nov 24 1833 etc
drwxr-xr-x 1 root root 10 Dec 17 2021 home
drwxr-xr-x 19 root root 4096 Jan 6 2023 kaliroot
dr-xr-xr-x 1 root root 0 ? keybase
lrwxrwxrwx 1 root root 7 Sep 24 07:19 lib -> usr/lib
lrwxrwxrwx 1 root root 7 Sep 24 07:19 lib64 -> usr/lib
drwxr-xr-x 1 root root 24 Dec 5 2022 mnt
drwxr-xr-x 1 nikel nikel 94 Jan 2 21:55 nikel_big_downloads
drwxr-xr-x 1 root root 228 Dec 5 2022 opt
dr-xr-xr-x 492 root root 0 ? proc
drwxr-x--- 1 root root 400 Dec 5 2022 root
drwxr-xr-x 33 root root 860 Jan 5 16:28 run
lrwxrwxrwx 1 root root 7 Sep 24 07:19 sbin -> usr/bin
drwxr-xr-x 1 root root 14 Dec 5 2022 srv
dr-xr-xr-x 13 root root 0 ? sys
drwxrwxrwt 22 root root 540 Jan 5 16:28 tmp
drwxr-xr-x 1 root root 80 Dec 5 2022 usr
drwxr-xr-x 1 root root 126 Dec 5 2022 var
Honestly I'm quite afraid to do any manipulations with /sys and /proc directory. I don't want to f**k up my system. So i have to wait then. Maybe it's even kernel bug because WTF those directories have ? as birthtime
I'm facing a similar error that might be related:
Error text:
thread 'main' panicked at /usr/share/cargo/registry/chrono-0.4.31/src/datetime/mod.rs:1418:38:
No such local time
if removing the --color-scale the command works fine:
@iax7 You can track this issue to when they fix it and see if their update fixes your error. Because for me your error looks like something different from mine.
Even when it's fixed in the standard library we'll still have to depend on that through updating requirements to use the Rust version it's released in so it'll be a while before any fix gets to eza.
So there's a fix committed to the stdlib which will fix this once it makes it to stable and we update our MSRV to the version it's released in. From what I can see, there won't be any code changes needed on our end.
Might be a while until we get there thou... Although latest clap requires 1.75 so we should be getting closer soon
Oh, by the way, it works perfectly fine now 🎉🎉🎉 Thanks everybody involved in making it work fine