Bug 239488 - nightly scripts lock pkg database for such a long time that portmaster builds fail
Summary: nightly scripts lock pkg database for such a long time that portmaster builds...
Status: Closed DUPLICATE of bug 232350
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 12.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Kubilay Kocak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-28 06:48 UTC by Martin Birgmeier
Modified: 2019-07-28 11:55 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2019-07-28 06:48:50 UTC
Scenario:
- FreeBSD 12.0-RELEASE-p7 #4 r349733M amd64 (and i386)
- rebuilding many packages using portmaster (due to the recent change from gcc8 to gcc9)
- letting the system run overnight
- machines do not have a direct internet connection and no proxy is configured

Result:
- at about 3:30 a.m., portmaster fails because pkg cannot get a lock on its database

Note:
- This probably happens while downloading vuln.xml and checking against it - maybe the database is already locked while the system is (unsuccessfully) trying to download vuln.xml?
Comment 1 Martin Birgmeier 2019-07-28 07:40:46 UTC
just noted bug #232350
Comment 2 Martin Birgmeier 2019-07-28 07:42:46 UTC
Created a new periodic.conf, hope it will work:

-------------------------------------------------------------------
[0]# cat /etc/periodic.conf 
#
# $MBi$
#

# disable nightly pkg checks if portmaster is running
# https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239488
# https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232350

if /bin/ps -axwww | /usr/bin/grep -q '[p]ortmaster'
then
    security_status_pkgchecksum_enable=NO
    security_status_pkgchecksum_enable=NO
fi
[0]# 
-------------------------------------------------------------------

Are commands allowed in this file?

-- Martin
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-07-28 11:55:23 UTC
Thanks Martin. This is the same issue as bug 232350 so we'll close this as a duplicate.

Your solution in comment 2 is effectively the same (implemented slightly differently) as bug 232350 comment 22

*** This bug has been marked as a duplicate of bug 232350 ***