Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

main: Ignore SIGPIPE when printing version #3203

Merged
merged 1 commit into from
Feb 27, 2024
Merged

main: Ignore SIGPIPE when printing version #3203

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 6 additions & 0 deletions src/ostree/ot-main.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@
#include <gio/gio.h>

#include <locale.h>
#include <signal.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
Expand Down Expand Up @@ -510,6 +511,11 @@ ostree_option_context_parse (GOptionContext *context, const GOptionEntry *main_e

if (opt_version)
{
/* Ignore SIGPIPE so that piping the output to grep or similar
* doesn't cause the process to fail. */
if (signal (SIGPIPE, SIG_IGN) == SIG_ERR)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually wait though, shouldn't we be setting it to SIG_DFL here so we get killed by SIGPIPE, which the shell is expecting?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, that's exactly what's happening now. The default disposition for SIGPIPE is to kill the process. The process gets killed and the shell sets the exit status to 128 + signum = 141. The pipefail feature says that any process with a non-0 exit status is considered failed. I think it would be better if bash saw the SIGPIPE triggered exit and treated it as a successful exit, but that's not what it does. See https://lists.nongnu.org/archive/html/bug-bash/2017-03/msg00179.html for one of the util-linux maintainers unsuccessfully trying to convince the bash maintainers to do that.

By ignoring the signal, the process won't be killed. Instead, all the writes will fail with EPIPE, which g_print will ignore. That's not so nice since it will keep trying to write data even though there's no reader. However, since the opt_version output is small and controlled, it's no big deal.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, thanks. So basically there's no way to get strict error handling right now for pipes that works reliably.

Yeah. I think the answer here is to not use shell script...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I think the answer here is to not use shell script...

Exactly. For me it's kinda sad because my entry point to software was elaborate shell scripts to do various things. But after being bitten by one too many of these gotchas I've mostly stopped writing them unless they're very simple.

return glnx_throw_errno_prefix (error, "Ignoring SIGPIPE");

/* This should now be YAML, like `docker version`, so it's both nice to read
* possible to parse */
g_auto (GStrv) features = g_strsplit (OSTREE_FEATURES, " ", -1);
Expand Down