FS#27270 - [shadow] .install file of shadow version 4.1.4.3-3 does not execute successfully

Attached to Project: Arch Linux
Opened by Smith Dhumbumroong (zodmaner) - Sunday, 27 November 2011, 05:58 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 04 December 2011, 03:19 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
After upgrade to shadow version 4.1.4.3-3, during the execution of .install file,
the script keeps looping and outputting the following error message:

[2011-11-27 12:51] /tmp/alpm_bZn4WV/.INSTALL: line 5: echo: write error: Broken pipe

Killing pacman is needed in order to stop the steam of error messages,

Additional info:
* package version(s)
- shadow 4.1.4.3-3

* config and/or log files etc.

Steps to reproduce:
1. Upgrade to shadow version 4.1.4.3-3
2. Noticed the error messages during the execution of .install file
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 04 December 2011, 03:19 GMT
Reason for closing:  Fixed
Additional comments about closing:  testing/shadow-4.1.4.3-5

install file no longer does this fix automatically.
Comment by Smith Dhumbumroong (zodmaner) - Sunday, 27 November 2011, 06:14 GMT
I have solved the issue by modifying the following line in the shadow.install from:
while :; do echo "y"; done | grpck &>/dev/null

To:
while :; do echo "y"; done | /usr/sbin/grpck &>/dev/null

I have attached the modified shadow.install with this comment.
   shadow.install (0.2 KiB)
Comment by Karol Błażewicz (karol) - Sunday, 27 November 2011, 06:47 GMT
http://mailman.archlinux.org/pipermail/arch-dev-public/2011-November/022171.html
Comment by Dave Reisner (falconindy) - Sunday, 27 November 2011, 14:11 GMT
I'd rather you figure out why /usr/sbin isn't part of your PATH.
Comment by Karol Błażewicz (karol) - Sunday, 27 November 2011, 14:13 GMT
/usr/sbin is in my $PATH and I got the same error when I updated.
Comment by Dave Reisner (falconindy) - Sunday, 27 November 2011, 14:15 GMT
Then I fail to see how hardcoding the path is a proper fix.
Comment by Andreas Radke (AndyRTR) - Sunday, 27 November 2011, 14:59 GMT
http://mailman.archlinux.org/pipermail/arch-dev-public/2011-November/022178.html

Should be closed as not a bug.
Comment by Smith Dhumbumroong (zodmaner) - Sunday, 27 November 2011, 14:59 GMT
But it is, at least on my desktop machine. I also have /usr/sbin in my root's $PATH.

For what it's worth, the problematic line executes just fine both as a root and as a regular user on my system.
Comment by Smith Dhumbumroong (zodmaner) - Sunday, 27 November 2011, 15:05 GMT
@Andy: My /etc/group file also have groups that lack the "x".

I have tried your suggestion, but sadly adding "x" to the groups that lacks it doesn't fix the problem.
Comment by Andreas Radke (AndyRTR) - Sunday, 27 November 2011, 15:15 GMT
check with grpck. when all errors were gone I could -S shadow again.
Comment by Smith Dhumbumroong (zodmaner) - Sunday, 27 November 2011, 15:17 GMT
Okay, disregard what I just said. I just noticed that I miss a few groups, and after adding "x" to all of them shadow upgrade successfully. Thanks for the solution, Andy.
Comment by Jan de Groot (JGC) - Tuesday, 29 November 2011, 14:21 GMT
While upgrading my system I also noticed this. I switched to root with "su -" and /usr/sbin is in $PATH. The whole point of the install scriptlet is to fix problems in /etc/group and /etc/gshadow. If this condition is triggered, shadow should not loop until it's aborted, but do its intended job instead. If that is not a bug, then the check should not even be there.

Either pacman cleans up $PATH, or there's something else going on (like bash thinking that grpck is gone when pacman upgraded it). Easiest fix for now is by adding the full path in the install file.
Comment by Dave Reisner (falconindy) - Tuesday, 29 November 2011, 14:24 GMT
But adding the full path isn't the fix... Contrived example:

while :; do echo y; done | this-binary-doesnt-exist

That won't loop forever, it'll just exit with command not found.
Comment by Smith Dhumbumroong (zodmaner) - Tuesday, 29 November 2011, 14:44 GMT
@Dave: But isn't that mean it isn't a path problem? Like Jan said, it might be other issue that caused this.

For what it's worth, I can still confirm that using full path in the install file fix the problem.
Comment by Dave Reisner (falconindy) - Tuesday, 29 November 2011, 15:48 GMT
I'm inclined to remove this magical fixit from the script and just print a warning that the group/gshadow files are inconsistant and that the user should run grpck on their own. I'm not interested in debating what precisely is causing this, and I'm not a fan of magical fixes that lead to breakages.

Loading...