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.

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

"%transfiletriggerin -- /lib/modules" loops through every file 375 times #370

Closed
chenxiaolong opened this issue Dec 13, 2017 · 3 comments
Closed

Comments

@chenxiaolong
Copy link

When setting %transfiletriggerin on /lib/modules, RPM seems to be passing the same list of files to the trigger script over and over. For example, with the following test case:

Name:       test-case
Version:    1.0
Release:    1%{?dist}
Summary:    Test case for transfiletriggerin loop

License:    GPLv3+
URL:        https://github.com/chenxiaolong/fedora-packages

BuildArch:  noarch

%description

%prep

%build

%install

%transfiletriggerin -- /lib/modules
cat >/tmp/files.txt

%files

%changelog

installing the RPM produces a 433MB file list:

[rpm-trans-test-case] ls -l /tmp/files.txt
-rw-r--r--. 1 root root 433904762 Dec 12 21:15 /tmp/files.txt

The number of lines do not match the number of files in /lib/modules.

[rpm-trans-test-case] wc -l /tmp/files.txt
5196138 /tmp/files.txt
[rpm-trans-test-case] sort -u /tmp/files.txt | wc -l
12645
[rpm-trans-test-case] rpm -qla | grep -c ^/lib/modules
12647
[rpm-trans-test-case] find /lib/modules | wc -l
12686

The same thing happens when setting the same trigger for /usr/src/kernels, though the list of files is now 15GB.

[rpm-trans-test-case] ls -lh /tmp/files.txt
-rw-r--r--. 1 root root 15G Dec 12 21:28 /tmp/files.txt

I tested with other non-kernel directories (eg. /usr/bin) and was not able to reproduce this issue. Any ideas what could cause this?

@pmatilai
Copy link
Member

The first thing that comes to mind is that both /lib/modules and /usr/src/kernels involve multiple versions of same package name installed in parallel, which is a fairly unusual situation otherwise, maybe that confuses the file trigger code. Just a guess for now, I'll look into it. Thanks for the report.

pmatilai added a commit that referenced this issue Dec 13, 2017
A prefix can have arbitrary number of matches within a given header,
but each header should be fed into the file list iteration just once.
Otherwise we end up feeding the same file list over and over to the
scriptlet - hundreds of megs or gigs of waste in worser cases.
@pmatilai
Copy link
Member

Fixed in commit e6effe3, and again thanks for reporting and a nice reproducer!

Another file trigger bug that needs an update to 4.13.x and 4.14.x soon...

pmatilai added a commit that referenced this issue Dec 13, 2017
Besides testing the output length sanity, add provisions for testing
scriptlet arguments too. All those zeros are technically wrong, but it
simply reflects what is implemented, there's no attempt at providing
anything else to the file triggers atm.
@chenxiaolong
Copy link
Author

Wow, thank you for the quick fix! A bit of an unusual situation indeed. In my case, I was making something that would trigger when out-of-tree kernel modules or DKMS config files were installed so that they would be automatically signed for UEFI secure boot.

pmatilai added a commit that referenced this issue Jan 16, 2018
A prefix can have arbitrary number of matches within a given header,
but each header should be fed into the file list iteration just once.
Otherwise we end up feeding the same file list over and over to the
scriptlet - hundreds of megs or gigs of waste in worser cases.

(cherry picked from commit e6effe3)
pmatilai added a commit that referenced this issue Jan 16, 2018
Besides testing the output length sanity, add provisions for testing
scriptlet arguments too. All those zeros are technically wrong, but it
simply reflects what is implemented, there's no attempt at providing
anything else to the file triggers atm.

(cherry picked from commit c6170c6)
pmatilai added a commit that referenced this issue Mar 28, 2018
A prefix can have arbitrary number of matches within a given header,
but each header should be fed into the file list iteration just once.
Otherwise we end up feeding the same file list over and over to the
scriptlet - hundreds of megs or gigs of waste in worser cases.

(cherry picked from commit e6effe3)
pmatilai added a commit that referenced this issue Mar 28, 2018
Besides testing the output length sanity, add provisions for testing
scriptlet arguments too. All those zeros are technically wrong, but it
simply reflects what is implemented, there's no attempt at providing
anything else to the file triggers atm.

Backported from commit c6170c6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants