shadow-utils-4.0.3-58.RHEL4 1. touch /var/log/faillog 2. faillog -m 32767 -r The second faillog will check every UID from 0 to the max UID, which is a horrendously large number on 64-bit systems. This makes faillog unusable on 64-bit systems. This means that reset_one() will be called for each and every UID. It might be better to modify it to reset ranges of UIDs.
Created attachment 122866 [details] shadow-faster-faillog.patch This will reset the failures only for existing users (which should be much less than 32-bit of them). Idea from Chris Snook <csnook>
It looks the patch is going to by applied by upstream too.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0276.html
We are still seeing this exact issue using shadow-utils-4.0.3-61.RHEL4
Using faillog with either the -p or -r flags doesn't generate a huge file. The file is probably sparse. It isn't until you use the -m flag that the file explodes to 128G. I think the problem is because every record has an individual fail_max field that the -m flag fills in, exploding the sparse file: struct faillog { short fail_cnt; short fail_max; char fail_line[12]; time_t fail_time; }; Instead, it should have a header record with system-wide defaults. After that, you should be able to fill in user-specific fail_max entries as needed, in a sparse manner.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Why is this bug still open? It was fixed in shadow-utils-4.0.3-61.RHEL4, shipped in 4.5 errata 2007:0276.
# touch /var/log/faillog # time faillog -m 32767 -r real 0m1.262s user 0m0.039s sys 0m0.193s # rpm -q shadow-utils shadow-utils-4.0.3-63.RHEL4.x86_64 # uname -a Linux x86-64-4as-6-m1.lab.boston.redhat.com 2.6.9-67.0.4.ELsmp #1 SMP Fri Jan 18 05:00:00 EST 2008 x86_64 x86_64 x86_64 GNU/Linux I don't know what's the problem here. According to comment #11, it should be OK on the other side too.