Bug 268711
| Summary: | 20 m default for /tmp – tmpmfs="YES" in rc.conf(5) – is too little for things such as ports-mgmt/pkg pkg-update(8) and Electron-based applications | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Graham Perrin <grahamperrin> |
| Component: | conf | Assignee: | Graham Perrin <grahamperrin> |
| Status: | Closed DUPLICATE | ||
| Severity: | Affects Some People | CC: | ceri, cy, dpetrov67, glebius, hrs, mikael, ngie, pkg, rgrimes, se, tagattie, wosch |
| Priority: | --- | Keywords: | crash |
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
| URL: | https://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5&manpath=FreeBSD | ||
| Attachments: | |||
Created attachment 239203 [details] Screenshot: pkg-update(8) not working on FreeBSD 12.4-RELEASE <https://www.freshports.org/devel/electron19/> <https://www.freshports.org/devel/electron21/> CC: maintainers tagattie@ and mikael@ – please see the FreeBSD 14.0-CURRENT screenshot at comment 0: * Chimeracord <https://github.com/RoboChimera/ChimeraCord/> using electron19 * Element (for Matrix) launched from GKrellM with the command below. electron21 https://app.element.io/ & For reference only. Not flagging for feedback from either of you. Both applications do work when I: * use /etc/fstab for tmpfs at /tmp * do _not_ use tmpmfs. ---- pkg@ For pkg update not working with tmpmfs, would you like me to open a corresponding issue at <https://github.com/freebsd/pkg/issues>? I imagine not, because the problem is worked around on three different systems by _not_ using tmpmfs. Attention to rc.d/FILESYSTEMS and rc.d/tmp, in particular: <https://cgit.freebsd.org/src/commit/libexec/rc/rc.d/FILESYSTEMS?id=4f48fd7c5677c6640cac59706d0340348a5f1d64> and <https://cgit.freebsd.org/src/commit/libexec/rc/rc.d/tmp?id=7e4eca7136eaa35e15f67682468f09aa7127b543> (2021-01-15) <https://cgit.freebsd.org/src/commit/libexec/rc/rc.d/tmp?id=24f44a445c4875a329d3947c50083f3e8b9b37db> (2021-01-19) Is it possible that /tmp is mounted too late to meet the direct, or indirect, requirements of things such as pkg update? (This is a wild guess. I'm not a developer.) CC: authors and approvers of D28097 and D28209, both of which were dependency-related. Thanks Created attachment 239204 [details] Screenshot: Chromium: aw, snap! www/chromium: unusable with tmpmfs > Aw, Snap! > > Something went wrong while displaying this webpage. > > Error code: 5 root@fuji:~ # pkg info -x chromium chromium-108.0.5359.124 root@fuji:~ # uname -KU 1301000 1301000 root@fuji:~ # freebsd-version -kru 13.1-RELEASE-p3 13.1-RELEASE-p3 13.1-RELEASE-p5 root@fuji:~ # Created attachment 239207 [details] Screenshot: Chromium: Can't open this page chrome://newtab Second tab > Can't open this page > > … > > Error code: 5 … and so on. All new tabs failed. In most cases, split-second visible appearance of new tab content (e.g. the Google search page) is followed by disappearance with a snap (5) or can't open (5). In other cases, I could not observe any new tab content before the error code appeared. Maybe appearance and disappearance occurred too fast for my eye to see. Sometimes: a click on the 'Reload' button was followed by unexpected closure of the window (all tabs). I don't recall as many closures as are logged below, so I guess that each exit on signal 5 (a crash?) was for a chrome://newtab failure. root@fuji:~ # zgrep chrome /var/log/messages.0.bz2 root@fuji:~ # grep chrome /var/log/messages Jan 2 11:14:17 fuji kernel: pid 1190 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:15:13 fuji kernel: pid 1211 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:15:18 fuji kernel: pid 1213 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:15:27 fuji kernel: pid 1215 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:15:38 fuji kernel: pid 1217 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:15:44 fuji kernel: pid 1174 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:15:51 fuji kernel: pid 1226 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:16:00 fuji kernel: pid 1243 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:17:03 fuji kernel: pid 1247 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:17:11 fuji kernel: pid 1249 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:17:32 fuji kernel: pid 1220 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:17:50 fuji kernel: pid 1272 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:17:56 fuji kernel: pid 1278 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:18:00 fuji kernel: pid 1280 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:18:04 fuji kernel: pid 1283 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:18:07 fuji kernel: pid 1285 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:18:09 fuji kernel: pid 1287 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:18:11 fuji kernel: pid 1291 (chrome), jid 0, uid 1001: exited on signal 5 Jan 2 11:18:13 fuji kernel: pid 1293 (chrome), jid 0, uid 1001: exited on signal 5 root@fuji:~ # ---- Workaround: cease using tmpmfs. What is displayed when entering the following commands? # mount -v | grep "on /tmp" # ls -ald /tmp # mdconfig -lv This is because the default tmpsize is 20MB which is simply too small. Setting tmpsize to 1G corrects the issue. So question is, can we adjust that default without problems? (In reply to Ceri Davies from comment #6) Thanks! I'll remove chromium@ from the CC list here. Also found, from <https://lists.freebsd.org/pipermail/freebsd-current/2019-July/073881.html>: > … As to how we arrived at 20m, I recall an OSF/1 course where the > instructor intimated that 20m was industry best practice at the time > and OSF/1 being BSD. That was a lifetime ago. Maybe it's time to > consider a higher default for 2019. … 2007 bug 80907 comment 4 did consider POLA, albeit not with regard to size. ---- Background: this bug report arose from #helpdesk and #storage discussions in Discord, where advice to use tmpmfs did not (also) include advice to specify tmpsize. The then assumption was that tmpmfs alone should work, subsequent discovery of the 20 m default caused some astonishment. Closing as a duplicate – OK'd with Wolfram (assignee of bug 243523). My bad. It should have been easy for me to find 243523. (Privately, I do know what caused me to not search properly on this occasion … lesson learnt.) *** This bug has been marked as a duplicate of bug 243523 *** |
Created attachment 239200 [details] Screenshot: pkg-update(8) and Electron-based apps not working on FreeBSD 14.0-CURRENT root@fuji:~ # freebsd-version -kru ; uname -aKU 13.1-RELEASE-p3 13.1-RELEASE-p3 13.1-RELEASE-p5 FreeBSD fuji 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC amd64 1301000 1301000 root@fuji:~ # pkg update -f -r FreeBSD Updating FreeBSD repository catalogue... Fetching meta.conf: 100% 163 B 0.2kB/s 00:01 Fetching packagesite.pkg: 100% 6 MiB 3.3MB/s 00:02 pkg: Error extracting the archive: 'Write error' pkg: No signature found Unable to update repository FreeBSD Error updating repositories! root@fuji:~ # sysrc tmpmfs="NO" tmpmfs: YES -> NO root@fuji:~ # nano /etc/fstab