Move the Handbook into source tree
Dear All , in many of my messages to FreeBSD mailing lists I am mentioning the following view : "Please move the Handbook into source tree , and Maintain it with respect to current release without mixing sliding releases : If you do this , maintenance of a correct Handbook is IMPOSSIBLE because maintenance of associated IF statements about releases . " When we look at the following web pages , we see the following : https://www.freebsd.org/cgi/man.cgi FreeBSD Manual Pages In the second box of "All sections" line , there are lines about all of the FreeBSD releases with many more other systems . In spite of this , in the following page : https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook The FreeBSD Documentation Project " Abstract Welcome to FreeBSD! This handbook covers the installation and day to day use of FreeBSD 13.0-RELEASE, FreeBSD 12.2-RELEASE and FreeBSD 11.4-RELEASE. ... " A Handbook which ( for me , exactly , for the others , perhaps ) with many errors ... I think that , it is NOT extraordinarily a difficult process to move the Handbook into source tree and maintaining it with respect to per release and insert into the above web page a part similar to the manual pages to display the requested Handbook with respect to releases . In the present case , previous handbooks are lost , because of the difficulty of finding them . Thank you very much and my best wishes for you and humanity in these pandemic days ... Mehmet Erol Sanliturk
Re: BUG in libm's powf
> On 6 Sep 2021, at 21:22, Gordon Bergling wrote:
>
> could you turn to test program into an AFT test to prevent further
> regressions?
Certainly!
M
>
> —Gordon
>
>> Am 06.09.2021 um 20:04 schrieb Steve Kargl
>> :
>>
>> No, thank you for the quick response.
>>
>> Of course, a one character diff might be easier to review. :-)
>>
>> --
>> steve
>>
>> On Mon, Sep 06, 2021 at 06:55:07PM +0100, Mark Murray wrote:
>>> Thanks!
>>>
>>> And it's committed!
>>>
>>> M
>>>
On 6 Sep 2021, at 18:53, Steve Kargl
wrote:
Fine with me. I don't have a phabricator account and
bugzilla reports seems to get lost in the ether.
--
steve
On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> Hi
>
> I've opened a Phab ticket for this. I hope that's OK?
>
> https://reviews.freebsd.org/D31865
>
> M
>
>> On 6 Sep 2021, at 16:28, Steve Kargl
>> wrote:
>>
>> Paul Zimmermann has identified a bug in Openlibm's powf(),
>> which is identical to FreeBSD's libm. Both derived from
>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>>
>> Consider
>>
>> % cat h.c
>> #include
>> #include
>> int
>> main(void)
>> {
>> float x, y, z;
>> x = 0x1.ecp-1F;
>> y = -0x1.02p+27F;
>> z = 0x1.557a86p115F;
>> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
>> return 0;
>> }
>>
>> % cc -o h -fno-builtin h.c -lm && ./h
>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>>
>> Note, clang seems to have a builtin for powf(), but one cannot
>> count of clang being the only consumer of libm. With the patch
>> at the end of this email, I get
>>
>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath &&
>> ./h
>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>>
>> Watch for copy and paste whitespace corruption.
>>
>> --- /usr/src/lib/msun/src/e_powf.c 2021-02-21 03:29:00.956878000
>> -0800
>> +++ src/e_powf.c 2021-09-06 08:17:09.88000 -0700
>> @@ -136,7 +136,7 @@
>> /* |y| is huge */
>> if(iy>0x4d00) { /* if |y| > 2**27 */
>> /* over/underflow if x is not close to one */
>> -if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>> +if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
>> /* now |1-x| is tiny <= 2**-20, suffice to compute
>> log(x) by x-x^2/2+x^3/3-x^4/4 */
>>
>>
>> --
>> Steve
>>
>
> --
> Mark R V Murray
>
--
Steve
>>>
>>> --
>>> Mark R V Murray
>>>
>>
>>
>>
>> --
>> Steve
>>
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0
On 9/6/21 8:21 PM, Cy Schubert wrote:
In message <2780735.ssxfcku...@sigill.theweb.org.ua>, "Oleg V. Nauman"
writes:
On 2021 M09 6, Mon 20:31:33 EEST Cy Schubert wrote:
One last favour to ask, can you try this with the wpa_supplicant-devel
port, please? I'm trying to narrow down if this is related to the options
in usr.sbin/wpa/Makefile.inc or an upstream problem. If this behaves the
same using wpa_supplicant-devel, this tells me to look at the code instead
of Makefiles.
I can reproduce the service netif restart problem using the old
wpa_supplicant 2.9, so at least here there is no change in behaviour.
Though on my sandbox machine the ifconfig dow/up is not required -- though
even the older wpa_supplicant 2.9 behaves the same on my laptop, (no
regression experienced here).
To help point to either Makefile.inc or contrib/wpa, can you please try the
wpa_supplicant-devel port. This will tell me where to look next.
I can confirm that wpa_supplicant from security/wpa_supplicant-devel port
demonstrating the same behavior as wpa_supplicant from base - "ifconfig wlan0
down ; sleep 5 ; ifconfig wlan0 up" mitigate wlan association issue.
Thank you.
This is an issue that I'll need to chase down with our upstream. In the
mean time while work on this/bring it to upstream's attention this should
circumvent the issue:
diff --git a/libexec/rc/rc.d/wpa_supplicant b/libexec/rc/rc.d/wpa_supplicant
index 8a86fec90e4d..cfe5f1ab27c6 100755
--- a/libexec/rc/rc.d/wpa_supplicant
+++ b/libexec/rc/rc.d/wpa_supplicant
@@ -12,6 +12,7 @@
name="wpa_supplicant"
desc="WPA/802.11i Supplicant for wireless network devices"
+start_postcmd="wpa_poststart"
rcvar=
ifn="$2"
@@ -27,6 +28,12 @@ is_ndis_interface()
esac
}
+wpa_poststart() {
+ ifconfig ${ifn} down
+ sleep 3
+ ifconfig ${ifn} up
+}
+
if is_wired_interface ${ifn} ; then
driver="wired"
elif is_ndis_interface ${ifn} ; then
I'll have more questions later (need to start working on another job) but
I'd like to learn more about your configuration to understand why it works
at boot for myself and phlip@ and not for you and the others here on
-current who have experienced the same issue. Understanding what triggers
this will go a long way to resolving it.
(cc'd philip@)
BTW, my laptop is configured so that wlan0 (iwn0) and bge0 are members of
lagg0. Whereas on my sandbox wlan0 (ath0) is used directly.
Hi, I have the same.
wlan0 does not associate after boot. (This is with iwm, AC 9260)
My workaround is simply 'ifconfig wlan0 up'.
After a few seconds wpa_supplicant associates and another few secods
later I have a DHCP IP address.
Jakob
Re: Move the Handbook into source tree
Hi, I think there are two conflated things here: - Moving the handbook into the source tree. - Creating branches in the handbook that track particular releases. The first one is largely irrelevant to anyone other than people contributing to the handbook, so I'll focus on the second: This is quite an easy way of having a per-release snapshot but it means that the handbook will diverge for different releases over time. If the new docs are documenting things that are new, that's fine, but if new docs are added to -CURRENT for things in a release, then they will need to follow the same MFC process as code flowing from current to releases, which brings up the potential of merge conflicts and so on. This is made even more complex in cases where code is MFC'd. Typically (unfortunately) docs are added to the handbook after a feature is committed and so things will need to be MFC'd at the same time as other features are MFC'd or later if they're written after the original MFC. I see two possible workflows, the current and the proposed one, both of which have disadvantages: - With the current workflow, you need to explicitly track which release things apply to in the document. - With your proposed workflow, you need to explicitly track which release things apply to by merging them at the correct time. It's not clear to me that either of these is necessarily easier than the other. David On 07/09/2021 08:01, Mehmet Erol Sanliturk wrote: Dear All , in many of my messages to FreeBSD mailing lists I am mentioning the following view : "Please move the Handbook into source tree , and Maintain it with respect to current release without mixing sliding releases : If you do this , maintenance of a correct Handbook is IMPOSSIBLE because maintenance of associated IF statements about releases . " When we look at the following web pages , we see the following : https://www.freebsd.org/cgi/man.cgi FreeBSD Manual Pages In the second box of "All sections" line , there are lines about all of the FreeBSD releases with many more other systems . In spite of this , in the following page : https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook The FreeBSD Documentation Project " Abstract Welcome to FreeBSD! This handbook covers the installation and day to day use of FreeBSD 13.0-RELEASE, FreeBSD 12.2-RELEASE and FreeBSD 11.4-RELEASE. ... " A Handbook which ( for me , exactly , for the others , perhaps ) with many errors ... I think that , it is NOT extraordinarily a difficult process to move the Handbook into source tree and maintaining it with respect to per release and insert into the above web page a part similar to the manual pages to display the requested Handbook with respect to releases . In the present case , previous handbooks are lost , because of the difficulty of finding them . Thank you very much and my best wishes for you and humanity in these pandemic days ... Mehmet Erol Sanliturk
Re: Install to ZFS root is using device names hence failing when device tree is changed.
On 9/7/21 10:29 AM, Peter Jeremy wrote: On 2021-Sep-06 17:45:31 +0200, Karel Gardas wrote: just installed 14-current snapshot from 2.9. on uefi amd64 machine. Installed from USB memstick which was detected as da0 into the ssd hanging on usb3 in external enclosure which was detected as da1. ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as /boot/efi and probably also something as root zpool. Anyway, expected thing happen. When I pulled out USB stick identified as da0 on reboot, the drive on USB3 switch from da1 to da0 and result is unbootable system with complains about various /dev/da1xx drives missing for swap efi boot etc. Can you give more details about exactly what the errors and when they occur during the boot cycle. In particular: * Low-level boot (anything prior to the FreeBSD kernel) knows nothing about da0 or da1, so any problems there are associated with your BIOS config, not FreeBSD. Low level boot is all right since kernel is booting. What's broken is root/zfs mount and swap enablement. * The swap partition will, by default, appear as a hard-wired device name in /etc/fstab - that will definitely need updating. This will prevent the "swapon" working but won't prevent the boot. ACK. Good to know. * ZFS doesn't care about device names - it looks for ZFS labels on all possible devices. I think you are wrong here. Let's see zpool status: karel@freebsd:~ $ zpool status pool: zroot state: ONLINE config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 da1p4 ONLINE 0 0 0 errors: No known data errors Now, let's reboot and see error on serial console when install da0 is not attached: Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.5: at usbus0 umass0 numa-domain 0 on uhub1 umass0: addr 4> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:9:0: Attached to scbus9 da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 201701C7 da0: 400.000MB/s transfers da0: 238475MB (488397168 512 byte sectors) da0: quirks=0x2 Dual Console: Serial Primary, Video Secondary No suitable dump device was found. Setting hostuuid: 8cdf33eb-6866-42ae-a49d-ae7ee4c0c33c. Setting hostid: 0xdf6467d8. no pools available to import swapon: /dev/da1p3: No such file or directory Starting file system checks: Can't open `/dev/da1p1' /dev/da1p1: UNEXPECTED INCONSISTENCY; RUN fsck_msdosfs MANUALLY. THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: msdosfs: /dev/da1p1 (/boot/efi) Automatic file system check failed; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! 2021-09-07T11:23:23.710549+02:00 - init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: So this is problematic /efi parition, if I remove it from the /etc/fstab I get this boot: Wow! It boots well, so you were indeed right. Checking zpool status reveals: karel@freebsd:~ $ zpool status pool: zroot state: ONLINE config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p4 ONLINE 0 0 0 errors: No known data errors karel@freebsd:~ $ so indeed, ZFS on FreeBSD is similar to this on Solaris. On Linux I got different experience (e.g. /dev/sdaX hardwired and failing to boot) hence I've been in impression that this is also a case of FreeBSD when code is shared thorough OpenZFS project. Great to know and thanks for kicking me into it. So just /efi partition mount is the culprit here... Thanks! Karel
Re: Move the Handbook into source tree
On Tue, Sep 7, 2021 at 12:17 PM David Chisnall wrote: > Hi, > > I think there are two conflated things here: > > - Moving the handbook into the source tree. > - Creating branches in the handbook that track particular releases. > > The first one is largely irrelevant to anyone other than people > contributing to the handbook, so I'll focus on the second: > > This is quite an easy way of having a per-release snapshot but it means > that the handbook will diverge for different releases over time. If the > new docs are documenting things that are new, that's fine, but if new > docs are added to -CURRENT for things in a release, then they will need > to follow the same MFC process as code flowing from current to releases, > which brings up the potential of merge conflicts and so on. > > This is made even more complex in cases where code is MFC'd. Typically > (unfortunately) docs are added to the handbook after a feature is > committed and so things will need to be MFC'd at the same time as other > features are MFC'd or later if they're written after the original MFC. > > I see two possible workflows, the current and the proposed one, both of > which have disadvantages: > > - With the current workflow, you need to explicitly track which > release things apply to in the document. > - With your proposed workflow, you need to explicitly track which > release things apply to by merging them at the correct time. > > It's not clear to me that either of these is necessarily easier than the > other. > > David > > My primary training is "Mathematics ( Option : Statistics and Operations Research ) , then Computer Engineering and Sciences . https://en.wikipedia.org/wiki/Operations_research Operations research When we think in this context , propositions are ( NOT EXACT ) but as alternatives or an alternative . It is possible to think of moving the Handbook into the source tree because manual pages are within the source tree . It may even be possible to construct some parts of the Handbook by utilizing the manual pages . In that way , errors due to repetitions will be eliminated easily . Therefore the main problem is not the way of the implementation of separate handbooks but maintaining separate handbooks and achieving correct and usable information in them . My proposition is also considering "branching" of a new release . If the Handbook is directly within the source tree or it is coupled into it in such a way that branching covers it . I think implementers will make their own decisions in the best way to realize it successfully and easily . Mehmet Erol Sanliturk > On 07/09/2021 08:01, Mehmet Erol Sanliturk wrote: > > Dear All , > > > > in many of my messages to FreeBSD mailing lists I am mentioning the > > following view : > > > >"Please move the Handbook into source tree , and > > Maintain it with respect to current release without mixing sliding > > releases : If you do this , > > maintenance of a correct Handbook is IMPOSSIBLE because maintenance > of > > associated IF statements about releases . > > " > > > > When we look at the following web pages , we see the following : > > > > https://www.freebsd.org/cgi/man.cgi > > FreeBSD Manual Pages > > > > In the second box of "All sections" line , there are lines about all of > > the FreeBSD releases > > with many more other systems . > > > > In spite of this , in the following page : > > > > https://docs.freebsd.org/en/books/handbook/ > > FreeBSD Handbook > > The FreeBSD Documentation Project > > > > > > " > > Abstract > > > > Welcome to FreeBSD! This handbook covers the installation and day to day > > use of > > FreeBSD 13.0-RELEASE, FreeBSD 12.2-RELEASE and FreeBSD 11.4-RELEASE. ... > > " > > > > A Handbook which ( for me , exactly , for the others , perhaps ) with > many > > errors ... > > > > > > I think that , it is NOT extraordinarily a difficult process to move the > > Handbook into source > > tree and maintaining it with respect to per release and insert into the > > above web page a part > > similar to the manual pages to display the requested Handbook with > respect > > to releases . > > In the present case , previous handbooks are lost , because of the > > difficulty of finding them . > > > > Thank you very much and my best wishes for you and humanity in these > > pandemic days ... > > > > > > Mehmet Erol Sanliturk > > > >
Re: PAM module for loading ZFS keys on login
Eric McCorkle wrote in : ... >> This patch creates a new PAM module that will load a ZFS key upon a >> successful login: https://reviews.freebsd.org/D31844. It will use the >> user's auth token as the key argument to loading a ZFS encryption key on >> a user-specific ZFS data set. ... Without knowing about libzfs i personally was stunned about the simplicity of your patch, having read the upstream one. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: PAM module for loading ZFS keys on login
Eric McCorkle wrote in : |Interesting, I wasn't aware of the upstream module. I'd say that's It's existence was the reason i have readded (now optional, and a tad different) session support for my pam_xdg PAM module, because i was thinking that, if such a many-eyes-seen thing of a software project that claims to be and aims at being enterprise, ships such a terrible and terribly broken thing, then i can also offer session tracking. But my manual at least states CAVEATS On Unix systems any “daemonized” program or script is reparented to the program running with PID 1, most likely leaving the PAM user session without PAM recognizing this. Yet careless such code may hold or expect availability of resources of the session it just left, truly performing cleanup when sessions end seems thus unwise. Since so many PAM modules do support session tracking and cleanup pam_xdg.so readded optional sup‐ port for this. But the real solution would be PAM session tracking in-kernel, somehow, wouldn't it? Also, on FreeBSD and OpenPAM many separate files exist in /etc/pam.d for things which might open a session, whereas linuxpam at least has /etc/pam.d/common-session; it has many common- things in fact, and in /etc/pam.d/sshd i for example see # # /etc/pam.d/sshd - openssh service module configuration # authinclude common-auth account include common-account passwordinclude common-password session include common-session --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: PAM module for loading ZFS keys on login
On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote: > Eric McCorkle wrote in > : > |Interesting, I wasn't aware of the upstream module. I'd say that's > > It's existence was the reason i have readded (now optional, and > a tad different) session support for my pam_xdg PAM module, > because i was thinking that, if such a many-eyes-seen thing of > a software project that claims to be and aims at being enterprise, > ships such a terrible and terribly broken thing, then i can also > offer session tracking. But my manual at least states > > CAVEATS >On Unix systems any “daemonized” program or script is reparented to the >program running with PID 1, most likely leaving the PAM user session >without PAM recognizing this. Yet careless such code may hold or > expect >availability of resources of the session it just left, truly performing >cleanup when sessions end seems thus unwise. Since so many PAM modules >do support session tracking and cleanup pam_xdg.so readded optional > sup‐ >port for this. If you use reaper facility, that would ensure that all (grand-)children of your session are always reparented to the reaper and not to init. In other words, you can reliable know when the session ends. See procctl(2) PROC_REAP_* commands. I believe that reaper-like functionality is available on all current Unix-like systems, even if under different names. > > But the real solution would be PAM session tracking in-kernel, > somehow, wouldn't it? > Also, on FreeBSD and OpenPAM many separate files exist in > /etc/pam.d for things which might open a session, whereas linuxpam > at least has /etc/pam.d/common-session; it has many common- things > in fact, and in /etc/pam.d/sshd i for example see > > # > # /etc/pam.d/sshd - openssh service module configuration > # > > authinclude common-auth > > account include common-account > > passwordinclude common-password > > session include common-session > > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >
Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0
On Tue, Sep 07, 2021 at 10:13:23AM +0200, Jakob Alvermark wrote: > ... > wlan0 does not associate after boot. (This is with iwm, AC 9260) > > My workaround is simply 'ifconfig wlan0 up'. > > After a few seconds wpa_supplicant associates and another few secods > later I have a DHCP IP address. > I just tried that (running main-n249159-bb61ccd530b7), and that (also) works for me -- in case that data point is of use. Peace, david -- David H. Wolfskill da...@catwhisker.org Life is not intended to be a zero-sum game. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: -CURRENT compilation time
Van: David Chisnall Datum: maandag, 6 september 2021 11:43 Aan: freebsd-current@freebsd.org Onderwerp: Re: -CURRENT compilation time On 06/09/2021 09:08, Jeremie Le Hen wrote: > Compiling C++ seems > extremely CPU heavy and this is made worse by the fact LLVM is built > twice (once for build/cross tools, once for the actual world). Note that you need to build LLVM twice only if you are actively debugging LLVM reproduceable deployment images. You actually don't need to build it at all, you can use an external toolchain to skip the first build and you can compile WITHOUT_TOOLCHAIN to avoid building the version that's installed and then install a toolchain from packages: https://wiki.freebsd.org/ExternalToolchain David Hi, I'm very interested in a base without llvm because of compile times. So I tried this in a jail with 14-current and pkg llvm12 installed. /etc/make.conf: WITHOUT_TOOLCHAIN=yes CROSS_TOOLCHAIN=llvm12 Buildworld, installworld and etcupdate went fine. "yes | make delete-old" removes the toolchain from base. Afterwards you can't do buildworld anymore. # make buildworld sh: cc: not found make: "/home/ronald/dev/freebsd/share/mk/bsd.compiler.mk" line 200: warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status make: "/home/ronald/dev/freebsd/share/mk/bsd.compiler.mk" line 204: Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. What am I missing? Regards, Ronald.
Re: Install to ZFS root is using device names hence failing when device tree is changed.
On 2021-Sep-06 17:45:31 +0200, Karel Gardas wrote: >just installed 14-current snapshot from 2.9. on uefi amd64 machine. >Installed from USB memstick which was detected as da0 into the ssd >hanging on usb3 in external enclosure which was detected as da1. > >ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as >/boot/efi and probably also something as root zpool. > >Anyway, expected thing happen. When I pulled out USB stick identified as >da0 on reboot, the drive on USB3 switch from da1 to da0 and result is >unbootable system with complains about various /dev/da1xx drives missing >for swap efi boot etc. Can you give more details about exactly what the errors and when they occur during the boot cycle. In particular: * Low-level boot (anything prior to the FreeBSD kernel) knows nothing about da0 or da1, so any problems there are associated with your BIOS config, not FreeBSD. * The swap partition will, by default, appear as a hard-wired device name in /etc/fstab - that will definitely need updating. This will prevent the "swapon" working but won't prevent the boot. * ZFS doesn't care about device names - it looks for ZFS labels on all possible devices. -- Peter Jeremy signature.asc Description: PGP signature
Re: PAM module for loading ZFS keys on login
Konstantin Belousov wrote in : |On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote: |> Eric McCorkle wrote in |> : |>|Interesting, I wasn't aware of the upstream module. I'd say that's |> |> It's existence was the reason i have readded (now optional, and |> a tad different) session support for my pam_xdg PAM module, |> because i was thinking that, if such a many-eyes-seen thing of |> a software project that claims to be and aims at being enterprise, |> ships such a terrible and terribly broken thing, then i can also |> offer session tracking. But my manual at least states |> |> CAVEATS |>On Unix systems any “daemonized” program or script is reparented \ |>to the |>program running with PID 1, most likely leaving the PAM user \ |>session |>without PAM recognizing this. Yet careless such code may \ ... |If you use reaper facility, that would ensure that all (grand-)children |of your session are always reparented to the reaper and not to init. In |other words, you can reliable know when the session ends. See |procctl(2) PROC_REAP_* commands. | |I believe that reaper-like functionality is available on all current |Unix-like systems, even if under different names. Ah it is really, really cool what becomes possible (everywhere;)! So (Open)PAM should maybe (configurably) enable this does for all programs which actually use modules which use session management. #?0|kent:free-src.git$ git grep PROC_REAP_ origin/main | grep -vE '\.2:|:tests/' | sed -E 's/^(.+:.+):.+$/\1/' | sort -u origin/main:sys/compat/freebsd32/freebsd32_misc.c origin/main:sys/kern/kern_procctl.c origin/main:sys/sys/procctl.h origin/main:usr.bin/timeout/timeout.c I do not have systemd here, but on Linux situation seems similar: #?0|kent:x$ tar -xf /x/balls/shadow/shadow-4.8.1.tar.xz #?0|kent:x$ grep -r REAP shadow-4.8.1/ #?1|kent:x$ tar -xf /x/balls/linux-pam/Linux-PAM-1.5.1.tar.xz #?0|kent:x$ grep -r REAP Linux-PAM-1.5.1/ [yes, pam_unix defines UNIX_REAP, not PR_SET_CHILD_SUBREAPER] #?0|kent:x$ tar -xf /x/balls/openssh/openssh-8.7p1.tar.gz #?0|kent:x$ grep -r REAP openssh-8.7p1/ #?1|kent:x$ Maybe this is why systemd flies, i would guess it does, and this gives you then reliable session management. I did not really know that actually, .. consciously. This is really cool, but still also that upstream OpenZFS module, and my one, and who knows which other PAM module also, perform really bad sad and bitter session counting via counter files, ... but that is a different topic. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: -CURRENT compilation time
On 06/09/2021 20:34, Wolfram Schneider wrote: With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 times faster (real or user+sys), down from 48 min to 19.5 min real time. Note that building LLVM with the upstream CMake + Ninja build system is *significantly* faster on a decent multicore machine than the FreeBSD bmake-based in-tree version. One of the things I'd love to prototype if I had time is a CMake-based build system for FreeBSD so that we could get all of the tooling integration from the compile_commands.json, reuse LLVM's (and any other contrib things that use CMake) build system without having to recreate it, and be able to use ninja, to build. David
Re: -CURRENT compilation time
On Tue, 7 Sep 2021, at 13:51, David Chisnall wrote: > One of the things I'd love to prototype if I had time is a CMake-based > build system for FreeBSD so that we could get all of the tooling > integration from the compile_commands.json, reuse LLVM's (and any other > contrib things that use CMake) build system without having to recreate > it, and be able to use ninja, to build. This would be a worthy FreeBSD foundation project IMHO. A+ Dave
Re: Move the Handbook into source tree
We have 3 main repos: src, ports and doc. There are good reasons why we are doing this, and it will not change in the near future. For further questions and details, please ask on the freebsd-docs mailing list. You are right that the documentation on our web site is mostly for -current, the state of the art of the code base. If you need the documentation for our supported releases please check our Documentation Archive at https://docs.freebsd.org/doc/ and select your favourite release, e.g. the handbook for FreeBSD 13.0 https://docs.freebsd.org/doc/13.0-RELEASE/usr/local/share/doc/freebsd/en/books/handbook/ the handbook for FreeBSD 12.0 https://docs.freebsd.org/doc/12.0-RELEASE/usr/local/share/doc/freebsd/en/books/handbook/ -Wolfram On Tue, 7 Sept 2021 at 09:03, Mehmet Erol Sanliturk wrote: > > Dear All , > > in many of my messages to FreeBSD mailing lists I am mentioning the > following view : > > "Please move the Handbook into source tree , and >Maintain it with respect to current release without mixing sliding > releases : If you do this , >maintenance of a correct Handbook is IMPOSSIBLE because maintenance of >associated IF statements about releases . > " > > When we look at the following web pages , we see the following : > > https://www.freebsd.org/cgi/man.cgi > FreeBSD Manual Pages > > In the second box of "All sections" line , there are lines about all of > the FreeBSD releases > with many more other systems . > > In spite of this , in the following page : > > https://docs.freebsd.org/en/books/handbook/ > FreeBSD Handbook > The FreeBSD Documentation Project > > > " > Abstract > > Welcome to FreeBSD! This handbook covers the installation and day to day > use of > FreeBSD 13.0-RELEASE, FreeBSD 12.2-RELEASE and FreeBSD 11.4-RELEASE. ... > " > > A Handbook which ( for me , exactly , for the others , perhaps ) with many > errors ... > > > I think that , it is NOT extraordinarily a difficult process to move the > Handbook into source > tree and maintaining it with respect to per release and insert into the > above web page a part > similar to the manual pages to display the requested Handbook with respect > to releases . > In the present case , previous handbooks are lost , because of the > difficulty of finding them . > > Thank you very much and my best wishes for you and humanity in these > pandemic days ... > > > Mehmet Erol Sanliturk -- Wolfram Schneider https://wolfram.schneider.org
Re: -CURRENT compilation time
Am 07.09.21 um 15:51 schrieb David Chisnall: > On 06/09/2021 20:34, Wolfram Schneider wrote: >> With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 >> times faster (real or user+sys), down from 48 min to 19.5 min real >> time. > > Note that building LLVM with the upstream CMake + Ninja build system is > *significantly* faster on a decent multicore machine than the FreeBSD > bmake-based in-tree version. > > One of the things I'd love to prototype if I had time is a CMake-based build > system for FreeBSD so that we could get all of the tooling integration from > the > compile_commands.json, reuse LLVM's (and any other contrib things that use > CMake) build system without having to recreate it, and be able to use ninja, > to > build. Wouldn't this break META_MODE? I'd rather be able to continue building the world within a few minutes (generally much less than 10 minutes, as long as there is no major LLVM upgrade) than have a faster LLVM build and then a slower build of the world ... Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0
In message , David Wolfskill writes: -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. > On Tue, Sep 07, 2021 at 10:13:23AM +0200, Jakob Alvermark wrote: > > ...=20 > > wlan0 does not associate after boot. (This is with iwm, AC 9260) > >=20 > > My workaround is simply 'ifconfig wlan0 up'. > >=20 > > After a few seconds wpa_supplicant associates and another few secods=20 > > later I have a DHCP IP address. > > > > I just tried that (running main-n249159-bb61ccd530b7), and that (also) > works for me -- in case that data point is of use. Hi, Commit 5fcdc19a8111 has addressed this.
Re: Move the Handbook into source tree
On Tue, Sep 7, 2021 at 7:51 PM Wolfram Schneider wrote: > We have 3 main repos: src, ports and doc. There are good reasons why > we are doing this, and it will not change in the near future. For > further questions and details, please ask on the freebsd-docs mailing > list. > > You are right that the documentation on our web site is mostly for > -current, the state of the art of the code base. If you need the > documentation for our supported releases please check our > Documentation Archive at > > https://docs.freebsd.org/doc/ > > and select your favourite release, e.g. > > the handbook for FreeBSD 13.0 > > https://docs.freebsd.org/doc/13.0-RELEASE/usr/local/share/doc/freebsd/en/books/handbook/ > > the handbook for FreeBSD 12.0 > > https://docs.freebsd.org/doc/12.0-RELEASE/usr/local/share/doc/freebsd/en/books/handbook/ > > -Wolfram > > On Tue, 7 Sept 2021 at 09:03, Mehmet Erol Sanliturk > wrote: > > > > Dear All , > > > > in many of my messages to FreeBSD mailing lists I am mentioning the > > following view : > > > > "Please move the Handbook into source tree , and > >Maintain it with respect to current release without mixing sliding > > releases : If you do this , > >maintenance of a correct Handbook is IMPOSSIBLE because maintenance of > >associated IF statements about releases . > > " > > > > When we look at the following web pages , we see the following : > > > > https://www.freebsd.org/cgi/man.cgi > > FreeBSD Manual Pages > > > > In the second box of "All sections" line , there are lines about all of > > the FreeBSD releases > > with many more other systems . > > > > In spite of this , in the following page : > > > > https://docs.freebsd.org/en/books/handbook/ > > FreeBSD Handbook > > The FreeBSD Documentation Project > > > > > > " > > Abstract > > > > Welcome to FreeBSD! This handbook covers the installation and day to day > > use of > > FreeBSD 13.0-RELEASE, FreeBSD 12.2-RELEASE and FreeBSD 11.4-RELEASE. ... > > " > > > > A Handbook which ( for me , exactly , for the others , perhaps ) with > many > > errors ... > > > > > > I think that , it is NOT extraordinarily a difficult process to move the > > Handbook into source > > tree and maintaining it with respect to per release and insert into the > > above web page a part > > similar to the manual pages to display the requested Handbook with > respect > > to releases . > > In the present case , previous handbooks are lost , because of the > > difficulty of finding them . > > > > Thank you very much and my best wishes for you and humanity in these > > pandemic days ... > > > > > > Mehmet Erol Sanliturk > > > If you consider me , now at home there is 4.4BSD Lite ( Version 2.0 . Released Sept 1995 ) as a memorial . I could not find any previous release because it is likely that I left them in my university during my retirement to allow them to install them in university student laboratories . Trouble is NOT ME , because since 1970 I have been in the computing area ( starting my work since 1966 ) . My PhD thesis is "A multimedia information management system ( 1995 )" getting two vetoes ( both of them being virtual ) , one PhD sufficiency examination because of "This thesis proposition is in very much upper level with respect to a PhD thesis requirements" , another veto in thesis defense because "We need to mention that , although this thesis is excellent , it is impossible to complete it as a PhD thesis due to its very complicated difficulty level . If we do not mention this , later on , if anyone sees our "Thesis defense evaluation report" may say that "How such a jury does not recognize the difficulty level of this thesis and does not mention it ." If all of you say "YES" , I will mention this point and say "NO" , but if any one of you says "NO" , my vote is "YES" . " They asked : "How did you do it ?" ... 'based on my vast experience and theoretical works performed previously " ... ( my primary work area is "Theoretical Computing Sciences" ) "Why did you not use simulation ? " ... "for me , writing a simulator is much more difficult than writing its own implementation sufficient to show its feasibility and usability ." ... Then trouble is an unusable handbook due to many errors spreaded over it due to its SLIDING nature of consisting of THREE separate releases . You may say that "The discussion area is in "docs" list . For me "NO" , because "It is a FreeBSD System Design Problem, not a 'docs' problem " , because use of FreeBSD is based on use of a handbook , because FreeBSD is not doing anything by itself , the only user doing everything . For this , the Handbook is a vital component for use of it . When tracking the mailing lists ( I am one of them , nearly the start of the Internet at least in my country Turkey ) mostly people are using it based on their experience or by reading sources . How can WE acquire such an expertise or is it possible that everyone will read the sources and use it ? I have mentione
Re: -CURRENT compilation time
> From: David Chisnall > Date: Tue, 7 Sep 2021 14:51:21 +0100 > On 06/09/2021 20:34, Wolfram Schneider wrote: > > With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 > > times faster (real or user+sys), down from 48 min to 19.5 min real > > time. > > Note that building LLVM with the upstream CMake + Ninja build system is > *significantly* faster on a decent multicore machine than the FreeBSD > bmake-based in-tree version. Just examples of llvm12 builds from my checking this . . . poudriere-devel llvm12 buil times, nothing else being built, all prerequisites already built (not that such are trivial): amd64 ThreadRipper 1950X with 128 GiByte of RAM, optane 1.4T media, 32 FreeBSD cpus: [00:00:07] [01] [00:00:00] Building devel/llvm12 | llvm12-12.0.1_4 [00:22:54] [01] [00:22:47] Finished devel/llvm12 | llvm12-12.0.1_4: Success for: ---Begin OPTIONS List--- ===> The following configuration options are available for llvm12-12.0.1_4: BE_AMDGPU=on: AMD GPU backend (required by mesa) CLANG=on: Build clang COMPILER_RT=on: Sanitizer libraries DOCS=on: Build and/or install documentation EXTRAS=on: Extra clang tools GOLD=on: Build the LLVM Gold plugin for LTO LIT=on: Install lit and FileCheck test tools LLD=on: Install lld, the LLVM linker LLDB=on: Install lldb, the LLVM debugger OPENMP=on: Install libomp, the LLVM OpenMP runtime library PYCLANG=off: Install python bindings to libclang > Options available for the single BACKENDS: you have to select exactly one of them BE_FREEBSD=off: Backends for FreeBSD architectures BE_NATIVE=on: Backend(s) for this architecture (X86) BE_STANDARD=off: All non-experimental backends ===> Use 'make config' to modify these settings ---End OPTIONS List--- Note the BE_NATIVE use. Also poudriere.conf has: ZPOOL=zoptb USE_TMPFS=yes ALLOW_MAKE_JOBS=yes For reference: # uname -apKU FreeBSD amd64_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #1 releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:28:31 PDT 2021 root@amd64_ZFS:/usr/obj/BUILDs/13_0R-amd64-nodbg-clang/usr/13_0R-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1300139 1300139 The swap/paging space stayed unused. aarch64 Honycomb with 64 GiByte of RAM, optane 480 GiByte media, 16 FreeBSD cpus: [00:00:15] [01] [00:00:00] Building devel/llvm12 | llvm12-12.0.1_4 [00:58:07] [01] [00:57:52] Finished devel/llvm12 | llvm12-12.0.1_4: Success for: ---Begin OPTIONS List--- ===> The following configuration options are available for llvm12-12.0.1_4: BE_AMDGPU=on: AMD GPU backend (required by mesa) CLANG=on: Build clang DOCS=on: Build and/or install documentation EXTRAS=on: Extra clang tools LIT=on: Install lit and FileCheck test tools LLD=on: Install lld, the LLVM linker OPENMP=on: Install libomp, the LLVM OpenMP runtime library PYCLANG=off: Install python bindings to libclang > Options available for the single BACKENDS: you have to select exactly one of them BE_FREEBSD=off: Backends for FreeBSD architectures BE_NATIVE=on: Backend(s) for this architecture (AArch64) BE_STANDARD=off: All non-experimental backends ===> Use 'make config' to modify these settings ---End OPTIONS List--- Note the BE_NATIVE use. Also poudriere.conf has: ZPOOL=zopt0 USE_TMPFS="data" ALLOW_MAKE_JOBS=yes For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 The swap/paging space stayed unused. I've not yet figured out a good way to time just an analogous subset of buildworld . It would need to be stable/13 or main [so: 14] targetted to involve building an llvm12 based set of material. releng/13.0 is llvm11 based. One point is that likely the system builds libc++ and such but devel/llvm12 does not: devel/llvm12 likely is bound to the system libc++ and such. This may make "analogous subset of buildworld" harder to isolate. So I've not made it to well-measured differences in time-used yet. > One of the things I'd love to prototype if I had time is a CMake-based > build system for FreeBSD so that we could get all of the tooling > integration from the compile_commands.json, reuse LLVM's (and any other > contrib things that use CMake) build system without having to recreate > it, and be able to use ninja, to build. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
killall, symlinks, and signal delivery?
I have stumbled about a quandry, which I hope someone can shed some light upon. In my day job, I often generate a sequence of images and display these images with ImageMagick's display command. From my csh prompt, a quick and dirty foreach() loop % foreach i (*.png) > display $i & > sleep 3 > end Instead of moving the cursor to each image and hitting 'q' to close the images. I normally kill all of the processes at one time. This used to work: % killall display Now I geit, for example, % display z.miff & % killall display No matching processes belonging to you were found % ps -Ukargl | grep display 19463 1 S0:00.02 display z.miff (magick) 19465 1 S+ 0:00.00 grep display % ls -l /usr/local/bin/display lrwxr-xr-x 1 root wheel - 6 Jun 1 14:18 /usr/local/bin/display@ -> magick So, there are two possibilities: (1) display was once an independent program and not a symlink to magick. Thus, killall just worked. Or, (2) killall no longer works because command associated with process 19463 is not really 'display' and the symlink isn't resolved to actually kill 'magick'. So, just chekcing (2), here. Is this a change in behvior for FreeBSD? -- Steve
Re: killall, symlinks, and signal delivery?
On September 7, 2021 3:42:53 PM PDT, Steve Kargl wrote: >I have stumbled about a quandry, which I hope someone >can shed some light upon. In my day job, I often >generate a sequence of images and display these images >with ImageMagick's display command. From my csh prompt, >a quick and dirty foreach() loop > >% foreach i (*.png) >> display $i & >> sleep 3 >> end > >Instead of moving the cursor to each image and hitting >'q' to close the images. I normally kill all of the >processes at one time. This used to work: > >% killall display > >Now I geit, for example, > >% display z.miff & >% killall display >No matching processes belonging to you were found >% ps -Ukargl | grep display >19463 1 S0:00.02 display z.miff (magick) >19465 1 S+ 0:00.00 grep display >% ls -l /usr/local/bin/display >lrwxr-xr-x 1 root wheel - 6 Jun 1 14:18 /usr/local/bin/display@ -> magick > >So, there are two possibilities: >(1) display was once an independent program and not a >symlink to magick. Thus, killall just worked. Or, >(2) killall no longer works because command associated >with process 19463 is not really 'display' and the >symlink isn't resolved to actually kill 'magick'. > >So, just chekcing (2), here. Is this a change in behvior >for FreeBSD? > It's likely your app is replacing its process name (argv[0]) to something else. ps auxww may give you a hint what it might be now. -- Pardon the typos and autocorrect, small keyboard in use. Cy Schubert FreeBSD UNIX: Web: https://www.FreeBSD.org The need of the many outweighs the greed of the few. Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: killall, symlinks, and signal delivery?
On Tue, Sep 07, 2021 at 04:20:30PM -0700, Cy Schubert wrote: > On September 7, 2021 3:42:53 PM PDT, Steve Kargl > wrote: > >I have stumbled about a quandry, which I hope someone > >can shed some light upon. In my day job, I often > >generate a sequence of images and display these images > >with ImageMagick's display command. From my csh prompt, > >a quick and dirty foreach() loop > > > >% foreach i (*.png) > >> display $i & > >> sleep 3 > >> end > > > >Instead of moving the cursor to each image and hitting > >'q' to close the images. I normally kill all of the > >processes at one time. This used to work: > > > >% killall display > > > >Now I geit, for example, > > > >% display z.miff & > >% killall display > >No matching processes belonging to you were found > >% ps -Ukargl | grep display > >19463 1 S0:00.02 display z.miff (magick) > >19465 1 S+ 0:00.00 grep display > >% ls -l /usr/local/bin/display > >lrwxr-xr-x 1 root wheel - 6 Jun 1 14:18 /usr/local/bin/display@ -> magick > > > >So, there are two possibilities: > >(1) display was once an independent program and not a > >symlink to magick. Thus, killall just worked. Or, > >(2) killall no longer works because command associated > >with process 19463 is not really 'display' and the > >symlink isn't resolved to actually kill 'magick'. > > > >So, just chekcing (2), here. Is this a change in behvior > >for FreeBSD? > > > > It's likely your app is replacing its process name > (argv[0]) to something else. ps auxww may give you a > hint what it might be now. Yes, that's likely. So, it could be a change in behavior for ImageMagick. Your suggested ps command doesn't provide anything new. ps shows the command that I entered, namely, 'display coarse_sand.jpg'. But, it also shows '(magick)', which is the actual name of the program. I'm guessing argv[0] = "magick". % ps 24333 7 I 0:00.43 display coarse_sand.jpg (magick) % killall magick does the job of killing the displayed image. -- Steve
Re: killall, symlinks, and signal delivery?
Steve Kargl wrote: > Yes, that's likely. So, it could be a change in behavior > for ImageMagick. Your suggested ps command doesn't provide I don't know when the change was made, but the pkg for ImageMagik 6.9.12.12 has "display" as a stand-alone binary, whilst the pkg for 7.0.11.12 has it as a softlink. So yeah, either an upstream change, or a port change. Cheers, Jamie
