[Bug 275632] process being killed which has a big file mmap'ed and performs writes to it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275632 --- Comment #5 from Martin Birgmeier --- Update: Not only the program itself but also unrelated programs may be killed - here is an excerpt of today's /var/log/messages: Jan 3 09:08:55 hal kernel: pid 4892 (cawic), jid 0, uid 20201, was killed: failed to reclaim memory Jan 3 09:08:57 hal kernel: pid 892 (Xorg), jid 0, uid 0, was killed: failed to reclaim memory Jan 3 09:08:59 hal kernel: pid 644 (named), jid 0, uid 53, was killed: failed to reclaim memory Jan 3 09:09:00 hal kernel: pid 2891 (xterm), jid 0, uid 0, was killed: failed to reclaim memory Jan 3 09:09:01 hal devd[388]: notify_clients: send() failed; dropping unresponsive client Jan 3 09:09:02 hal kernel: pid 4842 (xterm), jid 0, uid 20201, was killed: failed to reclaim memory Jan 3 09:09:18 hal kernel: pid 2917 (xterm), jid 0, uid 80, was killed: failed to reclaim memory The process was running as a regular user, so this can easily be used as a DOS attack. -- Martin -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275632] process being killed which has a big file mmap'ed and performs writes to it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275632 --- Comment #6 from Martin Birgmeier --- Output of "vmstat -c 1000" just before the program gets killed: procsmemorypage disks faults cpu r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs us sy id 1 0 21 229G 357M 22K 0 700 376 66K 69K 603 772 5495 97K 51K 1 42 57 3 0 21 229G 336M 22K 0 703 480 26K 53K 376 441 3907 100K 63K 2 15 84 0 0 21 229G 418M 23K 0 731 32 44K 4.3K 210 219 3011 105K 61K 2 12 85 2 0 21 229G 326M 22K 0 702 52 527 5.6K 5 5 1580 101K 53K 2 7 91 0 0 23 229G 358M 21K 1713 670 572 48K 254K 0 0 1505 96K 51K 3 12 85 1 0 22 229G 453M 20K 4262 648 1609 91K 166K 426 677 4658 90K 45K 2 48 49 0 0 22 229G 369M 22K 1504 718 344 4.9K 33K 292 355 3681 103K 63K 2 11 87 0 0 22 229G 317M 22K 0 702 159 22K 16K 520 610 5071 99K 54K 3 22 75 0 0 23 229G 161M 22K 4419 712 0 17K 74K 432 747 4953 99K 58K 2 34 64 0 0 21 229G 435M 7.9K 1742 248 0 88K 15K 355 444 3443 36K 32K 1 17 82 0 0 21 1.4G 408M6 0 0 1955 65K 63K 692 803 5242 331 14K 0 45 55 0 0 21 1.4G 387M6 0 0 03 2.7K 697 973 5925 293 25K 0 5 95 0 0 21 1.4G 384M6 0 0 19560 2.8K 677 705 4968 283 14K 0 15 85 0 0 21 1.4G 382M4 0 0 00 2.7K 768 1273 7037 269 26K 0 30 70 0 0 21 1.4G 382M6 0 0 19560 2.5K 487 488 3809 302 9.9K 0 11 89 The last five lines are after the kill. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276092] "route add 10/8 ip" adds 0.0.0.0/8, not 10.0.0.0/8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276092 Marek Zarychta changed: What|Removed |Added CC||zarych...@plan-b.pwste.edu. ||pl --- Comment #1 from Marek Zarychta --- That's expected. Please see also bug 258874 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276092] "route add 10/8 ip" adds 0.0.0.0/8, not 10.0.0.0/8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276092 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2588 ||74 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276092] "route add 10/8 ip" adds 0.0.0.0/8, not 10.0.0.0/8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276092 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275632] process being killed which has a big file mmap'ed and performs writes to it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275632 --- Comment #7 from Martin Birgmeier --- Watching the vmstat output, it seems that there is no pageout activity for a long time even while the cawic process has already started rewriting substantial amounts of the mapped file. Maybe the OS is busy paging in, completely "forgetting" about also writing back the changed pages. Or there is no "memory pressure" for pages rewritten of mapped files... -- Martin -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275632] process being killed which has a big file mmap'ed and performs writes to it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275632 --- Comment #8 from Martin Birgmeier --- Another kill with associated vmstat output: 0 0 14 17G 333M 14K 0 434 0 15K 18K 0 0 1373 62K 34K 1 5 94 0 0 14 17G 335M 14K 0 422 0 15K 18K 0 0 1354 61K 33K 1 6 93 0 0 14 17G 336M 13K 0 420 0 18K 19K 362 391 3952 60K 38K 1 11 89 2 0 22 17G 310M 11K 2151 358 439 13K 790K 14 28 1426 51K 29K 1 12 87 3 0 22 17G 456M 14K 3058 436 1450 97K 133K 0 23 1419 62K 35K 1 13 87 3 0 22 17G 398M 14K 0 432 39 445 5.2K 0 6 1400 62K 34K 2 6 93 0 0 22 17G 345M 14K 0 424 0 444 3.5K 1 0 1350 61K 33K 2 6 93 1 0 22 17G 108M 14K 2408 426 82 14K 63K 1397 1677 11128 58K 39K 2 55 43 1 0 21 17G 298M 14K 4834 422 106 65K 33K 231 249 3033 60K 39K 2 9 89 0 0 21 17G 268M 13K 4477 420 1854 67K 171K 154 172 2484 60K 35K 2 20 78 0 0 21 17G 311M 13K 4010 416 0 51K 24K 1469 1765 11330 58K 43K 2 53 45 3 0 22 17G 380M 14K 4779 433 655 51K 77K 6 22 1430 62K 34K 1 9 89 0 0 22 17G 459M 14K 4465 423 469 51K 64K 0 1 1379 61K 34K 1 6 93 0 0 22 17G 406M 14K 4982 424 468 15K 62K 0 0 1386 61K 33K 1 7 92 0 0 22 17G 349M 14K 4991 430 381 12K 55K 158 443 2957 62K 33K 2 28 70 3 0 21 17G 284M 14K 4670 430 256 31K 27K 672 1080 7129 62K 41K 2 38 60 0 0 21 17G 396M 13K 5051 420 650 58K 93K 0 0 1375 60K 34K 2 9 89 0 0 22 17G 344M 14K 4239 422 470 15K 60K 0 5 1380 61K 33K 1 8 91 0 0 21 17G 406M 14K 843 422 240 37K 23K 0 0 1354 61K 34K 1 8 91 1 0 21 17G 319M 14K 0 427 0 11K 3.5K 479 779 5628 61K 38K 2 27 72 procsmemorypage disks faults cpu r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs us sy id 1 0 21 17G 401M 13K 3450 409 649 57K 100K 759 815 6777 59K 41K 1 28 71 0 0 21 17G 337M 14K 0 428 84 446 7.7K 1 0 1367 62K 34K 2 4 94 0 0 22 17G 313M 14K 1796 428 523 24K 80K 0 1 1366 61K 34K 0 7 93 0 0 22 17G 336M 13K 0 416 0 19K 3.5K 0 0 1346 60K 33K 1 5 94 0 0 22 17G 264M 13K 3718 406 1015 32K 110K 402 474 4009 58K 35K 1 29 70 1 0 22 17G 139M 14K 5251 436 0 21K 28K 657 951 6062 62K 49K 1 30 69 1 0 20 1.4G 422M 8.4K 2401 330 1569 132K 65K 215 276 2965 37K 25K 1 18 81 0 0 20 1.4G 351M 326 17 0 0 500 3.3K 1943 2010 14499 544 32K 0 49 51 0 0 19 1.4G 429M 19 0 0 1956 20K 24K 1588 1900 12727 174 30K 0 56 44 0 0 19 1.4G 429M2 0 0 19560 3.6K 1177 1216 8171 269 20K 0 39 61 0 0 19 1.4G 429M2 0 0 00 3.6K 350 584 3307 179 8.3K 0 21 79 0 0 19 1.4G 348M2 0 0 3213 52K 40K 772 1188 6669 162 17K 0 61 39 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275744] Sendmail will not make all restart
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275744 --- Comment #5 from Emanuel Haupt --- (In reply to Russell from comment #4) Thank you Russel. For the record, it's also mentioned in the 20221205 entry in /usr/src/UPDATING. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 209628] freebsd-update upgrade broken in jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209628 Michael Osipov changed: What|Removed |Added CC||micha...@freebsd.org --- Comment #3 from Michael Osipov --- I believe that the workaround is ugly. freebsd-update can detect whether it runs inside a jail and derive the version automatically. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 209628] freebsd-update upgrade broken in jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209628 --- Comment #4 from Michael Osipov --- This could be used, I guess: root@deblndw013x4v1j:~ # sysctl -a | grep jail .. security.jail.jailed: 1 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253989] freebsd-update: workdir should default to ${basedir}/var/db/freebsd-update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253989 --- Comment #1 from Michael Osipov --- Can we close this as dup of Bug 235318? The report is identical. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276093] wc(1) fails to read files on pseudo-filesystems with the -c option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276093 Bug ID: 276093 Summary: wc(1) fails to read files on pseudo-filesystems with the -c option Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rbra...@suse.com To reproduce: ``` $ wc -c /compat/linux/proc/cpuinfo 0 ``` Fix available at https://github.com/freebsd/freebsd-src/pull/985 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276094] freebsd-update: -j/-b have incomplete/unclear semantics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276094 Bug ID: 276094 Summary: freebsd-update: -j/-b have incomplete/unclear semantics Product: Base System Version: 13.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: micha...@freebsd.org manpage says for -j: > -j jailOperate on the given jail specified by jid or name. (The >version of the installed userland is detected and the >--currently-running option is no more required.) So I would assume that all file/dir related operations: -b, -d, -f, -k are rebased on top of the basedir of the jail, but this does not happen. Only -b is set. Issues: * Bug 235318, Bug 253989: host's workdir is shredded * -f is used from the host, resulting in different conf applied, all paths from that conffile need to be rebase on top of basedir * -k since -f is not rebased the wrong key might be used. Expectatation is that all operations runs fully isolated from the host, namely jailed. Even if a jail isn't used -b should describe where and how it is applied... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276094] freebsd-update: -j/-b have incomplete/unclear semantics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276094 --- Comment #1 from Michael Osipov --- This issue is visibible when using Bastille-managed jails: * https://github.com/BastilleBSD/bastille/blob/master/usr/local/share/bastille/upgrade.sh * https://github.com/BastilleBSD/bastille/blob/master/usr/local/share/bastille/update.sh I will create an issue there...for the time being. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 235318] when updating jails using -b, freebsd-update is reusing host's /var/db/freebsd-update without indication of doing so, unless explicit -d as well
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235318 Michael Osipov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2760 ||94 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276094] freebsd-update: -j/-b have incomplete/unclear semantics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276094 Michael Osipov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2353 ||18 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 209628] freebsd-update upgrade broken in jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209628 Michael Osipov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2760 ||94 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276094] freebsd-update: -j/-b have incomplete/unclear semantics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276094 Michael Osipov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2096 ||28 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253989] freebsd-update: workdir should default to ${basedir}/var/db/freebsd-update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253989 Michael Osipov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2760 ||94 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276094] freebsd-update: -j/-b have incomplete/unclear semantics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276094 Michael Osipov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2539 ||89 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276094] freebsd-update: -j/-b have incomplete/unclear semantics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276094 Michael Osipov changed: What|Removed |Added URL||https://github.com/Bastille ||BSD/bastille/issues/658 --- Comment #2 from Michael Osipov --- Reported downstream. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269767] VM IMAGES panic on boot under LXC / LXD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269767 Mina Galić changed: What|Removed |Added Resolution|--- |FIXED Status|Open|Closed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276043] md5(1) et al are broken when reading the last argument because of capsicum(4) code
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276043 --- Comment #9 from Ricardo Branco --- (In reply to Mark Johnston from comment #8) I tested the patch and it works. Please don't close this bug until https://github.com/freebsd/freebsd-src/pull/984#issuecomment-1874667265 is addressed. Cheers, R -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276043] md5(1) et al are broken when reading the last argument because of capsicum(4) code
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276043 --- Comment #10 from Mark Johnston --- (In reply to Ricardo Branco from comment #9) Thanks! Do you plan to work on the md5 issue? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276043] md5(1) et al are broken when reading the last argument because of capsicum(4) code
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276043 --- Comment #11 from Ricardo Branco --- (In reply to Mark Johnston from comment #10) Yes. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276099] freebsd-update: manpage does not mention '-v' option and its aliases
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276099 Bug ID: 276099 Summary: freebsd-update: manpage does not mention '-v' option and its aliases Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: micha...@freebsd.org Note: This issue also applies to all other stable branches. freebsd-update supports verbose output: https://github.com/freebsd/freebsd-src/blob/8b144c015c9cce0bc99a7fbdc43f22f51a946d2c/usr.sbin/freebsd-update/freebsd-update.sh#L527-L538, but the manpage does not mention it at all. In some situations you might want to analyze an issue with verbose output. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 209628] freebsd-update upgrade broken in jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209628 --- Comment #5 from Leif Pedersen --- I guess I don't see the point of examining sysctl or branching differently when in a jail. There's actually no need for `freebsd-update` to be aware of jails at all, nor be aware of the currently running kernel. The whole point of `freebsd-version` is to indicate what is currently installed, be it in a jail or not, which is exactly what `freebsd-update` needs. The command `UNAME_r=$(freebsd-version) freebsd-update` works in all cases I'm aware of. `freebsd-update` just needs to be changed to default to it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 209628] freebsd-update upgrade broken in jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209628 --- Comment #6 from Michael Osipov --- (In reply to Leif Pedersen from comment #5) Agree, no reason to use uname here. freebsd-version everywhere. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276101] Cannot build world for 14-stable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276101 Bug ID: 276101 Summary: Cannot build world for 14-stable Product: Base System Version: 14.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: gja...@narod.ru In an attempt to upgrade from 12-stable amd64 system to 14-stable, I've got new sources via git, just like it is said in the Handbook. But the `make buildworld` command fails with these errors: --- all_subdir_usr.sbin/jail --- /usr/src/usr.sbin/jail/jaillex.l:106:6: error: comparison of integers of different signs: 'int' and 'yy_size_t' (aka 'unsigned long') [-Werror,-Wsign-compare] yyless(atvar); ^ jaillex.c:215:9: note: expanded from macro 'yyless' YY_LESS_LINENO(yyless_macro_arg);\ ^~~~ jaillex.c:204:36: note: expanded from macro 'YY_LESS_LINENO' for ( yyl = n; yyl < yyleng; ++yyl )\ ~~~ ^ ~~ /usr/src/usr.sbin/jail/jaillex.l:146:5: error: comparison of integers of different signs: 'int' and 'yy_size_t' (aka 'unsigned long') [-Werror,-Wsign-compare] yyless(0); ^ jaillex.c:215:9: note: expanded from macro 'yyless' YY_LESS_LINENO(yyless_macro_arg);\ ^~~~ jaillex.c:204:36: note: expanded from macro 'YY_LESS_LINENO' for ( yyl = n; yyl < yyleng; ++yyl )\ ~~~ ^ ~~ jaillex.c:1906:58: error: unused parameter 'yyscanner' [-Werror,-Wunused-parameter] static void yy_fatal_error (yyconst char* msg , yyscan_t yyscanner) ^ jaillex.c:2226:43: error: unused parameter 'yyscanner' [-Werror,-Wunused-parameter] void *yyalloc (yy_size_t size , yyscan_t yyscanner) ^ jaillex.c:2231:58: error: unused parameter 'yyscanner' [-Werror,-Wunused-parameter] void *yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) ^ jaillex.c:2243:36: error: unused parameter 'yyscanner' [-Werror,-Wunused-parameter] void yyfree (void * ptr , yyscan_t yyscanner) ^ 6 errors generated. *** [jaillex.o] Error code 1 make[4]: stopped in /usr/src/usr.sbin/jail --- all_subdir_usr.bin --- --- all_subdir_usr.bin/lex --- --- all_subdir_usr.bin/clang --- --- all_subdir_tests --- --- all_subdir_usr.bin --- --- all_subdir_usr.bin/kyua --- --- all_subdir_lib --- Apart from that I get a bunch of warnings like these, but I suppose it should not stop the world from building: __cxa_thread_call_dtors: dtr 0xc34b10 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0xc35190 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0xc354c0 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0xbc35f0 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0xc35190 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0xc354c0 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0xc34b10 from unloaded dso, skipping --- -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276102] freebsd-update: command gives questionable recommendation which command to run next
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276102 Bug ID: 276102 Summary: freebsd-update: command gives questionable recommendation which command to run next Product: Base System Version: 13.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: micha...@freebsd.org freebsd-update may print something like this: > To install the downloaded upgrades, run "/usr/sbin/freebsd-update install". or > Kernel updates have been installed. Please reboot and run > "/usr/sbin/freebsd-update install" again to finish installing updates. Morespecifically, these: > $ grep -e '\$0' /usr/sbin/freebsd-update | grep -v basename > echo "Run '$0 install' first." > echo "Run '$0 fetch -F' to proceed anyway." > echo "Run '$0 fetch' first." > echo "Re-run '$0 fetch'." > before running "$0 install". > echo "To install the downloaded upgrades, run \"$0 install\"." > echo "Re-run '$0 fetch'." > "$0 install" again to finish installing updates. > installed from the ports tree) and then run "$0 install" > echo "Run '$0 install' to proceed." The problem with these recommendations is that if freebsd-update is started with options (e.g., -b, -f, etc.) the copied and pasted recommendationd lead to incorrect or even broken results. Consider running: > freebsd-update -j deblndw013x4v2j -d $(jls -j deblndw013x4v2j -h path | tail > -1)/var/db/freebsd-update -f $(jls -j deblndw013x4v2j -h path | tail > -1)/etc/freebsd-update.conf -r 13.2-RELEASE upgrade then > freebsd-update install as next command would be wrong. This might be nit-picking, but not straight forward for some people. It should either completely replicate the command input or describe rather in prose rather can providing a copiable command. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276043] md5(1) et al are broken when reading the last argument because of capsicum(4) code
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276043 --- Comment #12 from Ricardo Branco --- Hopefully fixed by https://github.com/freebsd/freebsd-src/pull/988 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 209628] freebsd-update upgrade broken in jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209628 Xin LI changed: What|Removed |Added Assignee|b...@freebsd.org|sect...@freebsd.org CC||delp...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276106] hexdump(1) is not able to skip on files residing on pseudo-filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276106 Bug ID: 276106 Summary: hexdump(1) is not able to skip on files residing on pseudo-filesystems Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rbra...@suse.com To reproduce: `hexdump -s1 /compat/linux/proc/mounts` Fix: https://github.com/freebsd/freebsd-src/pull/989 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276107] tail(1) is not able to operate on files residing in pseudo-filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276107 Bug ID: 276107 Summary: tail(1) is not able to operate on files residing in pseudo-filesystems Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rbra...@suse.com tail(1) is not able to operate on files residing in pseudo-filesystems or others that advertise a zero size. To reproduce: `tail -1 /compat/linux/proc/mounts` dumps the whole file. Fix: https://github.com/freebsd/freebsd-src/pull/990 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276107] tail(1) is not able to operate on files residing in pseudo-filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276107 Mina Galić changed: What|Removed |Added CC||free...@igalic.co Status|New |In Progress URL||https://github.com/freebsd/ ||freebsd-src/pull/990 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276106] hexdump(1) is not able to skip on files residing on pseudo-filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276106 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #1 from Mark Johnston --- It would seem better for pseudofs-based filesystems to correctly report file sizes instead. In particular, pfs_getattr() needs to set vap->va_size, possibly by calling the fill function with a dummy UIO_NOCOPY uio. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276106] hexdump(1) is not able to skip on files residing on pseudo-filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276106 Xin LI changed: What|Removed |Added CC||delp...@freebsd.org --- Comment #2 from Xin LI --- (In reply to Mark Johnston from comment #1) > It would seem better for pseudofs-based filesystems to correctly report file > sizes I think this would require a pn_fill() (when !NULL) for every pfs_getattr() and defeat the purpose of stat() being faster than actually reading the file? Also it would diverge from what Linux does (their /proc would have 0-sized files and the behavior is documented, although I don't have an example of applications expecting this behavior..) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276106] hexdump(1) is not able to skip on files residing on pseudo-filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276106 --- Comment #3 from Mark Johnston --- (In reply to Xin LI from comment #2) Does the performance consideration really matter in practice given that these files are typically quite small. I didn't know that /proc files in Linux have size 0 though, so perhaps my suggestion is a bad idea indeed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253989] freebsd-update: workdir should default to ${basedir}/var/db/freebsd-update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253989 Mark Linimon changed: What|Removed |Added Resolution|--- |DUPLICATE Status|New |Closed --- Comment #2 from Mark Linimon --- *** This bug has been marked as a duplicate of bug 235318 *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 235318] when updating jails using -b, freebsd-update is reusing host's /var/db/freebsd-update without indication of doing so, unless explicit -d as well
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235318 Mark Linimon changed: What|Removed |Added CC||asom...@freebsd.org --- Comment #1 from Mark Linimon --- *** Bug 253989 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276106] hexdump(1) is not able to skip on files residing on pseudo-filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276106 --- Comment #4 from Ricardo Branco --- (In reply to Xin LI from comment #2) The GNU tools expect this behaviour and adapt accordingly. -- You are receiving this mail because: You are the assignee for the bug.
