0000789: Add set -o pipefail - Austin Group Defect Tracker

Notes
(0001976) eblake (manager) 2013-11-08 16:15	If we standardize this, then we need to also take some time to revisit what shell utilities should do when writing to a pipe when the reader closes early. Is it okay for a utility to exit with status 0 even when encountering a SIGPIPE (or EPIPE write() failure if SIGPIPE is ignored), when the utilities main goal is a filter that writes to stdout? Right now, it's perfectly okay for 'grep $pattern largefile \| head -n1' to have grep exit with non-zero status because the pattern matched enough lines in largefile that it hits a write failure when head exits early; but if you support a pipefail mode, then grep exiting with non-zero status due to writing to a closed pipe would cause seemingly random behavior (a pipeline may succeed normally, but fail when the system is heavily loaded).

(0001977) Don Cragun (manager) 2013-11-08 16:57	I merged the attached file containing the table describing the update to a pipeline's exit status into the Desired Action and removed the attached file.

(0001978) shware_systems (reporter) 2013-11-08 21:05 edited on: 2013-11-12 16:08	Adding set -o implies set +o too... A pipe could be wrapped with set +o pipefail; pipe_and_error_handling; set -o pipefail; easy enough. An application usage blurb that this sort of case needs to be taken into account should be provided, as that is a valid looking concern, but I'm not sure any behavioral changes otherwise are needed. An alternative would be a pipeonce version where this behavior usually off but a set -o pipeonce; pipe; just apples to that pipe. My concern with this would be: with the current way you know the exit status applies to the last process of the pipe. Just setting an option doesn't provide a way for the script to determine which process errored first so appropriate recovery can be attempted, and the error code should reflect that process. A new special variable would be needed, similar to argument count, to handle that. The proposed behavior, of last error is reported, may be a cascade of simply "Unexpected EOF" rather than "Socket connection timed out" that curl might report as first error.

(0001982) weeks (reporter) 2013-11-12 15:42	Aside from using "set +o pipefail" to disable pipefail for an entire pipeline, if it is known beforehand that a command in a pipeline may not read all the output from the previous command, pipefail can be selectively disabled by running the affected command(s) in a subshell that ignores SIGPIPE; e.g.: grep "$pattern" largefile \| (trap '' PIPE; sort) \| head -n 1 This allows the grep & sort exit statuses to still influence the exit status of the entire pipeline, where the sort command may return a non-zero exit status for reasons other than a SIGPIPE.

(0001983) eblake (manager) 2013-11-12 15:51	(trap '' PIPE; sort) isolates you from sort dying from SIGPIPE, but does NOT isolate you from sort exiting with non-zero status due to claiming that an EPIPE failure to write() is fatal. Which brings me back to my argument: if we are going to mandate 'set -o pipefail', we also need to standardize on whether utilities must treat EPIPE as fatal (as implied by the current wording on error handling), or whether it makes sense to mandate that some utilities shall treat EPIPE as non-fatal (namely, any utility that has no side effects other than outputting to stdout, where EPIPE is a sign that the reader on the other end no longer cares about that output).

(0002067) weeks (reporter) 2013-12-11 22:40	Eric: understood; I had completely missed that point in your first response. It may be okay for certain standard utilities to exit with status 0 upon write() failing due to EPIPE, though in that case I don't think it would be okay for such utilities to ignore SIGPIPE by default; this gives the script writer control over whether or not writing to a closed pipe constitutes an error (e.g., using the previously-mentioned workaround if a SIGPIPE is expected). Even without such a mandate, forcing the "sort" stage in the previous example pipeline to exit with status 0, e.g.: grep "$pattern" largefile \| (sort; true) \| head -n 1 is still an improvement over not having the pipefail option at all---at least "grep" can fail and cause the exit status of the pipeline to be nonzero.

(0002107) shware_systems (reporter) 2014-01-16 23:15	Per phone call 2014-Jan-09, text from Etherpad reflecting discussion points: Knowing a pipeline failed is not as useful without an array variable of which process(es) in the pipeline failed - both ksh and bash have pipefail, but they also have an array variable extension that gives this extra information Proposed is an index variable that relates failure code reported to process position in pipe, absent a standardized array capability. Maybe something like 'fail() { return $1; }; fail 2 \| : \| fail 3' producing "2 0 3" in the new variable. Maybe named POSIX_PIPE_STATUS Generically, value uses space separated string of the return codes for each member of the pipe in decimal notation. Not discussed, would a new pipe invocation clear prior value, or is it the scripts responsibility to clear it? Presuming the first, a caveat that a script has to copy the value if error recovery also uses a pipe may be desirable, rather than reference it directly. A method to check for parent relations may be: call cat /etc/termcap \| cat \| ps -f and then check for PPID in the ps output Action: Andrew: Ask shell maintainers: Would it be appropriate to add set -o pipefail and set +o pipefail without also adding the arrays that provide the exit status of all processes in the pipeline (or some non-array equivalent; see above)? Standardizing arrays first may be the higher priority, as arrays offer a lot more benefits than just pipeline status

(0002253) weeks (reporter) 2014-05-28 15:47	mksh, bash, and zsh implement PIPESTATUS (pipestatus, for zsh) arrays containing the exit statuses of the previous foreground pipeline; however, busybox ash lacks arrays, and ksh does not have an equivalent array of exit statuses. It would be expedient to first standardize common practice that's portable between the existing implementations ("set -o pipefail" only), then possibly mandate an array of exit statuses if/when arrays are standardized.

(0002685) stephane (reporter) 2015-05-29 21:14	I find "last" in the proposed text ambiguous as there's a possible confusion between "last" meaning "rightmost" or "last to exit". In: set -o pipefail (sleep 3; exit 3) \| (sleep 1; exit 2) \| true $? should be 2 (the rightmost command that exited with a non-zero status), not 3 (the last command to exit with a non-zero exit status after 3 seconds).

(0002689) stephane (reporter) 2015-05-31 18:27 edited on: 2015-05-31 19:27	IMO, changing utilities so that they return success upon SIGPIPE is out of the question. Think for instance of scripts that should be able to exit early when the command they run dies of a SIGPIPE when stdout is a broken pipe. #! /bin/sh - utility1 \|\| exit echo foo utility3 \|\| exit echo bar ... We could make the pipefail implementation ignore the status of commands that die of SIGPIPE, but then again, deciding what constitutes a SIGPIPE death is not always clear and the decision would be better left to the application. For instance, in: (cmd1; exit) \| script2 \| cmd3 The first subshell would typically terminate normally with exit code 141 (128+SIGPIPE) if the pipe became broken. Could be the same for script2, though an exit code of 141 could also be caused by an unrelated pipe. Also, option handling is not really compatible with the function features. Options are better avoided where possible. For instance in: set -o pipefail cmd1 \| cmd2 \| cmd3 set +o pipefail If any of those cmd1/2/3 is a function, setting that option could unexpectedly change the behaviour of that function. This kind of issue crops up all the time for other options. For instance, the bash completion system (based on functions) fails when you change some of the default options. Some shells like zsh can alleviate the problem by resetting the options to their default in a local scope, but even then that's cumbersome and not ideal (and there's nothing like that in POSIX sh yet). Instead I'm suggesting introducing a new builtin to check the pipeline failure which could also address some of the other deficiencies with termination status query in shells. Something like: status [-acsfl] [-i <signame>[+]] [-I <signame>[+]]... status -p [-acs] Without argument, status returns true if the previous command succeeds and the same exit status otherwise (mainly a no-op unless ! was used which is ignored). With: - -f -l (implies -a (for all/any)): returns true unless any of the commands in the pipeline did not return true. In which case the status of the first (leftmost) for -f or last (rightmost) for -l is returned instead (if -a is given without -l/-f, -l is implied). - -c: returns true if any (with -a) or the last command (without -a) in the last pipeline exited with a coredump. - -s: returns true unless any (with -a) or the last command (without -a) in the last pipeline exited with a signal. Otherwise returns the $? corresponding to the signal of that command (the first with -f, the last with -l) - -i: when reporting the status, ignore commands that die of a signame signal. If expressed as signame+, also ignore commands that returned with a status corresponding to that signame (-i pipe ignores commands that died of a SIGKILL, -i pipe+ also ignores commands that died of exit(141) (on systems where shells use that code to report a death by SIGPIPE). - -I: same as above but only ignores the signal in all but the last pipeline element. With -p, print status information instead. With -p alone, equivalent to echo "$?" unless ! was used for the last pipeline. With: -a: print the status of all elements of the pipeline, one per line (from the leftmost pipeline element to the rightmost) -s: for those commands that died of a signal, print the signal name (pipe/int/kill...) instead of number computed like $? -c: for those processes that generated a core, append +core. Examples: system("cmd1 \| cmd2; status -a") would also check the exit status of cmd1. Similar to: system("set -o pipefail; cmd1 \| cmd2") without side-effects if cmd1 or cmd2 is a function. system("cmd1 \| cmd2; status -aI pipe") same but ignores SIGPIPE death of cmd1 system("cmd1 \| cmd2; status -aI pipe+") same but also ignores a reported SIGPIPE death. system("cmd1 \| cmd2; status -ai xcpu+ -i alrm+ -I pipe+") ignore xcpu/alrm deaths only report real errors. cmd1 \| cmd2 \| cmd3 status -pasc would print: pipe segv+core 0 if cmd2 died of a SIGSEGV and dumped a core and as a result cmd1 died of a SIGPIPE. While cmd3 did an exit(0). A note about "!": set -o pipefail ! cmd1 \| cmd2 would be written: cmd1 \| cmd2; ! status -a ! cmd2 \| cmd2; ! status -a has the same effect, except in case of "set -e" and cmd2 fails. What do you think?

(0003904) jilles (reporter) 2017-12-27 22:54	Given the complication of checking all statuses without a feature like this and the ease with which the shell has all statuses available, I think something like this would be useful. With the set -o pipefail as implemented in some shells, the application can handle SIGPIPE normally using something like ( cmd1 r=$? if [ "$r" -gt 128 ] && [ "$(kill -l "$r")" = PIPE ]; then exit 0 else exit "$r" fi ) \| cmd2 Likewise, the dynamic scoping of options can be worked around: set -o pipefail (set +o pipefail; cmd1) \| (set +o pipefail; cmd2) r=$? set +o pipefail The status builtin utility proposal above may be a step in the right direction. The shell language being what it is, it will probably end up as something as ad hoc as getopts. The status builtin reading ephemeral state seems rather error-prone and inflexible. It may be better to set a variable as a side effect of executing a pipeline (like the PIPESTATUS array in some shells) and use the new builtin to interpret it, explicitly passing the value.

(0003905) stephane (reporter) 2017-12-28 09:43 edited on: 2017-12-29 12:58	Note that the comp.unix.shell FAQ had an entry for that. It is possible with the current POSIX sh specification to define a helper for that: https://unix.stackexchange.com/questions/76162/how-do-i-capture-the-return-status-and-use-tee-at-the-same-time-in-korn-shell/76171#76171 [^]

(0004102) kre (reporter) 2018-09-04 20:36	What has not been considered here is the operation of pipefail in an asynchronous pipeline. In particular, at what instant is the setting of the pipefail option tested. I see three possibilities (which all amount to the same thing for foreground pipelines, so it does not matter there) 1) the pipefail option setting when the pipeline is created (and/or perhaps the setting for each command in the pipeline when it is started). This allows set -o pipefail my \| pipe \| line & P=$! set +o pipefail # and then later wait $P # and here $? is set to the status of the pipeline, using the pipefail option, even though it is not enabled when the wait is done. 2) the status when the script waits for the status of the pipeline (when the status is made available to the script). This allows my \| pipe \| line & P=$! # and later set -o pipefail; wait $P; X=$?; set +o pipefail and X is the status from the pipeline, with the pipefail option set (regardless of its value when the pipeline was created, or at any intervening time). 3) The status of the pipefail option is tested as the shell detects that each process of the pipeline is done (has exited), so in set +o pipefail (sleep 1; exit 1) \| (sleep 5; exit 5) \| (sleep 9; exit 0) & P=$? sleep 3 sleep 3 set -o pipefail set -o pipefail sleep 4 set +o pipefail sleep 4 set -o pipefail wait $P wait $P $? == 0 $? == 5 In the sequence in the left column, pipefail is not set when the last process exits, so the status of the pipeline is the status of the rightmost process (0). In the right column, pipefail is enabled then and so the status of the pipeline is the status of the rightmost process with non-zero status to exit while the pipefail option was set, so 5 in this case (the middle of the 3 processes). If that process had done exit 0 instead of exit 5, the status of the pipeline would be 0, as the pipefail option was not set when the first process exited, hence its status is irrelevant. This 3rd option is, of course, essentially unusable, but is the easiest to implement - it allows the shell to immediately decide what to do with the exit status of each command in the pipeline as it exits, it does not need to retain all the status info until the whole pipeline is finished, which it would need to do with the 2nd option. The first option is the most useful I believe, but I also suspect not implemented anywhere - it allows the shell to collect the status as exch process in the pipeline exits, and also provides predictable behaviour to the application. Pity that no-one (that I know of) implements that. I added pipefail to the NetBSD sh (ash derivative) a while ago, it is in the NetBSD 8 release shell - that implementation uses scheme 2 above for dealing with async pipelines (because being different, and implementing (1) did not seem useful, when no-one else does, and (3), while simple, is useless.) We have no arrays (and I hope, never will) - there is currently no way to determine which process in the pipeline produced the status that is returned when the pipefail option is set. My impression is that most applications which would want to use it are content to simply discover "they all worked" and are prepared to write the script in a way to avoid inadvertent SIGPIPE/EPIPE exit issues (eg: using "sed -e '2,$d'" or "sed -n -e 1p" rather than "head -n1" or "sed -e 1q"). Alternatively the script can insert another process whose purpose is to insulate an earlier process from EPIPE by always reading until EOF, and writing to its stdout, (just like cat with no args) but ignoring any write errors (or at least, ignoring EPIPE and also ignoring SIGPIPE ... and always doing exit 0.) In general I support the pipefail option. I do not think it is required that everything that could possibly be useful as an adjunct be defined at the same time - if making the status of the processes in a pipe available is useful, and arrays are not to be the solution, then something else should be implemented and made available before anyone worries about specifying how to do it. Similarly, we do not need to invent ways to deal with pipes closing - let the applications work on it, and if they need shell assistance, ask for what they actually need. But the operation of the option needs to be fully defined (even if that includes "is unspecified" for some things.)

(0004103) geoffclare (manager) 2018-09-05 12:36 edited on: 2019-10-03 15:17	Here's an updated version of the wording in the desired action that fixes the incorrect use of "preceding" relating to '!' and the 0/non-zero mixup in the second row of the table, and also addresses the question of when the pipefail setting is obtained that was raised in Note: 0004102 ... On 2016 edition page 2369 line 75648 section 2.9.2, change: If the pipeline does not begin with the ! reserved word, the exit status shall be the exit status of the last command specified in the pipeline. Otherwise, the exit status shall be the logical NOT of the exit status of the last command. That is, if the last command returns zero, the exit status shall be 1; if the last command returns greater than zero, the exit status shall be zero. to: The exit status of a pipeline shall depend on whether or not the pipefail option (see [xref to set]) is enabled and whether or not the pipeline begins with the ! reserved word, as described in the following table. The pipefail option determines which command in the pipeline the exit status is derived from; the ! reserved word causes the exit status to be the logical NOT of the exit status of that command. The shell shall use the pipefail setting at the time it begins execution of the pipeline, not the setting at the time it sets the exit status of the pipeline. (For example, in <tt>command1 \| set -o pipefail</tt> the exit status of <tt>command1</tt> has no effect on the exit status of the pipeline, even if the shell executes<tt>set -o pipefail</tt> in the current shell environment.) pipefail Enabled Begins with ! Exit Status no no The exit status of the last (rightmost) command specified in the pipeline. no yes Zero, if the last (rightmost) command in the pipeline returned a non-zero exit status; otherwise, 1. yes no Zero, if all commands in the pipeline returned an exit status of 0; otherwise, the exit status of the last (rightmost) command specified in the pipeline that returned a non-zero exit status. yes yes Zero, if any command in the pipeline returned a non-zero exit status; otherwise, 1. On 2016 edition page 2411 line 77180 section set, add after nounset: pipefail Derive the exit status of a pipeline from the exit statuses of all of the commands in the pipeline, not just the last (rightmost) command, as described in [xref to 2.9.2].

(0004115) geoffclare (manager) 2018-09-11 09:42 edited on: 2018-09-11 09:44	Alternative suggestion structured like the NetBSD man page ... On 2016 edition page 2369 line 75648 section 2.9.2, change: If the pipeline does not begin with the ! reserved word, the exit status shall be the exit status of the last command specified in the pipeline. Otherwise, the exit status shall be the logical NOT of the exit status of the last command. That is, if the last command returns zero, the exit status shall be 1; if the last command returns greater than zero, the exit status shall be zero. to: The exit status of a pipeline is determined via the pipe sequence status as follows: If the pipefail option (see [xref to set]) was enabled when the shell began execution of the pipeline, the pipe sequence status shall be the exit status of the last (rightmost) command in the pipeline that exited with non-zero status, or zero if all commands in the pipeline exited with a status of zero. If the pipefail option was not enabled, the pipe sequence status shall be the exit status of the last (rightmost) command in the pipeline (and the exit statuses of any other commands in the pipeline are not used). If the pipeline begins with the ! reserved word, the exit status of the pipeline shall be the logical NOT of the pipe sequence status as determined above. That is, if the pipe sequence status is zero, the exit status shall be 1; if the pipe sequence status is non-zero, the exit status shall be zero. If the pipeline does not begin with the ! reserved word, the exit status of the pipeline shall be the same as the pipe sequence status. Note: Since the shell uses the pipefail setting at the time it begins execution of the pipeline, not the setting at the time it sets the exit status of the pipeline, altering pipefail in a command within the pipeline has no effect on the exit status of the pipeline, even if the shell executes the command in the current shell environment. On 2016 edition page 2411 line 77180 section set, add after nounset: pipefail Derive the exit status of a pipeline from the exit statuses of all of the commands in the pipeline, not just the last command, as described in [xref to 2.9.2].

(0004117) chet_ramey (reporter) 2018-09-11 14:20	I'm curious why the proposed text in note 4103 explicitly chooses kre's option 1 (using the value of pipestatus when the pipeline is started) when, as kre notes in 4102, nobody seems to implement it that way (except ksh93, as Jilles noted later).

(0004118) geoffclare (manager) 2018-09-11 14:46	Re: Note: 0004117, it's because note 4102 is a complete red herring. Asynchronous commands are lists, and if a pipeline is part of a list its exit status needs to be available in the later commands in the list, e.g.: command1 \| command2 \|\| echo failed & To make this work the only two possibilities are that either pipefail is checked as the shell begins execution of the pipeline or it is checked as the shell sets the exit status of the pipeline. An application can't tell the difference unless the shell executes one or more of the pipeline commands in the current shell environment (thus allowing pipefail to be changed in that environment during execution of the pipeline). Since ksh93 does that, it makes sense for the standard to specify the ksh93 behaviour.

(0004119) kre (reporter) 2018-09-11 15:05	Re note 4118... I'd prefer to say that it is because it is the more sensible choice. The application knows when it is starting an async pipeline, it does not necessarily know when one is about to finish in all cases. Wrt the example - anything run asynchronously is run in a subshell by definition, so unless the command list alters pipefail inside itself (as your example in note 4103 did) then the setting of pipefail at the beginning, and the setting at the end are the same. Aside from that obscure usage, the only time the difference really matters is when the option is changed while an async pipeline is running.

(0004120) chet_ramey (reporter) 2018-09-11 15:56	Re: 4118 That's not the only case. The examples in note 4102 are valid as well. In your example, it doesn't really make a difference because, as you say, existing shells that implement the feature will return the same result. In kre's examples, there will be real differences between implementations. We can say that the results are undefined if the option is changed while an asynchronous pipeline is running; that would accommodate existing implementations.

(0004121) geoffclare (manager) 2018-09-11 16:18	Re: Note: 0004120 Okay, I can see that when a pipeline is at the end of an asynchronous list, it would be possible for the time at which "the shell sets the exit status of the pipeline" to be when the wait is done, as per option 2 in note 4102. However, if done that way it means that for an asynchronous execution of a particular pipeline, where all the commands have the same exit status every time it is run (e.g. false \| true), the exit status of the pipeline can differ depending on whether it is obtained as part of the asynchronous list containing the pipeline or is obtained later on with wait. In my view that is just horrible and should not be allowed by the standard.

(0004122) chet_ramey (reporter) 2018-09-11 18:30	Re: 4121 The situation only arises (that is, the two options produce different results) when the value changes during the asynchronous pipeline's execution. A user could naturally expect that change to have an effect. Since a shell that implements your preferred option would return consistent results, and a shell that implements option 2 would return (different) consistent results, it comes down to preference. I think this is a really minor edge case. It's just not the way we usually do things when there are conflicting implementations.

(0004123) geoffclare (manager) 2018-09-12 08:21	Re: Note: 0004122 I don't see it as minor. To me it is a nasty maintenance issue. Suppose I have a script that does: set -o pipefail command1 \| command2 \|\| command3 & pid=$! set +o pipefail ... other stuff that needs pipefail disabled ... wait $pid Later on I modify the script and there is new stuff after the wait that needs to know whether the command1 \| command2 pipeline failed, so I change it to: set -o pipefail command1 \| command2 & pid=$! set +o pipefail ... other stuff that needs pipefail disabled ... if wait $pid; then command3 ... new stuff ... fi If the exit status of the command1 \| command2 pipeline now doesn't take into account the exit status of command1, that's a huge gotcha and violates the principle of least surprise.

Issue History
Date Modified	Username	Field	Change
2013-11-08 16:02	weeks	New Issue
2013-11-08 16:02	weeks	Status	New => Under Review
2013-11-08 16:02	weeks	Assigned To	=> ajosey
2013-11-08 16:02	weeks	Name	=> Nathan Weeks
2013-11-08 16:02	weeks	Organization	=> USDA-ARS
2013-11-08 16:02	weeks	Section	=> 2.9.2
2013-11-08 16:02	weeks	Page Number	=> 0
2013-11-08 16:02	weeks	Line Number	=> 0
2013-11-08 16:06	weeks	File Added: pipeline_exit_status.txt
2013-11-08 16:07	weeks	Desired Action Updated
2013-11-08 16:15	eblake	Note Added: 0001976
2013-11-08 16:50	Don Cragun	Interp Status	=> ---
2013-11-08 16:50	Don Cragun	Desired Action Updated
2013-11-08 16:57	Don Cragun	Page Number	0 => 2341
2013-11-08 16:57	Don Cragun	Line Number	0 => 74464-74467
2013-11-08 16:57	Don Cragun	Note Added: 0001977
2013-11-08 16:58	Don Cragun	File Deleted: pipeline_exit_status.txt
2013-11-08 21:05	shware_systems	Note Added: 0001978
2013-11-12 15:42	weeks	Note Added: 0001982
2013-11-12 15:51	eblake	Note Added: 0001983
2013-11-12 16:08	shware_systems	Note Edited: 0001978
2013-12-11 22:40	weeks	Note Added: 0002067
2014-01-16 23:15	shware_systems	Note Added: 0002107
2014-05-28 15:47	weeks	Note Added: 0002253
2015-05-29 21:14	stephane	Note Added: 0002685
2015-05-31 18:27	stephane	Note Added: 0002689
2015-05-31 19:27	stephane	Note Edited: 0002689
2017-12-27 22:54	jilles	Note Added: 0003904
2017-12-28 09:43	stephane	Note Added: 0003905
2017-12-29 12:58	stephane	Note Edited: 0003905
2018-09-04 20:36	kre	Note Added: 0004102
2018-09-05 12:36	geoffclare	Note Added: 0004103
2018-09-06 09:07	geoffclare	Relationship added	related to 0001207
2018-09-11 09:42	geoffclare	Note Added: 0004115
2018-09-11 09:44	geoffclare	Note Edited: 0004115
2018-09-11 14:20	chet_ramey	Note Added: 0004117
2018-09-11 14:46	geoffclare	Note Added: 0004118
2018-09-11 15:05	kre	Note Added: 0004119
2018-09-11 15:56	chet_ramey	Note Added: 0004120
2018-09-11 16:18	geoffclare	Note Added: 0004121
2018-09-11 18:30	chet_ramey	Note Added: 0004122
2018-09-12 08:21	geoffclare	Note Added: 0004123
2019-10-03 15:17	geoffclare	Note Edited: 0004103
2019-10-03 15:21	geoffclare	Final Accepted Text	=> Note: 0004103
2019-10-03 15:21	geoffclare	Status	Under Review => Resolved
2019-10-03 15:21	geoffclare	Resolution	Open => Accepted As Marked
2019-10-03 15:21	geoffclare	Tag Attached: issue8
2020-02-06 10:02	geoffclare	Relationship added	related to 0000267
2020-06-12 09:58	geoffclare	Status	Resolved => Applied
2024-06-11 08:52	agadmin	Status	Applied => Closed

Aardvark Mark IV