[Bug 248527] dump fails if diskspace over 90% of /usr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248527 Bug ID: 248527 Summary: dump fails if diskspace over 90% of /usr Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: linuxh...@freenet.de Hello@ALL 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r357959 if the /usr Diskspace is over 90% on a SSD of 500GB the dump tool crashes with: /usr/src/sbin/dump/traverse.c Error Line.. if Dumps a stored to /usb After remove of 50% date dump goes on running My question is why is there no information at the manpage where dump uses a temp folder to outsource the data for seconds? would it be a good idea to implement a diskspace check if dump starts and i could echo disk over XX% dump cant save? regards + stay healthy -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248536] periodic(8) /absolute/path/where/basename/contains-hyphens interpreted as options to mail(1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248536 Bug ID: 248536 Summary: periodic(8) /absolute/path/where/basename/contains-hyphens interpreted as options to mail(1) Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: danie...@apache.org I ran «periodic /usr/local/etc/periodic/one-off» from /etc/crontab and got the following output: [[[ Subject: Cron periodic /usr/local/etc/periodic/one-off mail: illegal option -- o Usage: mail [-dEiInv] [-s subject] [-c cc-addr] [-b bcc-addr] [-F] to-addr ... [-sendmail-option ...] mail [-dEHiInNv] [-F] -f [name] mail [-dEHiInNv] [-F] [-u user] mail [-d] -e [-f name] ]]] What happens: The function output_pipe() is called with a first argument of «/usr/local/etc/periodic/one-off», which then runs «eval» on the string «output=$one-off_output», which sets the variable $output to the value «-off_output» (because $one expands to nothing), and that variable is then used to build the mail command in $pipe, which works out to «mail -E -s '…' -off_output», which produces the above output. Reproduced in 11.2R, but by source inspection applies to CURRENT too. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246356] pcap(3) SEE ALSO contains invalid references
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246356 p5b2e9...@t-online.de changed: What|Removed |Added Resolution|--- |Feedback Timeout Status|New |Closed --- Comment #1 from p5b2e9...@t-online.de --- Due to lack of feedback I will stop contributing to documentation. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 245820] /etc/src.conf WITHOUT_OPENSSL=yes fails to build custom 12.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245820 p5b2e9...@t-online.de changed: What|Removed |Added Status|New |Closed Resolution|--- |Feedback Timeout --- Comment #1 from p5b2e9...@t-online.de --- I do not care either anymore. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248537] procstat -e/kvm_getenvv() fails for specific processes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248537 Bug ID: 248537 Summary: procstat -e/kvm_getenvv() fails for specific processes Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ag-free...@muc.de While implementing *BSD platform support for sysutils/py-psutils, I've encountered strange behaviour when using either the libprocstat or kvm interface to retrieve the environ for a foreign process on the system: Both kvm_getenvv() and procstat_getenvv() return ENOMEM on some systems. This happens repeatingly reproducable e.g. for the X11 Xorg server process; it can already be seen by using system utilities as well: » pgrep Xorg 1401 » sudo ps -e -p 1401 PID TT STAT TIME COMMAND 1401 v0 S646:37.30 /usr/local/bin/Xorg :0 -listen tcp (shows no environment and swallows the error) » sudo procstat -e 1401 PID COMM ENVIRONMENT procstat: sysctl(kern.proc.env): Cannot allocate memory 1401 Xorg - I've tried to track this down and searched for similar bug reports, but all suggestions mentioned there do not work. 1) Both library functions internally use the sysctl() interface to retrieve the information from the kernel. sysctl() uses _locked memory_ for transferring the data. So, a resource limit may be hit. But even if I raise the locked memory soft and hard limits (``ulimit -l -H ...´´, the error stays. 2) Even if I raise **vm.max_wired** to make sure no global limit is reached, the error stays. There is another scenario which trigges the problem: When using the 'Cirrus CI' continuous build platform (which runs on Google compute engine to my knownledge), there is also a process whose environment cannot be retrieve with the system interfaces kvm_getenvv() / procstat_getenvv(): sysctl vm.max_wired vm.stats.vm.v_wire_count vm.max_wired: 331490 vm.stats.vm.v_wire_count: 136164 limits Resource limits (current): cputime infinity secs filesize infinity kB datasize 33554432 kB stacksize 524288 kB coredumpsize infinity kB memoryuseinfinity kB memorylocked 131072 kB maxprocesses 8499 openfiles 116856 sbsize infinity bytes vmemoryuse infinity kB pseudo-terminals infinity swapuse infinity kB kqueues infinity umtxpinfinity ps auxm USERPID %CPU %MEMVSZRSS TT STAT STARTED TIME COMMAND root 25598 0.0 7.0 990596 291548 u0 S+ 23:580:12.63 ./cirrus-ci-agent -task-id 5900109814693888 -client-token d5950e87a4cc4ce89436b07589944d60 -server-token abae919382e6411787e4d67fc60dd527 -api-endpoint grpc.cirrus-ci.com:443 root 1 0.0 0.0 9788284 - ILs 23:520:00.01 /sbin/init -- root453 0.0 0.0 10456 1460 - Ss 23:520:00.00 /sbin/devd [] root 22 0.0 0.0 12320 1596 u0 Is+ 23:520:00.04 sh /etc/rc autoboot root 25548 0.0 0.0 12320 1848 u0 I+ 23:580:00.00 sh /etc/rc autoboot [] root 0 0.0 0.0 0320 - DLs 23:520:00.00 [kernel] [] procstat -e 22 procstat: sysctl(kern.proc.env): Cannot allocate memory PID COMM ENVIRONMENT 22 sh - -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248537] procstat -e/kvm_getenvv() fails for specific processes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248537 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #1 from Konstantin Belousov --- Some possible reasons for ENOMEM from kern.proc.env are: - env vector corruption, e.g. if application filled env vector with invalid (or NULL) pointers - application made the env vector or env strings set larger that ARG_MAX. >From the kernel PoV, the environment strings exist only at the moment of the execve(2) calls, when strings for args and env are passed through kernel from previous program to the new one. Between execs, it is up to the usermode to maintain env strings in a way it finds most convenient. Sysctl kern.proc.env is a hack to satisfy the popular request assuming the application did not deviated much from the structure passed to the new program on exec. If it did deviate, kernel cannot do much. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248537] procstat -e/kvm_getenvv() fails for specific processes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248537 --- Comment #2 from Armin Gruner --- (In reply to Konstantin Belousov from comment #1) Hi Konstantin, thanks for the quick reply and the explanations so far. Howevery, in the particular cases I've mentioned, I still cannot understand that processes like - the X11 Xorg server - /bin/sh launched for system autoboot like seen in the Cirrus CI box would deviate or corrupt their environment?! -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248537] procstat -e/kvm_getenvv() fails for specific processes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248537 --- Comment #3 from Armin Gruner --- (In reply to Armin Gruner from comment #2) Okay, I think I begin to understand a bit more after thinking about your explanations. Is it that a process after launch did setenv(), **envp had to be reallocated so that an new entry fits in and thus, that is the deviation you meant? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246356] pcap(3) SEE ALSO contains invalid references
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246356 Mateusz Piotrowski <0...@freebsd.org> changed: What|Removed |Added CC||0...@freebsd.org Resolution|Feedback Timeout|Works As Intended --- Comment #2 from Mateusz Piotrowski <0...@freebsd.org> --- Thank you for your problem report. Regarding the lack of feedback, it looks like it's a fairly straight forward issue we're facing here: someone would have to write a patch this manual page. At first I'd say there is little to discuss in this case, but actually there is a reason why those references are here: you see, pcap(3) comes from the contrib part of the src tree, which means there is an active upstream. This means 2 things: 1. Patches should ideally be submitted upstream. 2. A patch for removing those cross references would have to be maintained locally in the FreeBSD tree. This results in more work to be done during future merges of new libpcap versions into the FreeBSD tree. It is actually discouraged (unofficially I guess, but still) to patch little things like this. This is why I am going to close this PR as Works As Intended. I'm sorry if the handling of this PR caused frustration on your side. It's always a good idea to ping mailing lists if your PR seems to be rotting on Bugzilla. Cheers PS Please keep in mind that most of the documentation committers work on FreeBSD in their spare time and sometimes it takes a bit longer than desired to patch the code base. :) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248537] procstat -e/kvm_getenvv() fails for specific processes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248537 --- Comment #4 from Konstantin Belousov --- (In reply to Armin Gruner from comment #3) Yes, this is one of the most common cases. I highly doubt that it is a corruption. Just a state which is made internally by libc due to the app request. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: [PATCH] script(1): enable proper curses playback
Status: In-progress. On 8/8/20, Soumendra Ganguly wrote: > This has been accepted. Thank you. > > On 8/6/20, Soumendra Ganguly wrote: >> Hi, >>I was wondering if anyone is interested in reviewing this patch: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248377 >> >> Thank you. >> Soumendra >> > ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246050] Buffer overflows in fortune's strfile, unstr and randstr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246050 --- Comment #4 from Akos Somfai --- Anyone interested in commiting the patch? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243225] "mpr0: Out of chain frames" boot hang after clang 9.0.1 import (probably timing, not compiler related)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243225 --- Comment #6 from Terry Kennedy --- (In reply to Terry Kennedy from comment #5) Following up to my own post. I just emailed Warner Losh the following (forgetting that the discussion was also going on in this PR): The system is a Dell PowerEdge R730 with dual E5-2643 v3 CPUs, 128GB RAM, PERC H730 Mini RAID controller (for internal SAS drives) and a Dell "12Gb External SAS Adapter" (LSI SAS 3008) which is the problem controller. Since I emailed you last, Dell changed it again (they're getting irritated at this point) with no change. With a r364046 kernel from today, the system boots fine with hyper- threading enabled, but shows thenmprmhang with hyperthreading disabled. The previous kernel worked with hyperthreading disabled - as I've said, this appears to be timing-related as it first showed up after the LLVM 9.0.0 import into 12-STABLE. A verbose boot didn't appear to show anything, but as the kernel mes- sage buffer never gets written to disk because of the hang, I have to play the boot sequence back as a video from the internal remote manage- ment card. Also, sometimes a verbose boot works, since this is a timing- related Heisenbug, apparently. I have created a directory https://www.glaver.org/transient/imp which has (so far) dmesg.boot and pciconf.txt from a good boot, bootcapture_ bad.dvc from a non-hyperthreaded boot hang, bootcapture_good.dvc from a successful hyperthreaded boot. and videoplayer.zip which is the play- er for .dvc files. It contains a Windows .exe and a jar file and shell script for Linux (and presumably FreeBSD with Java and a GUI). I can provide remote access to the Dell iDRAC 8 Enterprise card which allows console viewing and all sorts of other stuff, like reset / power cycle and access to BIOS setup, etc. if needed. Let me know if there is anything else you need. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
