Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
Hello again, On Sat, Apr 1, 2023, at 18:46, наб wrote: > a quick skim reveals > this is because the final pipeline exits 1 because I used a && as an if; Wow, thank you for noticing that! It makes perfect sense, but I hadn't considered that particular difference between && and if. From the The Open Group Base Specifications Shell Command Language chapter: In 2018, https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_03_06 wrote: > The exit status of an AND list shall be the exit status of the last > command that is executed in the list. vs. In 2018, https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_07 wrote: > The exit status of the if command shall be the exit status of the > then or else compound-list that was executed, or zero, if none was executed. Thanks! Scott
Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
Control: tags -1 + patch
Control: retitle -1 zfsutils-linux: trim script exits 1 if last pool not
nvme-only
Got the attached mail today from sd-cron; a quick skim reveals
this is because the final pipeline exits 1 because I used a && as an if;
there's some merit to catching errors from t_i_n_a_t,
so spell it the long way with if instead of || : or explicit exit 0.
With this patch the script exits 0 on the same system
(single HDD-only pool).
Best,
наб
--- Begin Message ---
× cron-zfsutils-linux-root-0.service - [Cron] "24 0 1-7 * * root if [ $(date
+\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/trim ]; then /usr/lib/zfs-linux/trim;
fi"
Loaded: loaded (/etc/cron.d/zfsutils-linux; generated)
Active: failed (Result: exit-code) since Sun 2023-04-02 00:24:39 CEST;
329ms ago
TriggeredBy: ● cron-zfsutils-linux-root-0.timer
Docs: man:systemd-crontab-generator(8)
Process: 21264 ExecStart=/bin/sh
/run/systemd/generator/cron-zfsutils-linux-root-0.sh (code=exited,
status=1/FAILURE)
Main PID: 21264 (code=exited, status=1/FAILURE)
CPU: 55ms
Apr 02 00:24:38 szarotka systemd[1]: Starting
cron-zfsutils-linux-root-0.service - [Cron] "24 0 1-7 * * root if [ $(date
+\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/trim ]; then /usr/lib/zfs-linux/trim;
fi"...
Apr 02 00:24:39 szarotka systemd[1]: cron-zfsutils-linux-root-0.service: Main
process exited, code=exited, status=1/FAILURE
Apr 02 00:24:39 szarotka systemd[1]: cron-zfsutils-linux-root-0.service: Failed
with result 'exit-code'.
Apr 02 00:24:39 szarotka systemd[1]: Failed to start
cron-zfsutils-linux-root-0.service - [Cron] "24 0 1-7 * * root if [ $(date
+\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/trim ]; then /usr/lib/zfs-linux/trim;
fi".
Apr 02 00:24:39 szarotka systemd[1]: cron-zfsutils-linux-root-0.service:
Triggering OnFailure= dependencies.
--- End Message ---
From bbed9d714ec24c551c0d8d7ec4af5a8386caa150 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?=
Date: Sun, 2 Apr 2023 00:34:59 +0200
Subject: [PATCH] /lib/zfs-linux/trim: don't exit 1 if last pool isn't
nvme-only
---
debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
index 341a2fbbd..a807ecc57 100755
--- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
+++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
@@ -60,7 +60,7 @@ do
case "${ret}" in
disable);;
enable) trim_if_not_already_trimming "${pool}" ;;
- -|auto) pool_is_nvme_only "${pool}" && trim_if_not_already_trimming "${pool}" ;;
+ -|auto) if pool_is_nvme_only "${pool}"; then trim_if_not_already_trimming "${pool}"; fi ;;
*) cat > /dev/stderr <
signature.asc
Description: PGP signature
Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
On Thu, Feb 2, 2023, at 14:45, Petter Reinholdtsen wrote: > [Scott Colby] > > I believe this is caused by the final command of the script being > > `zpool list ... | while read -r pool do ...; done`. When the output > > of `zpool list` is exhausted, `read` returns an error, and thus the > > script exits with that status. I have confirmed this by running the > > script with `sh -x` and seeing that the last output line is > > `+ read -r pool`. > > This sound strange. It is not according to my understanding of bourne > shell scripting, and this oneliner describe how I believe it work: > > % ((set -x; echo foo|while read a; do a=$a; done); echo $?) > + echo foo > + read a > + a=foo > + read a > 0 > % You are correct. I was continuing to investigate this and I think the actual case is that the previous call returns 1: + lsblk -dnr -o TRAN /dev/sda + [ sata = nvme ] # <-- this is false + return + read -r pool As can be demonstrated by: $ cat test.sh #!/usr/bin/env sh printf '1\n2\n3\n' | \ while read -r h do echo "aa$h" false done $ sh -x test.sh + + printf 1\n2\n3\n read -r h + echo aa1 aa1 + false + read -r h + echo aa2 aa2 + false + read -r h + echo aa3 aa3 + false + read -r h $ echo $? 1 I still think that this is a bug in the trim script though.
Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
[Scott Colby] > I believe this is caused by the final command of the script being > `zpool list ... | while read -r pool do ...; done`. When the output > of `zpool list` is exhausted, `read` returns an error, and thus the > script exits with that status. I have confirmed this by running the > script with `sh -x` and seeing that the last output line is > `+ read -r pool`. This sound strange. It is not according to my understanding of bourne shell scripting, and this oneliner describe how I believe it work: % ((set -x; echo foo|while read a; do a=$a; done); echo $?) + echo foo + read a + a=foo + read a 0 % -- Happy hacking Petter Reinholdtsen
