Arch Linux

I noticed that problem as well.

I'm experiencing the same issue during updates that trigger the dkms remove hook prior to installing an update.

Also starting seeing this with Virtualbox DKMS module removal when upgrading package 'linux':

==> dkms remove -m vboxhost -v 5.0.22_OSE -k 4.6.2-1-ARCH
/usr/bin/dkms: line 1972: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1974: echo: write error: Broken pipe
/usr/bin/dkms: line 1972: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1974: echo: write error: Broken pipe
/usr/bin/dkms: line 1972: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1974: echo: write error: Broken pipe
/usr/bin/dkms: line 1972: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1916: echo: write error: Broken pipe
/usr/bin/dkms: line 1974: echo: write error: Broken pipe

I assume as its just trying to echo something it is 'harmless' ?

Is this "harmless"? Will it be fixed?

This dkms output was hidden by our alps hook. It has changed since  FS#49816  to let users get feedback from dkms builds.

Only virtualbox-*-dkms seems produce these noisy outputs. I don't know yet if the problem is in dkms or in the virtualbox.

I think I've also gotten it from bbswitch-dkms, but I don't have my system with bbswitch currently on it to check.

I can confirm this with bbswitch-dkms. Note that if you run the same uninstall command from the shell, it works.

Same with broadcom-wl-dkms

The error is harmless. Hooks are run with SIGPIPE ignored which causes '... | grep -q ...' in the dkms script to print the error when the grep exits early and the echo receives EPIPE.

@Andrew Gregory: agreed on the diagnostic. However, that doesn't mean it is OK to have these errors displayed, an error (however harmless) is never expected when all goes well.

Apparently it is not possible (in bash) to trap (or reset) a signal that was ignored when the shell was launched ("Signals ignored upon entry to the shell cannot be trapped or reset."), so there's not much we can do in the dkms hook. It also seems logical that libalpm runs hooks with SIGPIPE ignored, as a hook could close its pipe side while still having work to do.

I see 3 options:
1. As a workaround, do not ignore SIGPIPE in libalpm, and instead install a handler that does nothing. Not beautiful, but with that we can restore the default handler in the dkms hook.
2. Use some kind of (C?) wrapper to launch dkms from the hook, restoring SIGPIPE to default. Quite heavy, I guess.
3. Make dkms handle SIGPIPE being ignored properly. Probably not trivial.

Option 1 sounds like the most doable.

libalpm does not ignore SIGPIPE, GPGME does. I need to look into resetting signal handlers prior to calling the hook. In the meantime, this can be fixed by writing the hook script in something other than bash that is capable of restoring the default handler, like Perl. If rewriting the script is too much, a one line Perl wrapper can be used as well: Exec = /bin/perl -e "$SIG{PIPE}='DEFAULT'; exec('/usr/lib/dkms/alpm-hook', 'remove');"

Could you elaborate on how GPGme is involved here? I don't exactly know how the hooks are invoked so I'm probably missing something here.

Anyway, I wasn't sure how easy it would be to reset the signal handler in Perl, but being that easy I find your oneliner to be quite a reasonable workaround (I don't think rewriting the whole script is reasonable just because of signal handling). I think we should use it until a more proper fix can be made.

libalpm uses GPGME for signature checking. GPGME uses pipes to communicate with external processes. When GPGME is initialized it sets SIGPIPE to be ignored, so that it can gracefully handle EPIPE rather than have the entire application die.

https://bpaste.net/show/3ed72ce276a4

Hey guys I am experiencing the same problems with the "nvidia-dkms" module,

following what Andrew wrote I created "/etc/pacman.d/hooks/70-dkms-remove.hook" (the directory was not existing, so I created it) copied over all the contents from "/usr/share/libalpm/hooks/70-dkms-remove.hook" and adjusted the 'Exec' entry Andrew pointed out.

The error went away. Did I forgot anything? Is this really everything that needs to be changed? I googled and found somehting about "HookDir" in "pacman.conf", but I think it is set by default to the path above? So there is no need to activate it specifically, correct? It may be a stupid question, but i am rather new to Linux, thats why I am asking.

Greets

I pushed a version with the perl workaround proposed by Andrew until he can take time to fix properly in pacman/libalpm.

@Andrew: thanks for the explanation.

@Sébastien: thanks!