Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1136018 > unrolled thread

Bug#1030316: trim script always exits 1 despite not failing

Started by"Scott Colby" <debian@scott.scolby.com>
First post2023-02-02 20:30 +0100
Last post2023-02-02 21:00 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.debian.bugs.dist


Contents

  Bug#1030316: trim script always exits 1 despite not failing "Scott Colby" <debian@scott.scolby.com> - 2023-02-02 20:30 +0100
    Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing Petter Reinholdtsen <pere@hungry.com> - 2023-02-02 20:50 +0100
      Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing "Scott Colby" <debian@scott.scolby.com> - 2023-02-02 21:00 +0100

#1136018 — Bug#1030316: trim script always exits 1 despite not failing

From"Scott Colby" <debian@scott.scolby.com>
Date2023-02-02 20:30 +0100
SubjectBug#1030316: trim script always exits 1 despite not failing
Message-ID<FUNrs-2XNO-13@gated-at.bofh.it>
Package: zfsutils-linux
Version: 2.1.7-1~bpo11+1

When I invoke `sh /usr/lib/zfs-linux/trim`, the script always exits
1 despite operating properly. This is causing me some pain when
trying to automate calling this script with a systemd timer, since
I can't differentiate some other reason of the script exiting 1
from a successful run.

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`.

I'm not sure what the right solution to this would be, but I think
that it should be addressed.

Thank you,
Scott Colby

[toc] | [next] | [standalone]


#1136020 — Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing

FromPetter Reinholdtsen <pere@hungry.com>
Date2023-02-02 20:50 +0100
SubjectBug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
Message-ID<FUNKN-2XUr-5@gated-at.bofh.it>
In reply to#1136018
[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

[toc] | [prev] | [next] | [standalone]


#1136024 — Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing

From"Scott Colby" <debian@scott.scolby.com>
Date2023-02-02 21:00 +0100
SubjectBug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
Message-ID<FUNUt-2XXS-5@gated-at.bofh.it>
In reply to#1136020
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.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.bugs.dist


csiph-web