Hi,
I’m having a strange error with Atuin even when the daemon is enabled (and listening).
The error is:
Error: pool timed out while waiting for an open connection
Location:
atuin/src/command/client.rs:108:18
My config is:
auto_sync = false
dialect = "uk"
enter_accept = false
key_path = "$XDG_RUNTIME_DIR/agenix/atuin_key"
secrets_filter = true
sync_address = "<REDACTED>"
workspaces = true
[daemon]
enabled = true
sync_frequency = "120"
systemd_socket = true
[sync]
records = true
I am using ZFS. Can’t recall if that was fixed in Atuin?
The thing is, the daemon should be listening… so I guess the pool error means the client isn’t configured correctly?
Any ideas?
Thanks.
ellie
July 17, 2024, 5:37pm
2
Could you share your atuin doctor
as well please?
No need!
As it turned out, Nix hadn’t activated the daemon. I believe the hook was falling back to direct write, which ran into ZFS on $HOME.
Thanks for the quick reply!
1 Like
ellie
July 17, 2024, 5:59pm
4
No worries! Glad you got it sorted
ellie
July 17, 2024, 6:03pm
5
And fwiw for anyone finding this via google or something;
The daemon is not a 100% cure-all for any ZFS related issues. It is a workaround that does as much as we can to avoid the issue
The upstream ZFS problem:
opened 02:51PM - 15 Dec 22 UTC
Type: Defect
<!--
Thank you for reporting an issue.
*IMPORTANT* - Please check our issue … tracker before opening a new issue.
Additional valuable information can be found in the OpenZFS documentation
and mailing list archives.
Please fill in as much of the template as possible.
-->
### System information
Type | Version/Name
--- | ---
Distribution Name | Fedora
Distribution Version | 36
Kernel Version | 5.15.82
Architecture |x86_64
OpenZFS Version |2.1.7
<!--
Command to find OpenZFS version:
zfs version
Commands to find kernel version:
uname -r # Linux
freebsd-version -r # FreeBSD
-->
### Describe the problem you're observing
Usually `rpm` commands execute quickly, but pretty often (10% of the cases) there is 4 second extra delay:
```
16:22:55.694445 openat(AT_FDCWD, "/usr/lib/sysimage/rpm/rpmdb.sqlite-shm", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 6 <0.000086>
16:22:55.694563 newfstatat(6, "", {st_dev=makedev(0, 0x1e), st_ino=27231358, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=131072, st_blocks=18, st_size=32768, st_atime=1671114175 /* 2022-12-15T16:22:55.105109260+0200 */, st_atime_nsec=105109260, st_mtime=1671114175 /* 2022-12-15T16:22:55.106109257+0200 */, st_mtime_nsec=106109257, st_ctime=1671114175 /* 2022-12-15T16:22:55.106109257+0200 */, st_ctime_nsec=106109257}, AT_EMPTY_PATH) = 0 <0.000011>
16:22:55.694692 geteuid() = 0 <0.000010>
16:22:55.694759 fchown(6, 0, 0) = 0 <0.000047>
16:22:55.694855 fcntl(6, F_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=128, l_len=1, l_pid=0}) = 0 <0.000010>
16:22:55.694909 fcntl(6, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=128, l_len=1}) = 0 <0.000009>
16:22:55.694953 ftruncate(6, 3) = 0 <4.372489>
```
I have ZFS as root fs running on top of **LUKS2**. NVMe Corsair MP510 (Max Random Write QD32 IOMeter: Up to _440K_ IOPS) with practically zero other IO operations when I run `rpm`.
### Describe how to reproduce the problem
Just try rpm again.
### Include any warning/errors/backtraces from the system logs
<!--
*IMPORTANT* - Please mark logs and text output from terminal commands
or else Github will not display them correctly.
An example is provided below.
Example:
```
this is an example how log text should be marked (wrap it with ```)
```
-->
zpool show no errors and:
```
NAME PROPERTY VALUE SOURCE
tank type filesystem -
tank creation Wed Nov 10 15:40 2021 -
tank used 1.39T -
tank available 296G -
tank referenced 96K -
tank compressratio 1.29x -
tank mounted no -
tank quota none default
tank reservation none default
tank recordsize 128K default
tank mountpoint /tank default
tank sharenfs off default
tank checksum on default
tank compression zstd-3 local
tank atime on default
tank devices on default
tank exec on default
tank setuid on default
tank readonly off default
tank zoned off default
tank snapdir hidden default
tank aclmode discard default
tank aclinherit restricted default
tank createtxg 1 -
tank canmount off local
tank xattr sa local
tank copies 1 default
tank version 5 -
tank utf8only on -
tank normalization formD -
tank casesensitivity sensitive -
tank vscan off default
tank nbmand off default
tank sharesmb off default
tank refquota none default
tank refreservation none default
tank guid 8575689710526589949 -
tank primarycache all default
tank secondarycache all default
tank usedbysnapshots 0B -
tank usedbydataset 96K -
tank usedbychildren 1.39T -
tank usedbyrefreservation 0B -
tank logbias latency default
tank objsetid 54 -
tank dedup off default
tank mlslabel none default
tank sync standard default
tank dnodesize auto local
tank refcompressratio 1.00x -
tank written 0 -
tank logicalused 1.77T -
tank logicalreferenced 42K -
tank volmode default default
tank filesystem_limit none default
tank snapshot_limit none default
tank filesystem_count none default
tank snapshot_count none default
tank snapdev hidden default
tank acltype posix local
tank context none default
tank fscontext none default
tank defcontext none default
tank rootcontext none default
tank relatime on local
tank redundant_metadata all default
tank overlay on default
tank encryption off default
tank keylocation none default
tank keyformat none default
tank pbkdf2iters 0 default
tank special_small_blocks 0 default
```
It is possible that it could happen still, though it would show up in the daemon logs and not in your shell
1 Like
Good shout. For those interested in my setup, I created a ZFS zvol for Atuin, on a EXT4 filesystem to mitigate this issue. That way I can be certain my Atuin is syncing fine, and not running into any delays.
My Nix declaration for that mount is here: nixfigs/hosts/nixos/MORPHEUS-LINUX/disks.nix at main · shymega/nixfigs · GitHub