From owner-freebsd-questions@freebsd.org Sun Jun 13 09:25:26 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29E546596EE for ; Sun, 13 Jun 2021 09:25:26 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2q1d20tvz586t; Sun, 13 Jun 2021 09:25:24 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=Message-ID:Subject:To:From:Date:In-Reply-To; bh=m63ZzbmALBs+Cha5Gipd4g5u2hbC8M6AZuWhxE6k7wc=; b=KjGmvsGp3kosuNwj/kDUUVyoXU FSHwRBuIA81Ud6hI6UVcPpLsjoVLacEra2oghNYpEpb4KYwPQpXOhSVRM0QrJ4IDUoMNkjxsSSZPJ sP5l/EXU7x3389/FKS0tGGs3pbSc/FJd/Z4FV+rO/RVLLaCIFCAeMlxXrLuPFQNBwtF4=; Received: from vas by admin.sibptus.ru with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1lsMMn-0001WJ-EG; Sun, 13 Jun 2021 16:25:17 +0700 Date: Sun, 13 Jun 2021 16:25:17 +0700 From: Victor Sudakov To: freebsd-pkg@freebsd.org Cc: freebsd-questions@freebsd.org Subject: pourdiere broken for i386 jails ? (or maybe not poudriere per se) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OagdzASRn2iE9+24" Content-Disposition: inline X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 X-Rspamd-Queue-Id: 4G2q1d20tvz586t X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=KjGmvsGp; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-6.10 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:5001:21dc::10:from]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2001:19f0:5001:21dc::10:from:127.0.2.255]; DKIM_TRACE(0.00)[sibptus.ru:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-pkg,freebsd-questions]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 09:25:26 -0000 --OagdzASRn2iE9+24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Colleagues, Suddenly poudriere and poudriere-devel stopped working for i386 jails. I can't say when exactly this happened but probably after a recent freebsd-update. root@svn:~ # uname -rm 12.2-RELEASE-p7 amd64 root@svn:~ # poudriere bulk -j 114i386 -f /usr/local/etc/poudriere.d/pkglist.txt [00:00:00] Creating the reference jail... done [00:00:00] Mounting system devices for 114i386-default [00:00:00] Using packages from previously failed build: /poudriere/data/packages/114i386-default/.building [00:00:00] Mounting ports from: /poudriere/ports/default [00:00:00] Mounting packages from: /poudriere/data/packages/114i386-default [00:00:00] Mounting distfiles from: /usr/ports/distfiles [00:00:00] Copying /var/db/ports from: /usr/local/etc/poudriere.d/options [00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf -> /poudriere/data/.m/114i386-default/ref/etc/resolv.conf [00:00:00] Starting jail 114i386-default ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap [00:00:00] Error: Unable to execute id(1) in jail. Emulation or ABI wrong. [00:00:01] Cleaning up [00:00:01] Unmounting file systems root@svn:~ #=20 I tried deleting and recreating the "114i386" jail to no avail. I remember having this problem several years ago but cannot recall how it resolved. Mo= reover: root@svn:~ # chroot /poudriere/jails/114i386 ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort root@svn:~ # /poudriere/jails/114i386/bin/ls ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort root@svn:~ #=20 root@svn:~ # file /poudriere/jails/114i386/libexec/ld-elf.so.1 /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped root@svn:~ #=20 --=20 Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet --OagdzASRn2iE9+24 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJgxc79AAoJEA2k8lmbXsY09uEH/1Xfs0EMLV243de2/jSdEJ4I /mZ+yQeYm5Ifeaetz7s9cUFIP1yCr2EB5cKOVCuXEvAVmQWODOu0p1pGwAK8f12c /Wa/wfz4CzIhXf+qy3ulkbP99PQIz7PdesK6Ugkq6r4keycGqnTwF7ATLHop+CbI hseCgav1SwWdrXBqkgFUQOuIZN02GnLyft4OIewk+6sXsNOJL/DLoAr4z45k5Kcv YKFI0q4JIlxbtQylP70rTISMr7dY6w80JNphxr+yCTuU1oX4jrfNQ5HbhIYcroJr QA3GIE8jT6iy13yMUKTgMOFMjwXTLr98OgVl5rtnr84BrEwfamhC9VY9sI7g5a8= =sr1a -----END PGP SIGNATURE----- --OagdzASRn2iE9+24-- From owner-freebsd-questions@freebsd.org Sun Jun 13 09:27:10 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3AD68659A70 for ; Sun, 13 Jun 2021 09:27:10 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2q3d58vBz58pK for ; Sun, 13 Jun 2021 09:27:09 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=V6RaHm82upglM/GABFUSb6NXtfNF60e+d5Dlyte9oO4=; b=J6z63cuEAMS6Ucs6X+Lp3CSiRd PKZslhfgnq0N+uR/fKSFn00lSBHmJ+vkslO2ayyjw0ev2Q7bYq2/VEK71MaIPL3Er7Izer09f5Kvz w5zGV501JIgT3DNkS8w7kPK/9JsMczYXoHmA7Ors3791cQSFmbGgqLycSXFtyBEuzOFY=; Received: from vas by admin.sibptus.ru with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1lsMOa-0001XS-EY; Sun, 13 Jun 2021 16:27:08 +0700 Date: Sun, 13 Jun 2021 16:27:08 +0700 From: Victor Sudakov To: Paul Procacci Cc: Odhiambo Washington , FreeBSD Questions Subject: Re: lang/php72 needed Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QyQWYB4aw4+5kEAp" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 X-Rspamd-Queue-Id: 4G2q3d58vBz58pK X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=J6z63cuE; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-6.10 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:5001:21dc::10:from]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; SPAMHAUS_ZRD(0.00)[2001:19f0:5001:21dc::10:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-questions]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 09:27:10 -0000 --QyQWYB4aw4+5kEAp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Paul Procacci wrote: > >> The closest equivalent to Docker is jail, but jail lacks all the > >> infrastructure and automation Docker has. There are attempts to build > >> something like Docker (iocage is the most known IMHO but its images are > >> not layered which kills all the fun). >=20 > Never tried this, but you may want to evaluate focker. >=20 > https://github.com/sadaszewski/focker >=20 > It may be 'good enough' for your needs. >=20 > Who knows. >=20 > Good Luck. Interesting, as a funny curiosity. I don't think it will become anything more than a toy. --=20 Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet --QyQWYB4aw4+5kEAp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJgxc9sAAoJEA2k8lmbXsY0UKMH+wVSecQRR2Th5b6BimkP84DE GKOqwabhpB5QIKsC5LxPnY/zwoD5K1YlUF8W8d7cTm2HlcEupFps6RqVCPz4xc2+ IHk3L7nQCFmqtsti11IBAiRQFxKvxy00/qPhWpDI6uoQkHwbuEWOiuHtYwDHI+C+ oNzy5zdOa+6FVdK8vMxFjDxtTeFQl/9caARaglK0MCyNzocBVekXMkMzSgAY3ErJ 5WN0/y2hbQW47Xe0+VuzWF6B3sziP3V/hXoG50OvW6GHH3Nl9QdK1pyLOmh9Phv9 Fa7NveqCBksTfPL/EKTYORKkE7QuQMuW8lTsSXzFFG7eCeEvBsz9J9ri3foL/Ao= =OewI -----END PGP SIGNATURE----- --QyQWYB4aw4+5kEAp-- From owner-freebsd-questions@freebsd.org Sun Jun 13 10:52:38 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E58C765AFDD for ; Sun, 13 Jun 2021 10:52:38 +0000 (UTC) (envelope-from 4250.82.1d4d20004526d93.1a697a84c2d009b47a08833a1e564684@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2ryF72kWz3Fpn for ; Sun, 13 Jun 2021 10:52:37 +0000 (UTC) (envelope-from 4250.82.1d4d20004526d93.1a697a84c2d009b47a08833a1e564684@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1623581558; x=1626173558; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:cc:to:from:date:x-thread-info; bh=d4REglLTFp1gpwZHtVS+mo5oDGGacbyJ1LUg46vvnPA=; b=eoRJf7a2vz1VmDoPqMOMVzhHFcnAhqrN395qIGBONlCaYK6Vq/MHAnyMD+VSkjZtT3nTCufSGWfmqkyk66HtqWl0r6MzRl2Xilj5KmVVZcKN6qWTAkycNQnp2C8T+iQE1hwecUV3U6o3hzraKzGP4TJuJvSs3KnT3+N+Z7txlyc= X-Thread-Info: NDI1MC4xMi4xZDRkMjAwMDQ1MjZkOTMuZnJlZWJzZC1xdWVzdGlvbnM9ZnJlZWJzZC5vcmc= Received: from r2.us-west-2.aws.in.socketlabs.com (r2.us-west-2.aws.in.socketlabs.com [142.0.190.2]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Sun, 13 Jun 2021 06:52:25 -0400 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r2.us-west-2.aws.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Sun, 13 Jun 2021 06:52:22 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1lsNj2-0000W0-Fe; Sun, 13 Jun 2021 11:52:20 +0100 Date: Sun, 13 Jun 2021 11:52:20 +0100 From: Steve O'Hara-Smith To: Victor Sudakov Cc: Odhiambo Washington , FreeBSD Questions , Paul Procacci Subject: Re: lang/php72 needed Message-Id: <20210613115220.649a225ee12d5046204e8348@sohara.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G2ryF72kWz3Fpn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=eoRJf7a2; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d4d20004526d93.1a697a84c2d009b47a08833a1e564684@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d4d20004526d93.1a697a84c2d009b47a08833a1e564684@email-od.com X-Spamd-Result: default: False [-2.70 / 15.00]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d4d20004526d93.1a697a84c2d009b47a08833a1e564684@email-od.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sohara.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[142.0.176.198:from]; SPAMHAUS_ZRD(0.00)[142.0.176.198:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[email-od.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d4d20004526d93.1a697a84c2d009b47a08833a1e564684@email-od.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 10:52:39 -0000 On Thu, 10 Jun 2021 12:35:44 +0700 Victor Sudakov wrote: > bhyve != Docker. These are different technologies. > The Linux equivalent of bhyve is kvm. > > The closest equivalent to Docker is jail, but jail lacks all the Nope jail is the equivalent of LXC (containers) on Linux, a layer below Docker. > infrastructure and automation Docker has. There are attempts to build > something like Docker (iocage is the most known IMHO but its images are > not layered which kills all the fun). Indeed Docker is a layer above the containers and hypervisors and below the orchestration layer provided by Kubernetes. -- Steve O'Hara-Smith From owner-freebsd-questions@freebsd.org Sun Jun 13 14:24:37 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3ACE065D1B4 for ; Sun, 13 Jun 2021 14:24:37 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2xfr39VSz3jYN for ; Sun, 13 Jun 2021 14:24:36 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 116A85C008F for ; Sun, 13 Jun 2021 10:24:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 13 Jun 2021 10:24:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm2; bh=xMiOL3hbqrSDXM7xOrIw4j8aW/WlugFfILK9G8pJWLY=; b=ms0+9hvu dqY0oos/t5vzED5yYtSzl+brXDujjgVkl6IJDRyq/kWJbw9RZ8X3j3pOBU6KhB7w U9m82houyVrhJxnyAKNaEeFRJkBKpZxaMQ2ZJDA4qWkQpA63HGU7itIhUHvFRyil whlNMASX/DvR9YsU9czDFvA+s/ZXrhTPsNmHX42FSCgwAmrnNoI/nkYd3njiGRwx GPnUgpSntWVuk9r69eJngMruPPET6EhRlT8d8GURqKqVdKIGIga98h3jYlhjE3vG gbRuKyEhng5s4BFI3vKLh0wQeZb9BHRGi1TLMOAGL5lkrhd5D/NlnAvm+pYKBhq+ FXTRnGXXI6nbIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=xMiOL3hbqrSDXM7xOrIw4j8aW/Wlu gFfILK9G8pJWLY=; b=K5VjBmkhYL7IQwK5xBoa6Qh4XD3ZRWB3drDQTL/equaDz ol2JVwljg8MIuJmWjU8RkbCSJrlBVWF630d/SCEwM2sBW0JtMZ9qELw9MhFShWhC CN2cH+zVjlFjSAqrauf7eGsNWhvRXt7HeOshv73k/zaTkbeqnbsh3qvDh/uvs6yK vY7Qz4GMv14bwM7FGt8u/y1mEsDmS1ABkmkU9kBGN10Z5PbtzKR3e/v/IMVI9GxU SYOkAR73yLDHcoOq58K1JIbTewfK1ISkuIMZRbih0PNMeNQIe0b0mwZ9Wh3CE/nC tHU25u3J27g+dso3N3xNyEy7rQOM0J9wRnoOPn8XQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvfedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiig shhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevgffhffdtfeekleelhedtjeelvdfhvd egieejveffgfduvdfhteegjeeujeeuieenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 13 Jun 2021 10:24:35 -0400 (EDT) Date: Sun, 13 Jun 2021 15:24:34 +0100 From: tech-lists To: freebsd-questions@freebsd.org Subject: freebsd tftp server for hetrogenous diskless clients Message-ID: Mail-Followup-To: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ps7KC//FGUh0KtdQ" Content-Disposition: inline X-Rspamd-Queue-Id: 4G2xfr39VSz3jYN X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=ms0+9hvu; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=K5VjBmkh; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.26 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-5.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26:c]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.111.4.26:from]; ASN(0.00)[asn:11403, ipnet:66.111.0.0/20, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.111.4.26:from:127.0.2.255]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 14:24:37 -0000 --ps7KC//FGUh0KtdQ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Can freebsd be a pxe/tftp/nfs server for linux (ubuntu/debian/arch) clients? any pitfalls/gotchas? thanks, --=20 J. --ps7KC//FGUh0KtdQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmDGFSEACgkQs8o7QhFz NAWW9g//W2lK4qqePI6QqRxns783mXTvtPBDrgcvpvWIu3GzK2dC5ELr6AtGpg/A EpXW/JsksCwafYnrPK/7sJUe+C9t0soxj4AifCmU5dmjQ+V9HF0xjYYROJAAKAU/ 14zboHoQzwVasGvv9qC7SmakyR22bF9R/XwXkgo/I2yoQt/GOQRp0B/fuBONwddo xz4KjhDHMNk9GnUpjeWu75TwyfqqewQZ3eEasNm1cTyeVi+gql3dnudwmRABOg2I naVcL7D+Uo7EJZYjb/jP+zZrubv5nkNtfTGKXt71zZxJeOe5ZhTapRlPKwTyg6jn a2bCgpgDmBm48IMP/mUV/elqa2kEUqtw7I00d2EOBg78hyfV+9muqPNiQYBJYQFr JFaqQ/IaH3i2EAjXrNmHaWiuLccso0WhkwMD2ms/vCX6a5k0i3UK1EhsgQR25TPF jYsYUvXi2yw1ihlwqJSXSu/eW12SzbsLcR53snJeskf1VdxjfgLHfhJ2q1LfjHMf a9Rp34VsMd05TUpy+325xMe3QThYOICJPEBGoggnx6wRIDF3bJtSeWvz5VGa9ZbW qKcwReGHX0SjuYFG/BQ3Be9nbs2JDRi46PGgalEnj3KGSiVyweGEAL9nYZO56tKD NX0JSzzLGxxfBFWjI22zhpDRhCKBgWy9j0rRngS6hs3finLDAfc= =M0S+ -----END PGP SIGNATURE----- --ps7KC//FGUh0KtdQ-- From owner-freebsd-questions@freebsd.org Sun Jun 13 15:47:28 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7B9A465E238 for ; Sun, 13 Jun 2021 15:47:28 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2zVR3pYrz3qgL for ; Sun, 13 Jun 2021 15:47:27 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=O+HjGWpGVYmmf+P+c8CRKcmbAM84g/1Z9A3IFq20TJY=; b=BsxlMd4YikTCvtyFObl8vHmyS1 8bxJRW6NUud+LAYYQbtSs5cOdKu1p9SGsFQn7aviE/uFG+sVCxgkFTrsGOXlwMRDkpZz1fZndCw2C HgOlru/CC65Xr6b2YA/jpqEd1Bn/mPlWHls6Vt+MgFUDE2YL8KdVkFFM0Iara5deqYGU=; Received: from vas by admin.sibptus.ru with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1lsSKZ-0003OR-BN; Sun, 13 Jun 2021 22:47:23 +0700 Date: Sun, 13 Jun 2021 22:47:23 +0700 From: Victor Sudakov To: Steve O'Hara-Smith Cc: Odhiambo Washington , FreeBSD Questions , Paul Procacci Subject: Re: lang/php72 needed Message-ID: References: <20210613115220.649a225ee12d5046204e8348@sohara.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DiBf19guPPpAIrGG" Content-Disposition: inline In-Reply-To: <20210613115220.649a225ee12d5046204e8348@sohara.org> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 X-Rspamd-Queue-Id: 4G2zVR3pYrz3qgL X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=BsxlMd4Y; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-6.10 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:5001:21dc::10:from]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; SPAMHAUS_ZRD(0.00)[2001:19f0:5001:21dc::10:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-questions]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 15:47:28 -0000 --DiBf19guPPpAIrGG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Steve O'Hara-Smith wrote: > On Thu, 10 Jun 2021 12:35:44 +0700 > Victor Sudakov wrote: >=20 > > bhyve !=3D Docker. These are different technologies. > > The Linux equivalent of bhyve is kvm. > >=20 > > The closest equivalent to Docker is jail, but jail lacks all the >=20 > Nope jail is the equivalent of LXC (containers) on Linux, a layer > below Docker. Dunno, https://en.wikipedia.org/wiki/List_of_Linux_containers lists Docker and LXC as different container technologies. Maybe Wikipedia is incorrect about it. --=20 Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet --DiBf19guPPpAIrGG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJgxiiLAAoJEA2k8lmbXsY0x/gH/3mqPH5vzUHSaYH85FoqSzG6 QWorGhTTwX6f7WxS78TjKle3lVEoYc2N9K4/2UMjmPILRv958y+P/YgqvJJFtlIq KeMRABkxhQz71Nzd5IPjjnc5kKilSjCj4ZXhkZE3Fmeb1Eqev6BI2OAwXtGHENn6 U7BWjdTDlvkVMTP0esVxeIhnMYq+ZKZk149ZDxxvaUvWXet2slY1BmiX1JG6K3Ik RN7KqveXHfGJZg3PFfdN0yPgo8Lwk2GEnKECheGuZdmarkTSfqQkXd2fZN9uXUf3 JPjJKNr2NaFZoRvzqhDh5B533rzGkcPZUZ1jIeCqtoLjVSljzAgYup1Dp3QzFQs= =q9eF -----END PGP SIGNATURE----- --DiBf19guPPpAIrGG-- From owner-freebsd-questions@freebsd.org Sun Jun 13 15:58:18 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7C43365ED81 for ; Sun, 13 Jun 2021 15:58:18 +0000 (UTC) (envelope-from 4250.82.1d4d20004590b86.b76981ed2aa390748f192c79e3b2b47a@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2zkx4r9zz3rL6 for ; Sun, 13 Jun 2021 15:58:17 +0000 (UTC) (envelope-from 4250.82.1d4d20004590b86.b76981ed2aa390748f192c79e3b2b47a@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1623599898; x=1626191898; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:cc:to:from:date:x-thread-info; bh=/Q86QsFJ4a22SZoi/tIawk/0yNojOpKBrLrfYZE1f0g=; b=ibIB1UOQE09fohnvbJdHt/867HKP/nMfwvxWmE2ftZqhZa93wDGyXtorPxIM8r/k0oqRk8aNYrRjJx5a9HKRIbAP1jfUXSlfQ7OD/d7RBjIrBKfXssn5VRae8/+yfDVoo53sL/x+StPmeXJtddbxevDxSNaCeGXOU8EPBmRk49A= X-Thread-Info: NDI1MC4xMi4xZDRkMjAwMDQ1OTBiODYuZnJlZWJzZC1xdWVzdGlvbnM9ZnJlZWJzZC5vcmc= Received: from r1.us-east-1.aws.in.socketlabs.com (r1.us-east-1.aws.in.socketlabs.com [142.0.191.1]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Sun, 13 Jun 2021 11:58:13 -0400 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r1.us-east-1.aws.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Sun, 13 Jun 2021 11:58:12 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1lsSV0-0002dr-Ch; Sun, 13 Jun 2021 16:58:10 +0100 Date: Sun, 13 Jun 2021 16:58:10 +0100 From: Steve O'Hara-Smith To: Victor Sudakov Cc: Odhiambo Washington , FreeBSD Questions , Paul Procacci Subject: Re: lang/php72 needed Message-Id: <20210613165810.00c23cd91a198c77e221001f@sohara.org> In-Reply-To: References: <20210613115220.649a225ee12d5046204e8348@sohara.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G2zkx4r9zz3rL6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=ibIB1UOQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d4d20004590b86.b76981ed2aa390748f192c79e3b2b47a@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d4d20004590b86.b76981ed2aa390748f192c79e3b2b47a@email-od.com X-Spamd-Result: default: False [-2.70 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sohara.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[142.0.176.198:from]; SPAMHAUS_ZRD(0.00)[142.0.176.198:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[email-od.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d4d20004590b86.b76981ed2aa390748f192c79e3b2b47a@email-od.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d4d20004590b86.b76981ed2aa390748f192c79e3b2b47a@email-od.com]; MAILMAN_DEST(0.00)[freebsd-questions]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 15:58:18 -0000 On Sun, 13 Jun 2021 22:47:23 +0700 Victor Sudakov wrote: > Dunno, https://en.wikipedia.org/wiki/List_of_Linux_containers lists > Docker and LXC as different container technologies. Maybe Wikipedia is > incorrect about it. It is, Docker uses LXC. -- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/ From owner-freebsd-questions@freebsd.org Sun Jun 13 16:02:53 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4FD5265EE24 for ; Sun, 13 Jun 2021 16:02:53 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [198.71.6.79]) by mx1.freebsd.org (Postfix) with ESMTP id 4G2zrD2l9Mz3rMj for ; Sun, 13 Jun 2021 16:02:51 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [198.71.6.79]) by mail2.nber.org (8.16.1/8.15.2) with ESMTPS id 15DG2omc004041 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 13 Jun 2021 12:02:50 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Sun, 13 Jun 2021 12:02:49 -0400 (EDT) From: Daniel Feenberg To: tech-lists cc: freebsd-questions@freebsd.org Subject: Re: freebsd tftp server for hetrogenous diskless clients In-Reply-To: Message-ID: <17986d52-bbf3-96a7-e1bb-4ecdee69962c@nber.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiSpam-Interceptor-Info: not scanned X-KLMS-AntiPhishing: Clean, 1970/01/01 00:00:00 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2021/06/13 01:13:00 #12233019 X-KLMS-AntiVirus-Status: Clean, skipped X-Rspamd-Queue-Id: 4G2zrD2l9Mz3rMj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of feenberg@nber.org designates 198.71.6.79 as permitted sender) smtp.mailfrom=feenberg@nber.org X-Spamd-Result: default: False [-3.50 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nber.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[198.71.6.79:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:26287, ipnet:198.71.6.0/23, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions]; RWL_MAILSPIKE_POSSIBLE(0.00)[198.71.6.79:from] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 16:02:53 -0000 On Sun, 13 Jun 2021, tech-lists wrote: > Hi, > > Can freebsd be a pxe/tftp/nfs server for linux > (ubuntu/debian/arch) clients? > > any pitfalls/gotchas? We have more than 30 Linux clients PXE booting from a FreeBSD server. This is not a network install, /bin /sbin etc are NFS mounts. We have been doing this for many years, currently the Linux clients are all CentOS, they have been Ubuntu at times in the past. Both FreeBSD and Linux have been kept up to current supported releases. We like PXE booting with system files on read-only server because it makes updates quick and easy, ensures uniformity across clients and is in general convenient. We don't do it to save disk space. Network bandwidth is not really a problem - 1GBE is fine for this, although we upgraded to 10GBE some years ago because the applications do a lot of network I/O. If you lose the network connection the client will hang till the network is restored, and jobs will continue from where they left off. Daniel Feenberg NBER > > thanks, > -- > J. > From owner-freebsd-questions@freebsd.org Mon Jun 14 10:19:31 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2D2AD642FF3 for ; Mon, 14 Jun 2021 10:19:31 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G3S9Y517jz4gSB for ; Mon, 14 Jun 2021 10:19:29 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 7DE3C4E6BD; Mon, 14 Jun 2021 03:19:22 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Periodic tasks are not nice MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26812.1623665962.1@segfault.tristatelogic.com> Date: Mon, 14 Jun 2021 03:19:22 -0700 Message-ID: <26813.1623665962@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G3S9Y517jz4gSB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 10:19:31 -0000 Up late and found my system to be rather sluggish. Poked around and found this running: /usr/local/etc/periodic/security/460.pkg-checksum top shows it is -not- nice'd. Shouldn't all these sorts of background taks be nice'd? From owner-freebsd-questions@freebsd.org Mon Jun 14 08:40:06 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EE5DF64CF80 for ; Mon, 14 Jun 2021 08:40:06 +0000 (UTC) (envelope-from stenn@nwtime.org) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3Pys5dF8z4Z22 for ; Mon, 14 Jun 2021 08:40:04 +0000 (UTC) (envelope-from stenn@nwtime.org) Received: from [10.208.75.157] (075-139-201-087.res.spectrum.com [75.139.201.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4G3Pyh6BbSzMNM9; Mon, 14 Jun 2021 08:39:56 +0000 (UTC) To: freebsd-questions@freebsd.org From: Harlan Stenn Subject: mlmmj team Message-ID: Date: Mon, 14 Jun 2021 01:39:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G3Pys5dF8z4Z22 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=nwtime.org; spf=pass (mx1.freebsd.org: domain of stenn@nwtime.org designates 66.220.13.234 as permitted sender) smtp.mailfrom=stenn@nwtime.org X-Spamd-Result: default: False [-1.98 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.220.13.234:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.220.13.234:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.82)[0.821]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[nwtime.org,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:66.220.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-Mailman-Approved-At: Mon, 14 Jun 2021 12:30:56 +0000 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 08:40:07 -0000 Hi, I've got some questions for the folks who are switching the FreeBSD mailing lists from mm2 to mlmmj. How can I reach these folks? Thanks... -- Harlan Stenn http://networktimefoundation.org - be a member! From owner-freebsd-questions@freebsd.org Mon Jun 14 09:29:24 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 64C756582FC for ; Mon, 14 Jun 2021 09:29:24 +0000 (UTC) (envelope-from alex.ernst19@gmail.com) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3R3l3wzjz4dC9 for ; Mon, 14 Jun 2021 09:29:23 +0000 (UTC) (envelope-from alex.ernst19@gmail.com) Received: by mail-ot1-x333.google.com with SMTP id o17-20020a9d76510000b02903eabfc221a9so10252024otl.0 for ; Mon, 14 Jun 2021 02:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Kgjfnw+G5qvqM2IqKCxDs5Nq0CT1Ru6kD7qdYw5ZdMA=; b=fzJ3/wjPP8MuR1ch6iJfy0Skz1F2DFo8dX6XtgNdhVD0QaMwDXwyrbLDhD24Qrhqg8 qYHpxgeS6NuHGvNEi3qULvuIuSGPFeVLcC+XuJhOitGvV+vf36kilLPfxnT7XkA/KFi7 N22D/nh6jgZu63FG9xa6u+Vx7/jTtwqcV1niohfSOdiGTDmrCEKz776rR52mxsNE3AzQ M74bh4PqrXKkK8F6bHHqKyY4kxuy1Y+LAgWfRlTkYngTEi9k+9iqXXkI8KL0+Rdg/4t9 gw0aGhjpr6Mqnz1Iixiwv5PA/xtXzOTEN3jzduEF91pztT+XCCd7W/+ItWQQiOOc1U05 24bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Kgjfnw+G5qvqM2IqKCxDs5Nq0CT1Ru6kD7qdYw5ZdMA=; b=oHFZ05tdBsqd+6dM+zuIxDDkaDuM8P8tO9dN8fOLstGhnBIQdn2IFk9YCR9HgtvTlH EwfJJ/AefDvOuQ0FcUm+ti44EG8PJYln8fYO9wz6R7i1vY6ThsXEX7ooGsyjsAPgY1YA RapRrGTTer2jJ6JrH8HxztMqL85132/x3Uz/h9YOKOc9LAam0ltXXaBBj7U8WPA76kOo yawFvtCzsrvBtslCv6abrS+5XrO327FgremJPL2fuB0n1pXCYA0HqZLf6j0xE/2O4xOy 9kt22zP2Leea4ySPgiH718OWdibTr5eS40pJLEA1Rzech6i+3SbdU0vT+3Yrgzt+iZZn 6LFw== X-Gm-Message-State: AOAM531/ZSzI/0y/2xDeexClBbHz4DShoCZf8LuZ4f4Df8EIV31x9wfE Ym3I41GxMOVns3mqzfNYu0CpgvXX6ZtFVpeNhvVzZhxIlgU= X-Google-Smtp-Source: ABdhPJx8Klb4NHViibztS4LtUi91vZ8VjZIaAiPbf1MnJI4ez3JNieW2qxzrpGM/SKwQXR/IaRLdmm2IoW+BOKKxLRU= X-Received: by 2002:a9d:7497:: with SMTP id t23mr12885648otk.124.1623662962212; Mon, 14 Jun 2021 02:29:22 -0700 (PDT) MIME-Version: 1.0 From: Alex Ernst Date: Mon, 14 Jun 2021 11:29:09 +0200 Message-ID: Subject: FreeBSD PPC64le QEMU To: freebsd-questions@freebsd.org X-Rspamd-Queue-Id: 4G3R3l3wzjz4dC9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=fzJ3/wjP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alexernst19@gmail.com designates 2607:f8b0:4864:20::333 as permitted sender) smtp.mailfrom=alexernst19@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::333:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[4.59.95.194:email,133.3.45.0:email,4.59.95.193:email,4.59.95.195:email,71.40.128.0:email,4.59.95.192:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::333:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::333:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-Mailman-Approved-At: Mon, 14 Jun 2021 12:31:11 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 09:29:24 -0000 I have problems installing FreeBSD PPC64le in QEMU. Tried with the following ISO-images: FreeBSD-13.0-RELEASE-powerpc-powerpc64le-bootonly.iso.xz < https://download.freebsd.org/ftp/releases/powerpc/powerpc64le/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-powerpc-powerpc64le-bootonly.iso.xz > FreeBSD-13.0-RELEASE-powerpc-powerpc64le-disc1.iso.xz < https://download.freebsd.org/ftp/releases/powerpc/powerpc64le/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-powerpc-powerpc64le-disc1.iso.xz > FreeBSD-13.0-RELEASE-powerpc-powerpc64le-dvd1.iso.xz < https://download.freebsd.org/ftp/releases/powerpc/powerpc64le/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-powerpc-powerpc64le-dvd1.iso.xz > $ qemu-system-ppc64 --accel tcg,thread=multi -smp cpus=2 -m size=1024 -cdrom FreeBSD-13.0-RELEASE-powerpc-powerpc64le-disc1.iso -boot order=d -hda FreeBSD-13.0-RELEASE-powerpc64le.qcow2 -net user,hostfwd=tcp::22222-:22 -net nic -nographic -vga none QEMU Starting Build Date = Jul 17 2020 11:15:24 FW Version = git-e18ddad8516ff2cf Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/vty@71000000 Populating /vdevice/nvram@71000001 Populating /vdevice/l-lan@71000002 Populating /vdevice/v-scsi@71000003 SCSI: Looking for devices 8000000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" Populating /pci@800000020000000 No NVRAM common partition, re-initializing... Scanning USB Using default console: /vdevice/vty@71000000 Welcome to Open Firmware Copyright (c) 2004, 2017 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /vdevice/v-scsi@71000003/disk@8200000000000000 ... Successfully loaded Consoles: Open Firmware console FreeBSD/powerpc64le Open Firmware loader, Revision 0.1 Memory: 1048576KB Booted from: /vdevice/v-scsi@71000003/disk@8200000000000000 Loading /boot/defaults/loader.conf don't know how to load module '/boot/kernel/kernel' can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK ls /boot/kernel/kernel /boot/kernel/kernel OK Thank you, Alex From owner-freebsd-questions@freebsd.org Mon Jun 14 13:08:46 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C44BA6413E0 for ; Mon, 14 Jun 2021 13:08:46 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from p-impout006.msg.pkvw.co.charter.net (p-impout006aa.msg.pkvw.co.charter.net [47.43.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3Wws0k37z4tH7 for ; Mon, 14 Jun 2021 13:08:44 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from localhost ([96.28.177.163]) by cmsmtp with ESMTP id smKTlu9RnB5K5smKTllgus; Mon, 14 Jun 2021 13:08:38 +0000 X-Authority-Analysis: v=2.4 cv=ZqIol/3G c=1 sm=1 tr=0 ts=60c754d6 a=xqrt2BZAGHte7XHhrxJgbA==:117 a=xqrt2BZAGHte7XHhrxJgbA==:17 a=HpEJnUlJZJkA:10 a=DBwwDor5xuMA:10 a=EkcXrb_YAAAA:8 a=nC6m0xQHAAAA:8 a=Wxn1ExL5PS-EnFj5g10A:9 a=LK5xJRSDVpKd5WXXoEvA:22 a=gJRmeAjJyBU9q77i_GoH:22 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22 From: "Thomas Mueller" To: freebsd-questions@freebsd.org CC: Harlan Stenn Subject: Re: mlmmj team References: X-CMAE-Envelope: MS4xfHy/YuWwmB2Gmu/HRBCe2IO8deN8OWXrStVq2hy3mCiOzNhQsyn8tiTxRSl8Z1Z+UZnvDkSLhpHXckXlC1gxrMC2YFUPjKbjajhQ5OPpMmF2BnZoH59S iUvwkHWZb5dIGVyB0l8eB9ObYvCHJQmprf3R+cmKFNYjQBVScaEHU6aSuzBw+KAlH6C7SeL4U+8IEDSasJgzVsySqdy60oxpn767R0db/xsOMDb96Nlgq/zp X-Rspamd-Queue-Id: 4G3Wws0k37z4tH7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mueller6722@twc.com designates 47.43.26.137 as permitted sender) smtp.mailfrom=mueller6722@twc.com X-Spamd-Result: default: False [0.21 / 15.00]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[twc.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[twc.com]; MISSING_DATE(1.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; DMARC_NA(0.00)[twc.com]; SPAMHAUS_ZRD(0.00)[47.43.26.137:from:127.0.2.255]; MISSING_MID(2.50)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[47.43.26.137:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions]; RECEIVED_SPAMHAUS_PBL(0.00)[96.28.177.163:received] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 14 Jun 2021 13:08:46 -0000 X-List-Received-Date: Mon, 14 Jun 2021 13:08:46 -0000 > I've got some questions for the folks who are switching the FreeBSD > mailing lists from mm2 to mlmmj. > How can I reach these folks? > Thanks... > Harlan Stenn > http://networktimefoundation.org - be a member! I might also have questions. Reason for the CC is that I have been unable to post any messages to FreeBSD lists. Downloading is OK. Maybe I need to try posting from a different account? Tom From owner-freebsd-questions@freebsd.org Mon Jun 14 14:51:04 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B5C1E6589EB for ; Mon, 14 Jun 2021 14:51:04 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3ZBw1R50z3KYh for ; Mon, 14 Jun 2021 14:51:03 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7A8791430 for ; Mon, 14 Jun 2021 10:42:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 14 Jun 2021 10:42:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=3pS674AmSxrnC1PjoTm2zaAeq91 MkMOAuzochU9MvDw=; b=ZKEPmfyMEP/nWu+Qi+7cGiVvq8qAGGiz+FOQMbKBp1Y DqpwEpX/oLimsko4UHBFYLydhzpDb7YQHO9khA0TPhCBMVtipxvdU8lhp6Z8Q1H4 pLcqmnJklLjE6PjpCgaxJHvztqz5ddQP8wyyzHwj4QAfE7T6zcEdicz6HUD37XKK VmWlvTuJ0MrRXmgcUxCUeO2zH5vLcq0lfmyS98pnoJUQTgIuZOMcNC3xnq6ZJc+o aA//WxVIjag+H2WEvDJeiscQ0V4PUYd5vh5tj/BYu8H40MQziW98wlgTa5jG9kPs MkXdhV6L8JQbLZvP2Yl00qVBbOWb3MePmWuB0DanINA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3pS674 AmSxrnC1PjoTm2zaAeq91MkMOAuzochU9MvDw=; b=EVx2tmghOrCpi4li/iwxO9 OIx14XTz9QxOqXIZ85VpKKFPg/Vl4SmDPkB+/45CJjCzNHUWq9np1l+s7ZzqFMDF QeGd+vW8MNS+IDNY+ndwU8Worx1LV5nTeiUJv0/JtJ03xtpr3pVqF/3XcI+RVMu9 w4t0z3qfOQ9Ti1HvZ2lGap3uvZHy8FB+6Xbjmd3bVRJhvjSkJ4etso5n2VfuGFDA HAelhZAQtjFys1X/ArF1GseTjMA5WY5pbMDWZV7ZdD3tTnPqTQESJbpf3+PO+het 1y4rCV5KtsNAm94jTY2SyicFweGvI2DLTrvQ3xke3G+dZ8E5BKIuwTd9oKwQ2KYQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvhedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeettddtudeugfeggefhkeekteekje elfeffleehjeffgffftdeffedtjeegueeiffenucffohhmrghinhepfhhrvggvsghsugdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe htvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 14 Jun 2021 10:42:12 -0400 (EDT) Date: Mon, 14 Jun 2021 15:42:09 +0100 From: tech-lists To: freebsd-questions@freebsd.org Subject: Re: freebsd tftp server for hetrogenous diskless clients Message-ID: Mail-Followup-To: freebsd-questions@freebsd.org References: <17986d52-bbf3-96a7-e1bb-4ecdee69962c@nber.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pG3BIwHX3XejJ6n4" Content-Disposition: inline In-Reply-To: <17986d52-bbf3-96a7-e1bb-4ecdee69962c@nber.org> X-Rspamd-Queue-Id: 4G3ZBw1R50z3KYh X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=ZKEPmfyM; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=EVx2tmgh; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-5.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[64.147.123.25:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MAILMAN_DEST(0.00)[freebsd-questions]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 14:51:04 -0000 --pG3BIwHX3XejJ6n4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 13, 2021 at 12:02:49PM -0400, Daniel Feenberg wrote: >We have more than 30 Linux clients PXE booting from a FreeBSD server. This >is not a network install, /bin /sbin etc are NFS mounts. > >We have been doing this for many years, currently the Linux clients are >all CentOS, they have been Ubuntu at times in the past. Both FreeBSD and >Linux have been kept up to current supported releases. > >We like PXE booting with system files on read-only server because it makes >updates quick and easy, ensures uniformity across clients and is in >general convenient. We don't do it to save disk space. Network bandwidth >is not really a problem - 1GBE is fine for this, although we upgraded to >10GBE some years ago because the applications do a lot of network I/O. If >you lose the network connection the client will hang till the network is >restored, and jobs will continue from where they left off. Hi Daniel, Thanks for confirming this. Can you recommend any guides/how-tos as https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-dis= kless and man 8 diskless seem to only address freebsd clients and servers? I'm looking for an example with say ubuntu as client. or briefly describe how= =20 you did it? The clients need to always get the same IP address. I guess this would be tied to the MAC in some way. One issue is that there is already a dhcp server active on the router. If the freebsd tftp/pxe/nfs server is another dhcp server on the same network, they'll clash. How can this be avoided? thanks, --=20 J. --pG3BIwHX3XejJ6n4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmDHarcACgkQs8o7QhFz NAVxPw/+MUs0iuiC8Q8mYFVKKhC2vD5MBIljnBf1xGLvXHmdaSm6cxUUyt0OmMqF HFTPbfNkwFz0dvuCmGGQPodXII/OkaTtbbZ9J8rpnF48Gt/nn9JjNgNxtVyJVCnr ciEn2QbmDnSmlzr5+G0jZPRCNBrqZuvleWuPgmUfEIWL/sjUFZ0OCPr2OskQsOGw bDnssHWAuB+jPlzYkL51TLvrnp1VF3F6F+WkYEoFd78OzSYYZSMbGSsBltZ7IEUo cyBk94NdgLeKPyviid17VU1IMW2LIlVpkuPQIfRZldhRLwLZCzhqGe2WrD8YVLcC 9wVwaDbVTHk+JmduDDvwSWCpa2WMBesyXL9ZLsX83DlndgwhxFK3j7ZmxnfQkHMo dT7COCKSaoBO82GuDA3tKOw2KlT+C0l2qamRGfEpSvP9SmmB8r9zoKJu9xkqSYXZ 0eYmPKtOMqXLOBImSHLHKBfvecuezckrbBf/0de1zQE7leYoR2Np6jt1Dfcv3TCg g2qyUXfUJTv6EkUENsj1N4lJrA4Klfp4DwMmNs4rWXohue/ZP/LQ14mOp5ycS5v4 ka/mL8Z6LdLsZ+4cDnpVcXF0gBaJMggUrxD0qMK1T6TTp0SJzkG7ypFIgqb5ITvI nnnR8g5d/FfpcD3/iNnFpjKw4fFYhsAg4BdhQTgKeeii7NsolCc= =JJI5 -----END PGP SIGNATURE----- --pG3BIwHX3XejJ6n4-- From owner-freebsd-questions@freebsd.org Mon Jun 14 15:40:57 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 78F686445D2 for ; Mon, 14 Jun 2021 15:40:57 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3bJS2xHhz3QCp for ; Mon, 14 Jun 2021 15:40:56 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from smtpclient.apple (unknown [73.99.214.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 130F8262; Mon, 14 Jun 2021 11:40:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: freebsd-questions Digest, Vol 888, Issue 1 From: Paul Mather In-Reply-To: Date: Mon, 14 Jun 2021 11:40:49 -0400 Cc: Victor Sudakov , Steve O'Hara-Smith Content-Transfer-Encoding: quoted-printable Message-Id: <9EE124D9-9210-4CBE-8DAE-99BED61768C2@gromit.dlib.vt.edu> References: To: freebsd-questions@freebsd.org X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G3bJS2xHhz3QCp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-2.43 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[paul]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[128.173.49.70:from:127.0.2.255]; RECEIVED_SPAMHAUS_PBL(0.00)[73.99.214.146:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[128.173.49.70:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.934]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 15:40:57 -0000 On Sun, 13 Jun 2021 22:47:23 +0700, Victor Sudakov = wrote: > Steve O'Hara-Smith wrote: >> On Thu, 10 Jun 2021 12:35:44 +0700 >> Victor Sudakov wrote: >>=20 >>> bhyve !=3D Docker. These are different technologies. >>> The Linux equivalent of bhyve is kvm. >>>=20 >>> The closest equivalent to Docker is jail, but jail lacks all the >>=20 >> Nope jail is the equivalent of LXC (containers) on Linux, a = layer >> below Docker. >=20 > Dunno, https://en.wikipedia.org/wiki/List_of_Linux_containers lists > Docker and LXC as different container technologies. Maybe Wikipedia is > incorrect about it. IMHO, FreeBSD Jails are more closely analogous to LXD = (https://linuxcontainers.org/lxd/) in Linux than they are to Docker or = LXC. (But, you could mimic jails using LXC or Docker.) Somewhat = confusingly, the LXD binary used to interact with LXD "jails" is called = "lxc". :-) (LXD is built atop Linux's LXC.) Cheers, Paul.= From owner-freebsd-questions@freebsd.org Mon Jun 14 15:56:46 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B4CA36486D6 for ; Mon, 14 Jun 2021 15:56:46 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [198.71.6.79]) by mx1.freebsd.org (Postfix) with ESMTP id 4G3bfj6h7mz3RC0 for ; Mon, 14 Jun 2021 15:56:45 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [198.71.6.79]) by mail2.nber.org (8.16.1/8.15.2) with ESMTPS id 15EFuhn4088401 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 14 Jun 2021 11:56:43 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Mon, 14 Jun 2021 11:56:43 -0400 (EDT) From: Daniel Feenberg To: tech-lists cc: freebsd-questions@freebsd.org Subject: Re: freebsd tftp server for hetrogenous diskless clients In-Reply-To: Message-ID: <1974b6ed-f026-b857-cf82-f53ef5f0b0e9@nber.org> References: <17986d52-bbf3-96a7-e1bb-4ecdee69962c@nber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiSpam-Interceptor-Info: not scanned X-KLMS-AntiPhishing: Clean, 1970/01/01 00:00:00 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2021/06/14 08:42:00 #12240495 X-KLMS-AntiVirus-Status: Clean, skipped X-Rspamd-Queue-Id: 4G3bfj6h7mz3RC0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of feenberg@nber.org designates 198.71.6.79 as permitted sender) smtp.mailfrom=feenberg@nber.org X-Spamd-Result: default: False [-3.50 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nber.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[198.71.6.79:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:26287, ipnet:198.71.6.0/23, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions]; RWL_MAILSPIKE_POSSIBLE(0.00)[198.71.6.79:from] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 15:56:46 -0000 On Mon, 14 Jun 2021, tech-lists wrote: > On Sun, Jun 13, 2021 at 12:02:49PM -0400, Daniel Feenberg wrote: > >> We have more than 30 Linux clients PXE booting from a FreeBSD server. This >> is not a network install, /bin /sbin etc are NFS mounts. >> ... > > Hi Daniel, > > Thanks for confirming this. Can you recommend any guides/how-tos as > https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-diskless I wrote up diskless booting of freebsd clients, but someone else here handled booting Linux clients, and hasn't documented the procedure. There are some web postings that seem to address this, such as: https://help.ubuntu.com/community/DisklessUbuntuHowto I am pretty sure that the Linux client won't care that the DHCP server is FreeBSD. I know the freebsd dhcp serve won't care that the files are Linux. ... > One issue is that there is already a dhcp server active on the router. > If the freebsd tftp/pxe/nfs server is another dhcp server on the same > network, they'll clash. How can this be avoided? Put the Linux configuration information in the FreeBSD DHCP server. That information is only the "next-server" for tftp loading pxelinux. Any DHCP server can offer that. For years we had the kernel and root filesystem on a propietary NetApp fileserver, now it is on a FreeNAS server - the clients don't care. If for some reason you don't have control of the DHCP server, that would be a problem. If you can turn it off, then run your own. If you can restrict the MAC addresses it responds to, you could do that and run a separate DHCP server for your diskless client. But we boot freebsd and linux clients off the same dhcp server, just with different Daniel Feenberg > > thanks, > -- > J. > From owner-freebsd-questions@freebsd.org Mon Jun 14 19:09:22 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF19C649AF1 for ; Mon, 14 Jun 2021 19:09:22 +0000 (UTC) (envelope-from johnl@iecc.com) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gal.iecc.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3gwx6Svgz4Z2C for ; Mon, 14 Jun 2021 19:09:21 +0000 (UTC) (envelope-from johnl@iecc.com) Received: (qmail 50771 invoked from network); 14 Jun 2021 19:09:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c64d.60c7a960.k2106; bh=Q1O2Uh4+M9z0Y7PpkUBJg9zBbNcR2NefC4uF3B4pMCw=; b=rKCa7vtny8xPwl8/bJ0AnASq+owU8LV7Re5cYmKzPyiJhP7fvM+90H+IoQMYyep2MQ7QbXjEs/hEOEIGUwUaDRqmsJcn94z7U0pLtSfK4Jf8ieQjoXLX8SMzRONexpEvwosiT2Ar7X/2tvFq3aMilIiWgOswgSlP269/UP+jxcZIoPNHY+7pH+h2XinqW4c8xEojfKiYIB2O9Roqr6u/gqp4hhTiqtZm26bBP9GrMUMV2UxBN5rgbySF9RoHKMXIg6YqMHzPsGYOQBUub+HBB3SRFm+Bol6B1ujEXU0wxM/zmRwtCrnuBKMGrpnZ/JbxSw3z3mN31D4oyzT6YgJ74A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Jun 2021 19:09:20 -0000 Received: by ary.qy (Postfix, from userid 501) id 165D610C902F; Mon, 14 Jun 2021 15:09:17 -0400 (EDT) Date: 14 Jun 2021 15:09:17 -0400 Message-Id: <20210614190918.165D610C902F@ary.qy> From: "John Levine" To: freebsd-questions@freebsd.org Cc: rfg@tristatelogic.com Subject: Re: Periodic tasks are not nice In-Reply-To: <26813.1623665962@segfault.tristatelogic.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit X-Rspamd-Queue-Id: 4G3gwx6Svgz4Z2C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=iecc.com header.s=c64d.60c7a960.k2106 header.b=rKCa7vtn; dmarc=pass (policy=none) header.from=iecc.com; spf=pass (mx1.freebsd.org: domain of johnl@iecc.com designates 2001:470:1f07:1126:0:43:6f73:7461 as permitted sender) smtp.mailfrom=johnl@iecc.com X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f07:1126::/64]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[2001:470:1f07:1126:0:43:6f73:7461:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[iecc.com:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2001:470:1f07:1126:0:43:6f73:7461:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[iecc.com:s=c64d.60c7a960.k2106]; DMARC_POLICY_ALLOW(-0.50)[iecc.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:1f07:1126:0:43:6f73:7461:from]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 19:09:22 -0000 It appears that Ronald F. Guilmette said: >Shouldn't all these sorts of background taks be nice'd? Maybe. My not very new server has 12 CPUs (six on each chip) so there is always an available CPU so the speed limit is the disk, not the processor. Nice only affects CPU scheduling. From owner-freebsd-questions@freebsd.org Mon Jun 14 20:49:14 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8FD69651FC6 for ; Mon, 14 Jun 2021 20:49:14 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G3k893VHnz4qfL for ; Mon, 14 Jun 2021 20:49:13 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id A68B34E657; Mon, 14 Jun 2021 13:49:11 -0700 (PDT) From: "Ronald F. Guilmette" To: "John Levine" cc: freebsd-questions@freebsd.org Subject: Re: Periodic tasks are not nice In-Reply-To: <20210614190918.165D610C902F@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3359.1623703751.1@segfault.tristatelogic.com> Date: Mon, 14 Jun 2021 13:49:11 -0700 Message-ID: <3360.1623703751@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G3k893VHnz4qfL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-3.28 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 20:49:14 -0000 In message <20210614190918.165D610C902F@ary.qy>, you wrote: >It appears that Ronald F. Guilmette said: >>Shouldn't all these sorts of background taks be nice'd? > >Maybe. My not very new server has 12 CPUs (six on each chip) so there >is always an available CPU so the speed limit is the disk, not the >processor. Nice only affects CPU scheduling. Hummm... OK. But on the other hand, if a given process is starved of CPU, then it will naturally be less able to suck up all of the available actuator movements of the spinning rust disks that I am still cheap enough to own, yes? Regards, rfg From owner-freebsd-questions@freebsd.org Mon Jun 14 21:29:58 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4BD8B65482E for ; Mon, 14 Jun 2021 21:29:58 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3l3948v4z3Fqv for ; Mon, 14 Jun 2021 21:29:57 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id f17so12909185wmf.2 for ; Mon, 14 Jun 2021 14:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=xva5NqqOuSu10lg8hnW+rM2r/16V7nuiya/ioV31lIk=; b=a4/nG1b6ygR5Y5xkYVgeDc0wkGuMH5wUbcdzun9dO1QjeCo7/H3RDAa6lfd8gyNcc+ FEbPdG7jbLzYeOYNUw+nof0eUfs9ZQpvXpQnUubWIqB509epXlqp1L2FJeHUKuNDli11 iguNUJV3Mo9tXZX+4kfhXvHXwqEHodYPRWDVt2h665j0D37MZIkCBZkCwNH7tTmFuKQd RFU4+FbAxthZncHtKrDl8CH/mVdxFzK/8bsQlqdYuunRjcA5X+qG+ZpLNc5TJT35flJz eoWCGjoETzt4+xZAO660xEGHG9bryUkUPUuWi9GmX5CKN07l7V8V+htKlNbPNjlkC2cF UQ4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=xva5NqqOuSu10lg8hnW+rM2r/16V7nuiya/ioV31lIk=; b=drzUPd441cRR00n97jtiobTxYjNnv6FXcBnFwCXeI4lYmu/xWt0DBXuItAf9C3sfQF +a/qohVpCC793xl40nxowi+9F8xnVt9ykP/7JI+tG4xPPeKOGw1SetnuPV2YALjVpI2a nbIiWx0yf7DvFqshtO7JPXgFOnyGKDAT57y4/yGADC1hwIcPHKF/8Og1QthpqQBjwq4c PKpoKrdgB8Fb8oSncARp228/i4ic3i5nCB+qk+rDASqpREJ61qbIKGAR9OqJL77gTDm9 yqvRM6/tIC6OOMecOCPjb00mFtGuGBqjvqdpko+oLqkpQTtjhdzkf6BirrKJ5UtuPXHb DMBw== X-Gm-Message-State: AOAM531w21iASr7fdtRg27lYXdQT0ObYGkyJ6BepIhEnhk7tlHxvspIC aNTCL/+jbTjYVReYR5JuMhlQuStdRXIisQ== X-Google-Smtp-Source: ABdhPJyhW/hL6Q9KrrbzZgQzBwXJyFXy4vQ2aGaSGIzuJ/LY9iT0DKjCKcal4WIx5bd5PHYzx0LRYw== X-Received: by 2002:a1c:67c3:: with SMTP id b186mr19101167wmc.12.1623706195601; Mon, 14 Jun 2021 14:29:55 -0700 (PDT) Received: from [192.168.1.10] (88-105-96-80.dynamic.dsl.as9105.com. [88.105.96.80]) by smtp.gmail.com with ESMTPSA id n13sm19190552wrg.75.2021.06.14.14.29.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jun 2021 14:29:54 -0700 (PDT) Subject: Re: mlmmj team To: freebsd-questions@freebsd.org References: From: Graham Perrin Message-ID: <80744520-1f98-a1f2-62ec-5c5fbff638f1@gmail.com> Date: Mon, 14 Jun 2021 22:29:53 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 4G3l3948v4z3Fqv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=a4/nG1b6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::334 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::334:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[88.105.96.80:received]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::334:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::334:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 21:29:58 -0000 On 14/06/2021 09:39, Harlan Stenn wrote: > Hi, > > I've got some questions for the folks who are switching the FreeBSD > mailing lists from mm2 to mlmmj. > > How can I reach these folks? > > Thanks... I guess, postmaster. Certainly, the address receives attention in the context of Bugzilla. From owner-freebsd-questions@freebsd.org Mon Jun 14 22:37:08 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 49CDD656F5E for ; Mon, 14 Jun 2021 22:37:08 +0000 (UTC) (envelope-from Norman.Gray@glasgow.ac.uk) Received: from hillend.cent.gla.ac.uk (hillend.cent.gla.ac.uk [130.209.16.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3mXf4xpzz3Mxs for ; Mon, 14 Jun 2021 22:37:06 +0000 (UTC) (envelope-from Norman.Gray@glasgow.ac.uk) Received: from cas08.campus.gla.ac.uk ([130.209.14.165]) by hillend.cent.gla.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1lsvCZ-0000qq-NN; Mon, 14 Jun 2021 23:37:03 +0100 Received: from CMS09-02.campus.gla.ac.uk (172.20.14.170) by cas08.campus.gla.ac.uk (130.209.14.165) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Jun 2021 23:37:02 +0100 Received: from cas07.campus.gla.ac.uk (130.209.14.164) by cms09-02.campus.gla.ac.uk (172.20.14.170) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Jun 2021 23:37:02 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.54) by cas07.campus.gla.ac.uk (130.209.14.164) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 14 Jun 2021 23:37:02 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NIcY0c3yT/YpjCHX1hWUg89fccQxKKJpFTJG7475nWIrxEmpEfiHkItEGdpB7+crPfSt+jszTOdGxDy1TGuapMtH/jpVHpXhohQCMzUG3RyQ5x6eEALeguHEJeDzfVcvPMh+6jpt90IqTXufhT2u6qoGotaCjvQlZNFCBhp7ofnlENuyoPrnG7IoIPeFWGgkPkmxDuAmHVrLa+JiEHzbG/ovGPlBZG323Vcq8K0XxAluLj2l90Jzh6ZLEOizO9W/pUwL/SEsB4wl6crFpKih++3+A7D9zbvD/kTLA2vyjrMK1fJExEREEf+R0AvWwIWLP1SQUMPK9yQmOza2vRTXLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VqvFwl9NbSQW09EqT+RBINHbVvUP5LnrEBHEpNd/H08=; b=jO/WPhbFWV4+ujL2t0HA5IkU58OOy5qvut+vKKH11WQQVQoqVc6j+AJNtx1iQzDAEYHWEjqsZoRCgOsgHAo+MeydjSV9mlkTGujJ1NxsCD19mGQmYnKF/NhQlZb+jx4xh+FAoxJz1TN6eBX6Sk5vnaNJriCxQzEwriTJ3blUT0k5qT+l00HF1tpd8E3ipfVwkWoJKmuJkCRdGnT5ilbbeOBFynUey13Mrxm1LIJ4mUlYdkqs+cpmhb76mvFFLALY6EZ+XcBBx3aDzDIcA3PH5QT88Rr4vmBguWFzr5WK4q7x7JERdf2d6zZa1qzXJXiIxF+fhcvZ3Cdl2LD7wFrECA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=glasgow.ac.uk; dmarc=pass action=none header.from=glasgow.ac.uk; dkim=pass header.d=glasgow.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gla.onmicrosoft.com; s=selector2-gla-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VqvFwl9NbSQW09EqT+RBINHbVvUP5LnrEBHEpNd/H08=; b=n2MJ2HkJt0dW5Tqp5ZDqAsY7kAstfVcxcKSKSwwmW+Up2NAKiahY381F8UWh2c4tPnzYnaAi0ewdZRfDTYBvWD4xfmB7bZKBFvGJkekix/rXz+f0hcB3LvqgQU5YlCaO2ihY3OtviOVJ1RqfCcxj8vzORGzxUiJ9A0Beg2J0/W0= Received: from CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:d4::7) by CWXP265MB4023.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:122::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.23; Mon, 14 Jun 2021 22:37:02 +0000 Received: from CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM ([fe80::977:cd20:64d7:e0bf]) by CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM ([fe80::977:cd20:64d7:e0bf%4]) with mapi id 15.20.4219.025; Mon, 14 Jun 2021 22:37:02 +0000 From: Norman Gray To: "Ronald F. Guilmette" CC: John Levine , Subject: Re: Periodic tasks are not nice Date: Mon, 14 Jun 2021 23:37:00 +0100 X-Mailer: MailMate (1.14r5769) Message-ID: In-Reply-To: <3360.1623703751@segfault.tristatelogic.com> References: <3360.1623703751@segfault.tristatelogic.com> Content-Type: text/plain; format=flowed X-Originating-IP: [2001:8b0:df5:af53:2c1b:f35f:c01a:bdea] X-ClientProxiedBy: LO4P123CA0278.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:195::13) To CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:d4::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.10] (2001:8b0:df5:af53:2c1b:f35f:c01a:bdea) by LO4P123CA0278.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:195::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.20 via Frontend Transport; Mon, 14 Jun 2021 22:37:01 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0123742a-efc5-4345-0a18-08d92f84ed8f X-MS-TrafficTypeDiagnostic: CWXP265MB4023: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2043; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NC0dSqGwlUIvmEZYv9vxO/lGkg1gMZ4ZNzABO6h3KJpQZlxQ4K0/th5+bAJqo0px6XuC0C7Y1G81fNpcPA+kTeK7wBnUU2+7+Z3DAhEOFtv4PePrW2FxeQMlLiwp/hlMs+dU1TDhHlWs/pH6vQJzBMndVe7aIU+NODQcYMtFbqvwM2EPcWwd8WPWhPI3CHOS5oqg6axPabRSnFABUAdBDtt2a0OP/ZxNcrA7qADrpVE1kq147RfeuxmBd2fBcPAyg9qe2pIIUS/fzYSD01iKhco3cwo3I9+IeOldLESZHWkJ8P94N9NNd+WY6shfA1lIeSlAFAIcaZJsOe2LLYYCh9ilUbYo03Lkl1pKY/GsV5QaQipaNhntvRlR+TFG/VOU2sgj/3OWiQ/j64abV6ErInPdFur4gB3LI6XmHKAzs75ybfilfd3vkhVb95QOJpaDDMlEFAGBd3D+CtypY9DS/INameGaMPRl5RKQhiLUcEwuPzT2awL4oxa9MpXRQtWm9zisPcRv+aazlpaUYnihx0qfJUpVxiW0Pv1oXqCS4RKAdBoqXAluQrkPjC+GDGkzmv6LtK9oh38h/xmJvGRBaKwa5bGNralcuMet8tnIpXnOZtkEH7fXWZTC9z2kQ3HD8AYqU9/D9SPZhIZVDoLLNoLeD5NzBLBKV4ZpN1fhB0HihEPKDBNpo3G640uCrXsC4SlLRgN+ajTJeI4b/IEHiYxEcx7cNgHCq7kYMrtIu2T6sHpdeZVWe0zMl6IX7PC3rha72jM9c4rNyIUKPJX7vA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(396003)(136003)(366004)(186003)(16526019)(36756003)(44832011)(6486002)(316002)(5660300002)(478600001)(66946007)(83380400001)(66476007)(66556008)(33656002)(4326008)(53546011)(966005)(86362001)(8936002)(38100700002)(2616005)(786003)(6916009)(8676002)(2906002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?GEAxTzpsGASgEXYdpawVzKEBz1EMfK7zUWYJIDvqgzLNCu0sLBgjTbZdF6gv?= =?us-ascii?Q?WfXeJCuPaaxDm0mNFzlO99NRqLxpmrrxM6VqyEac5qkPwniGLIBhv4HVMSuY?= =?us-ascii?Q?6FUMFQcf5CuC/Nty+qQG4iACoAOY2EqTKZLn2uWQ3M/8CAiyd8iTF2KR+vG9?= =?us-ascii?Q?Ck/gNuno1l3cjGNXfZQ/pQbI0IX0EVgyhUZi9Wemp+CHMsMwK8a4AZd7QqoL?= =?us-ascii?Q?1UAPrHAYaMooKB9C2qVn6XAhY20ycvXZz/c67auVeZkzzPWGVgor5+RvOLUO?= =?us-ascii?Q?OuRdeQdSxUEW+mHefVImYld3nBcWaJJ1s36v/Uk/YWLCgZYoHGXjQ3ggwVT/?= =?us-ascii?Q?mNa2zlTTMJezdNtew7L+Y0UrJxyBpfsnQzAFn+sHSyqFzvOCQw0mAuvKhQvs?= =?us-ascii?Q?ZMn7I2YfiRvAQj+aq+apudMDNIxWAJGaey53myCzaueQkJD+wYHrqPO/ZO3l?= =?us-ascii?Q?Dde3HEysWNyW2+BySXOlWokJU8FEd9oYDJAgTS4xd0xWcLFGveYCumUBYPNv?= =?us-ascii?Q?wm4yXYNuga3pP9gBQr5SrFHR8RMEkeXVPtLHghLsuKAXCyNbKBQw99tqqNsc?= =?us-ascii?Q?4Qvjm2SumA2OFHP1lOwKHiTmEv9rcFoTakbw7V5BNmY7hJGVmXYlvzglcJuk?= =?us-ascii?Q?u6BMXcjglc9Ds4gBLOBSfR9+UJ6BQAtcXkpabgjhPSbccuXBSu9nNyrFqV0F?= =?us-ascii?Q?lQoOPdIk6FEDAU0kpvfTazC857KCdMWRRz3EpFLH1KcMGmxglWza6pqso288?= =?us-ascii?Q?AniAIPfI9Yc5yPcW0mKl6kQxBc219fP/LQj/9ueTwW/c0lcPX9q2Y8gA5g6V?= =?us-ascii?Q?kKOC7WZpZjwKxl6G8uPKke99Zq+ue44wB9iKHjv0hYqPm/OxiktREfI0axyO?= =?us-ascii?Q?0VVlHMXYPIWDbJFLZeqRG1XpVlejoc+XR4w5NaL4kpChiqGgQkpOsXVlvbSr?= =?us-ascii?Q?vSujGVpq7n8qnj5CdtzFwixTpkcLlr3yhwIY9TQZvlV7AQCCN3wOBsshVJUU?= =?us-ascii?Q?liT2brMFcV6jKegDn6OcRY14MWOPc2NvnG43Kntw/Lij7USIlcrvrR2wGLm9?= =?us-ascii?Q?YrR6VVzux+jvDSRA9qkaJ9SmNChhsQeyTQ3pwtqkICj7JBcuOfUrSZMUP5M0?= =?us-ascii?Q?LAouxTBrVlYMxB+8Ov+bIpHhvO/Ny6bG7SopnIhKng4xI5avAn6uCJhfJKpQ?= =?us-ascii?Q?rUSTg58M2kvRc8ayBOyNvo4W3MvFU93i6ViIguOpZYhPpmfn8Yr0Bqjj5se0?= =?us-ascii?Q?qhlEmdiLzbd85/NIlGO2E/r/g/LapBTN9QHG4D0CJF6Kksp/+NTcVpR2CQ1G?= =?us-ascii?Q?8tFzPD3IQYjI0PupVX6O7Hi8X8NSmJUm3wNPaf1aX3DFqrl2SaEYaTA9Tzqf?= =?us-ascii?Q?jjSt0DG/5RbIuTz5HEVmVZo5Zbmb?= X-MS-Exchange-CrossTenant-Network-Message-Id: 0123742a-efc5-4345-0a18-08d92f84ed8f X-MS-Exchange-CrossTenant-AuthSource: CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jun 2021 22:37:02.1749 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6e725c29-763a-4f50-81f2-2e254f0133c8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: l6kwJwaqahOAdIYVlhzA9lS9+LKvS468Ad3rXuFRIrQH/LenSVKs7JvfC+W1IgqpGbkkIGYjq+12abD89CkaRfHtgIs8eqEJC/9JGDvtue0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP265MB4023 X-OriginatorOrg: glasgow.ac.uk X-Rspamd-Queue-Id: 4G3mXf4xpzz3Mxs X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gla.onmicrosoft.com header.s=selector2-gla-onmicrosoft-com header.b=n2MJ2HkJ; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=none; spf=pass (mx1.freebsd.org: domain of Norman.Gray@glasgow.ac.uk designates 130.209.16.102 as permitted sender) smtp.mailfrom=Norman.Gray@glasgow.ac.uk X-Spamd-Result: default: False [-5.20 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gla.onmicrosoft.com:s=selector2-gla-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:130.209.0.0/16]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[glasgow.ac.uk]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[130.209.16.102:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[130.209.16.102:from]; DKIM_TRACE(0.00)[gla.onmicrosoft.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:786, ipnet:130.209.0.0/16, country:GB]; RCVD_COUNT_SEVEN(0.00)[8]; MAILMAN_DEST(0.00)[freebsd-questions]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 22:37:08 -0000 Ronald, hello. On 14 Jun 2021, at 21:49, Ronald F. Guilmette wrote: > But on the other hand, if a given process is starved of CPU, then it > will naturally be less able to suck up all of the available actuator > movements of the spinning rust disks that I am still cheap enough to > own, yes? For me, the aha! here is that nice doesn't artificially starve a process of CPU, it merely puts it to the back of the queue when the kernel is scheduling it. That means that _if_ there is a shortage of CPU, then the process will not be given a turn on the CPU very often (depending on the value of the niceness). If, on the other hand, there are two (single-threaded) processes running, A and B, with only the second one niced, and two CPUs, then there is _no_ shortage of CPU. Thus B can be given the second CPU to play with, without disrupting A. Both CPUs will be fully utilised, and the CPU scheduling queue will be empty most of the time. If A were multi-threaded, then it would be possible for the kernel to schedule it on both CPUs. In that case, the kernel would do so more often for A than for B, and B would be starved. Returning to the case where A is single threaded, consider the case where B, again making full use of a CPU, is doing something which is thrashing the disk. This time, the kernel will spend more time servicing process B and its disk accesses, so A will end up waiting in a queue for disk access, and so be slowed down by B, even though it's B that's niced. (I'm sure no-one will hold back from correcting me if I've misunderstood something, or skipped a subtlety). Best wishes, Norman -- Norman Gray : http://www.astro.gla.ac.uk/users/norman/it/ Research IT Coordinator SUPA School of Physics and Astronomy, University of Glasgow, UK Charity number SC004401 From owner-freebsd-questions@freebsd.org Mon Jun 14 21:10:34 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2ADCC653B4A for ; Mon, 14 Jun 2021 21:10:34 +0000 (UTC) (envelope-from mirror176@hotmail.com) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10olkn2053.outbound.protection.outlook.com [40.92.42.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3kcn0NBsz3Cgg for ; Mon, 14 Jun 2021 21:10:32 +0000 (UTC) (envelope-from mirror176@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=od3pLWRi+QjkFH7atI2DKAac3KgyVowVNoEEg5ugKs+xM4Yko5c7/yl9S2XPOInCa7TgX46BQhBKc47JkSDZ4QmLF3Sgpm+kfT68nEeYGB6w58EF7VHhznXKZ0D91sSs/iyNkxTQcQfh1omaKPRVbmstD2/M0IbgKD8fbeYOoUT1rIk9Zvd3jebHmPLfG7P5ij/VX0R5LN2UJIT4Vb1GMHRIOxaOSZDIYOWfG9EidTQu3rMesAlTCR/P+EcXuXNjVJgluXadWZ2FO0lvP/To/HgJP6rhILK57N/oNEqZmlv4uMeaxRmuH1whwkhhDtakWDH/+pP5ui9Va0HXGILVQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bP7oYiKZcNyVx+sTD6WpxCFNTXUme+J0QOWN2/o0uGM=; b=CwyCsZXPOVeqE6eVYthSbRRkD0etkr5Lc1GhVpHZxcel4lqiq/mOrHWV5EU/HHW+ZyY0yhe1VbOEKNefRIdgEQ3dQ99Ul3kkF8HSxAKKWlOZZ4aP7mgg5NU8PvmSjGA9h+w29fuSnhH+m+JMc9N5yBr72qi9/Sjbw0RlMBcQGDuW8qhI0h2w7i9ToytlPjfFVhmsH+07rP+bOHkPrycWmwsn32p5p/Wie/pZFCmQXXKa4IZJB/p+PSPJalvR/jUOHVXjeEZzmeDL8ILLYQGE4ZTkeG7ENJJpC41TB0XcJkcrNCqY3q8asT2OFYW1qwry0T0IliT48corbPjwFCl9kQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bP7oYiKZcNyVx+sTD6WpxCFNTXUme+J0QOWN2/o0uGM=; b=SGQPKJbkF7d7d7czTqA0JWRn+uHNtGWWKCkPrffrwvYtzMtUsfCgEt9fpIA/Omvm9QmfJICrOFXKoq/E04EtfIkLLjkI7gHsUT0G7mjzGVo+WTqYpkGpWHVwWVweiLdP8C+oPoCJCopMIi1BXJZF+PQWb1yxpr8KJCb0SoEH9Gzf10lnwYqlHi32b1uGrqi8wMn4MowDgGw1V+m4xSVhTTa3ahs+wJQ2GF4IpGajQr9WlSYXD4bjbht1BflYJtKXsI2/l+rCqUlnAA/BfUBULNALx8t+uVzregJXDgU65hwpNbK/UPvskGtZLXBnTdLoyZVxjGmWVhfbxnpWSicuUQ== Received: from DM6NAM10FT033.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e86::50) by DM6NAM10HT129.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e86::219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.18; Mon, 14 Jun 2021 21:10:31 +0000 Received: from DM6PR03MB3674.namprd03.prod.outlook.com (2a01:111:e400:7e86::43) by DM6NAM10FT033.mail.protection.outlook.com (2a01:111:e400:7e86::148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.18 via Frontend Transport; Mon, 14 Jun 2021 21:10:31 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:839F364763A760D0D8ED94E9F4A466F0CC6EFBDDF02F896B8F5CDA22A9D6A6E7; UpperCasedChecksum:147D51C92142DA159F585B2C26B1CCCD9EE6882B13E59EB36F1391A79A4B63BC; SizeAsReceived:8541; Count:43 Received: from DM6PR03MB3674.namprd03.prod.outlook.com ([fe80::bcaf:331f:88da:3b9b]) by DM6PR03MB3674.namprd03.prod.outlook.com ([fe80::bcaf:331f:88da:3b9b%7]) with mapi id 15.20.4219.025; Mon, 14 Jun 2021 21:10:31 +0000 To: freebsd-questions@freebsd.org From: "Edward Sanford Sutton, III" Subject: Why doesn't cc -ansi disable conflicting type for getline from stdio.h? Message-ID: Date: Mon, 14 Jun 2021 14:10:28 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LGwTt1xj1LKnYCBVxoiegy1f8qZiYRC1p" X-TMN: [vTU0/1HatVBbHv7LJxZsN2LV/R5mAxUN] X-ClientProxiedBy: SJ0PR05CA0019.namprd05.prod.outlook.com (2603:10b6:a03:33b::24) To DM6PR03MB3674.namprd03.prod.outlook.com (2603:10b6:5:aa::16) X-Microsoft-Original-Message-ID: <9d793a27-659e-7b0a-ad9e-6eee34c2dc62@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from darkstar.l.net (70.162.106.2) by SJ0PR05CA0019.namprd05.prod.outlook.com (2603:10b6:a03:33b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.9 via Frontend Transport; Mon, 14 Jun 2021 21:10:30 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 43 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 8bc2f805-323d-4eaf-ac0c-08d92f78d786 X-MS-TrafficTypeDiagnostic: DM6NAM10HT129: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5X8zA4WSDbDrGhfPHfjwRcucbH2+vQSCmckNBQ/SYBmrvBCjDpBzAfg9PThVx/5vzls5CINsgjA7d8JqsoguSs3UR48LOzuOkjKAnuaQEObgkUJ9yFEiNM62AOra5r1ZqMwxgBjlMc7pyJB/dMPmC/YBmiNReE2xY0/kAsSEe3LzX2FIf4aY/qHnfxGvAzd0sXXFld5+FvtbabIGRDFzrX03HmhHcmiKvmuc2y+7K7UKAxzpQeNNGiJX1j0W47BaRUTDjppB4HLhvpNRoga9bZ92lwy1pleChIqvDcPrG5jZ5gUFE/qQAB2vZwh21Y/d/u4W9oYKU2QFhRzllIwxs3O6l/OZO5s7iB5ErBP5cAoDHLdVmkJNK/fHOQNRSN9QY77IxqDS0yCb7hbMCrbs4A== X-MS-Exchange-AntiSpam-MessageData: rouNtnpX1LlB3ZpwI4lSEm3mplQqu+31sJhUEWzIoApS5/g4oKIDrbsdM19sLKSheFVkPbnvgulXIFsJ9buXsRuh874u42MjhgTWc3pNuPnm7z8Bc3hGs9C8xWl2jRQ6kRqfo278lRE6+ApgMQ5KHQ== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bc2f805-323d-4eaf-ac0c-08d92f78d786 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jun 2021 21:10:31.1242 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DM6NAM10FT033.eop-nam10.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM10HT129 X-Rspamd-Queue-Id: 4G3kcn0NBsz3Cgg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=SGQPKJbk; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=hotmail.com; spf=pass (mx1.freebsd.org: domain of mirror176@hotmail.com designates 40.92.42.53 as permitted sender) smtp.mailfrom=mirror176@hotmail.com X-Spamd-Result: default: False [-3.60 / 15.00]; FREEMAIL_FROM(0.00)[hotmail.com]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[hotmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.92.42.53:from]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[40.92.42.53:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[40.92.42.53:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.42.53:from]; MAILMAN_DEST(0.00)[freebsd-questions] X-Mailman-Approved-At: Tue, 15 Jun 2021 05:23:49 +0000 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 21:10:34 -0000 --LGwTt1xj1LKnYCBVxoiegy1f8qZiYRC1p Content-Type: multipart/mixed; boundary="y92VoQwPpesYOhlfQQd8DmThc5KmxdnyL"; protected-headers="v1" From: "Edward Sanford Sutton, III" To: freebsd-questions@freebsd.org Message-ID: <9d793a27-659e-7b0a-ad9e-6eee34c2dc62@hotmail.com> Subject: Why doesn't cc -ansi disable conflicting type for getline from stdio.h? --y92VoQwPpesYOhlfQQd8DmThc5KmxdnyL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Trying to work on properly learning C so following K&R second edition of C Programming Language. Found in manpage that -std=3Dc89 or -ansi can be passed to setup a more compatible set of build rules which hid warnings about how main is defined. My understanding is that this should also cause getline to not be defined in /usr/include/stdio.h. Is there a reason that "#if __POSIX_VISIBLE >=3D 200809" should trigger as true in there with -std=3Dc89? Section 1.9 page 29 uses that function name in its own sample= code. I know I could rename it, but is there a way to disable this book to modern compiler incompatibility from command line as I was attempting? I've tried to call the compiler executable directly and also attempted with /usr/local/bin/clang10 without different results. I tried to disable ccache from environment variable setting but don't know how to tell if that took effect properly nor would I expect it should be relevant. If you have a different starting suggestion for learning C then I'd be interested but it seemed to be the guidance I found with internet searching and other starter books I own usually mix c and c++ with more of a c++ and nonunix focus. Also trying to work on learning vi while doing this; hard to wrap my brain around insert (sometimes?) backing me up 1 character when exiting the mode. If helpful I can include the code I typed form the page of text, or a smaller example showing the problem. Below is compiler command with output and /usr/lib/clang/11.0.1/include does not have a copy of stdio.h that I see. /usr/bin/clang -ansi -v characterarrays.c FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang" -cc1 -triple x86_64-unknown-freebsd13.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name characterarrays.c -mrelocation-model static -mframe-pointer=3Dall -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -fno-split-dwarf-inlining -debugger-tuning=3Dgdb -v -resource-dir /usr/lib/clang/11.0.1 -std=3Dc89 -fdebug-compilation-dir /home/mirror176/programming/k&r -ferror-limit 19 -fgnuc-version=3D4.2.1 -fcolor-diagnostics -faddrsig -o /tmp/characterarrays-a7e144.o -x c characterarrays.c clang -cc1 version 11.0.1 based upon LLVM 11.0.1 default target x86_64-unknown-freebsd13.0 #include "..." search starts here: #include <...> search starts here: /usr/lib/clang/11.0.1/include /usr/include End of search list. characterarrays.c:4:5: error: conflicting types for 'getline' int getline(char line[], int maxline); ^ /usr/include/stdio.h:380:10: note: previous declaration is here ssize_t getline(char ** __restrict, size_t * __restrict, FILE * __restrict); ^ characterarrays.c:16:37: error: too few arguments to function call, expected 3, have 2 while ((len =3D getline(line, MAXLINE)) > 0) ~~~~~~~ ^ /usr/include/stdio.h:380:10: note: 'getline' declared here ssize_t getline(char ** __restrict, size_t * __restrict, FILE * __restrict); ^ characterarrays.c:27:5: error: conflicting types for 'getline' int getline(char a[], int lim) ^ /usr/include/stdio.h:380:10: note: previous declaration is here ssize_t getline(char ** __restrict, size_t * __restrict, FILE * __restrict); ^ characterarrays.c:31:45: error: use of undeclared identifier 'c1' for (i=3D0; i Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0046F640A1C for ; Tue, 15 Jun 2021 06:11:09 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G3ycX2Sl5z4cTg for ; Tue, 15 Jun 2021 06:11:07 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id DB97E4E657; Mon, 14 Jun 2021 23:11:05 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Is a successful call to write(2) atomic? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22222.1623737465.1@segfault.tristatelogic.com> Date: Mon, 14 Jun 2021 23:11:05 -0700 Message-ID: <22223.1623737465@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G3ycX2Sl5z4cTg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 06:11:10 -0000 OK, here's a stupid programming question. I believed that I knew the answer to this, but now I'm no longer so sure. Assume that a given program, "example", forks a child process (or perhaps many such) and then each of these processes tries, in a manner that is entirely non-sychronized with any of the others, to write blocks of data using calls to write(2) to file descriptor 1. Assume further that "example" is run from the command line as follows: example > ordinary-disk-file Lastly asume that the return value for all calls to write() is diligently checked to insure that it is never either -1 or a short write count, and that if it ever, is, "example" will exit with a non-zero exit status (and assume also that otherwise it will exit with a zero exit status). Question: Assuming that "example" runs and exits with a zero status (thus indicating that all calls to write() completed successfully and none returned a short write count) then might it ever be the case that some single chunk of data that was successfully written to "ordinary-disk-file" by a single call to write() might be split into two or more parts in the output file, with chunks of data that were written by other processes in the same family possibly being interleaved between parts of that one chunk in the output file? In other words: Is a block of data that is successfully written by a single call to write() itself treated as being effectively atomic and indivisible, i.e. with repsect to the physical output file? I have always assumed so, but looking at the man page for write(2) just now I see that it contains no such guarrantee. And in fact, I have an output file which was written to by multiple processes from a family or procsses, and where some of the output appears to have been garbled in the sense of text lines that I know were written by one process being muddled up with lines that were written from other processes from the same family. Of course, this -might- all just be down to my own crappy programming. That's what 'm tryiong to determine.) From owner-freebsd-questions@freebsd.org Tue Jun 15 06:55:29 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1B647641808 for ; Tue, 15 Jun 2021 06:55:29 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G3zbh1CXdz4fXX for ; Tue, 15 Jun 2021 06:55:27 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: by mail-pj1-x1031.google.com with SMTP id 13-20020a17090a08cdb029016eed209ca4so891889pjn.1 for ; Mon, 14 Jun 2021 23:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tqFvgS1KTHwY1TcriJqQIpk9LbfgB9z3EmNyt6xYjc0=; b=VnYI6uki9sEiYxW2AKQer5k+Y2T5RFxhzad6ZbFJYlYCq4UpCB69U9VOqcaVrbKstJ omLLbEqmnvywI+NzUxFXY/FaSh5PPw6kvRDlZnKoECEf+ZmkN70bEKHsnpknUXIKmllv ShTUP5keKEWRu7ZIx9WczDUgohJMx99DB4+eWqAd2ExmQyMraNvJe8NLMuwQRNUeq7qJ RoqcJpsil5nPcYeSUJURAxVnRm9C5eM5PHGktZS1CsdUjbWfWFFuQHrP2CrgJ9/i6Rdk NzMZ02uFGpiCbn9I7N0Yzzor78g2KGKPjXjw2mvDNEif7FQGwYPGk0l5h0HLDmIcafDd NjoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tqFvgS1KTHwY1TcriJqQIpk9LbfgB9z3EmNyt6xYjc0=; b=rlvMr3Hi6fat7m7LLq8UQkhrVupnxb86vPkLCaBr3nGqmV0VM8T6OKYfhoq8M75hcL Ju4tGcyYPLHzD24BUX6DL/gjDX45ncvRFlTrHyJ6FpNxg8xi6ryZAROtZtrvJr6iBPpa dqwnR6UWYsL59MIfHmdlxykOZBCOVh+XMaO5vlesWwB3pZo4a778ELHmJrlpmUNVhqCr 3XrE9shNTFFoi+IWxmlsBkq1ePRRZJcxC4mIhczEx32/boYQN+5JsHG94L+TWaJYp6lW D4pygndC1iRgJ44lIpuQ8rsfhaLGkd7y4KjkkJcpHNPA/czuYm721hCZDdQ8nfDdJ8yt 7PzA== X-Gm-Message-State: AOAM533oX/XIZFASZGb+Gy5OwGPIrYqGIbBxE6qdBuoNZHWphzI3rFe+ X9CZ50YHW6qTUdjzvqIHJ2RAzTLeYDfzrxMHG0YgIUs42wMr X-Google-Smtp-Source: ABdhPJxqIg4Ckh37vqQc+EdA4cPvoIk4zG221Toe4/FsHnyoHPOO7mo0vGbSMUv7MMP5fxt8Idx758yrqtw7ibh7sd4= X-Received: by 2002:a17:90a:694d:: with SMTP id j13mr23642981pjm.99.1623740126274; Mon, 14 Jun 2021 23:55:26 -0700 (PDT) MIME-Version: 1.0 References: <22223.1623737465@segfault.tristatelogic.com> In-Reply-To: <22223.1623737465@segfault.tristatelogic.com> From: Paul Procacci Date: Tue, 15 Jun 2021 02:55:14 -0400 Message-ID: Subject: Re: Is a successful call to write(2) atomic? To: "Ronald F. Guilmette" Cc: FreeBSD Questions X-Rspamd-Queue-Id: 4G3zbh1CXdz4fXX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=VnYI6uki; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pprocacci@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=pprocacci@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::1031:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::1031:from:127.0.2.255]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 06:55:29 -0000 On Tue, Jun 15, 2021 at 2:11 AM Ronald F. Guilmette wrote: > > Assume that a given program, "example", forks a child process (or perhaps > many such) and then each of these processes tries, in a manner that is > entirely non-sychronized with any of the others, to write blocks of data > using calls to write(2) to file descriptor 1. > > Assume further that "example" is run from the command line as follows: > > example > ordinary-disk-file > > Lastly asume that the return value for all calls to write() is diligently > checked to insure that it is never either -1 or a short write count, > and that if it ever, is, "example" will exit with a non-zero exit status > (and assume also that otherwise it will exit with a zero exit status). > > Question: Assuming that "example" runs and exits with a zero status (thus > indicating that all calls to write() completed successfully and none > returned > a short write count) then might it ever be the case that some single chunk > of data that was successfully written to "ordinary-disk-file" by a single > call to write() might be split into two or more parts in the output file, > with chunks of data that were written by other processes in the same family > possibly being interleaved between parts of that one chunk in the output > file? > > I had a long response, but decided to shorten it....I hope you don't mind. The only time atomicity is guaranteed is for pipes when the write(2) size fits in PIPE_BUF (512 bytes on my version of FreeBSD). Otherwise, it depends is really the best answer as it depends on the file system. Sometimes filesystems like ext4 require O_DIRECT to be set, in order to avoid the garbled text as you've mentioned, and even then it's limited to the number of bytes written. A suggestion; the way I've done something similar in the past..... Parent Process - Orchestrator - creates pipes handing one end of the pipe to each child. Child Process - do'ers - write whatever it intends on writing to the pipe the parent is waiting for data on. Parent process then grabs the data the child wrote, and in turn writes it to stdout (or whatever file descriptor you intend). This method, a bit more involved, ensures one writer to a file descriptor, is portable, and you can rest easy about it working on whatever latest and greatest file system someone decides to make. That's always been my understanding anyways, and I am open to being corrected. ~Paul -- __________________ :(){ :|:& };: From owner-freebsd-questions@freebsd.org Tue Jun 15 07:06:27 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8252F64132F for ; Tue, 15 Jun 2021 07:06:27 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G3zrL5TyCz4fwB for ; Tue, 15 Jun 2021 07:06:26 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id A9A504E657; Tue, 15 Jun 2021 00:06:25 -0700 (PDT) From: "Ronald F. Guilmette" To: FreeBSD Questions Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22439.1623740785.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2021 00:06:25 -0700 Message-ID: <22440.1623740785@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G3zrL5TyCz4fwB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 07:06:27 -0000 In message , = Paul Procacci wrote: >I had a long response, but decided to shorten it....I hope you don't mind= . Not at all. >The only time atomicity is guaranteed is for pipes when the write(2) size >fits in PIPE_BUF (512 bytes on my version of FreeBSD). >Otherwise, it depends is really the best answer as it depends on the file >system. >Sometimes filesystems like ext4 require O_DIRECT to be set, in order to >avoid the garbled text as you've mentioned, and even then it's limited to >the number of bytes written. This is deeply distrubing. I never knew about this. I am furiously readi= ng the FreeBSD & Linux man pages for open(2). (It appears that both support that flags, O_DIRECT and O_SYNC, aqnd Linux also adds the O_DSYNC flag. I feel a bit dumb that I never nknew about these until now.) >A suggestion; the way I've done something similar in the past..... > >Parent Process - Orchestrator - creates pipes handing one end of the pipe >to each child. >Child Process - do'ers - write whatever it intends on writing to the pipe >the parent is waiting for data on. >Parent process then grabs the data the child wrote, and in turn writes it >to stdout (or whatever file descriptor you intend). Yes, yes. Believe me when I say that I am considering reworking my code to do exactly this as we speak. I don't even know for sure if I have a "{lack of} atomicity" problem in my existing code, but I am 100% sure that what you just described would completely solve the problem, if indeed it does exist. >This method, a bit more involved, ensures one writer to a file descriptor= , >is portable, and you can rest easy about it working on whatever latest an= d >greatest file system someone decides to make. Yes. Thank you. Regards, rfg From owner-freebsd-questions@freebsd.org Tue Jun 15 08:39:37 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 17087642FB2 for ; Tue, 15 Jun 2021 08:39:37 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G41vr26xYz4pk5; Tue, 15 Jun 2021 08:39:35 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=t8ejBvUBQ4EP6Ih/efmHicgSvUhcPbRS9NwnzEbAdgI=; b=lQJvOsNB3AP3cTQTlSczL3aM3o J6sQKGRku1nAqwFj+QdfnnHgB+Wc/zEpHMi4E7P8TyxLLRHOsgvyz2zlw79UMqZfFNRwaArZ8GhZb rZIw+sYsvCpUt6S2UKZXJL9c8BU2U/owsY1t5pKfkMstcNg7SZ4qPjLPIobgwZVtAz2w=; Received: from vas by admin.sibptus.ru with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1lt4bZ-000GIt-Ph; Tue, 15 Jun 2021 15:39:29 +0700 Date: Tue, 15 Jun 2021 15:39:29 +0700 From: Victor Sudakov To: freebsd-pkg@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Re: pourdiere broken for i386 jails ? (or maybe not poudriere per se) Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMRsYwQx6eggYDb+" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 X-Rspamd-Queue-Id: 4G41vr26xYz4pk5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=lQJvOsNB; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-6.10 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:5001:21dc::10:from]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2001:19f0:5001:21dc::10:from:127.0.2.255]; DKIM_TRACE(0.00)[sibptus.ru:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-pkg,freebsd-questions]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 08:39:37 -0000 --qMRsYwQx6eggYDb+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Victor Sudakov wrote: >=20 > Suddenly poudriere and poudriere-devel stopped working for i386 jails. I > can't say when exactly this happened but probably after a recent > freebsd-update. What surprises me is that a simple jail would not start: # jail -c path=3D/poudriere/jails/114i386 mount.devfs host.hostname=3Dtest3= 2bit command=3D/bin/tcsh ELF interpreter /libexec/ld-elf.so.1 not found, error 8 jail: /bin/tcsh: exited on signal 6 # file /poudriere/jails/114i386/libexec/ld-elf.so.1 /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared object,= x86-64, version 1 (FreeBSD), dynamically linked, stripped Why is ld-elf.so.1 in an i386 jail a 64-bit executable? Compare: # file /poudriere/jails/122i386/libexec/ld-elf.so.1 /poudriere/jails/122i386/libexec/ld-elf.so.1: ELF 32-bit LSB shared object,= Intel 80386, version 1 (FreeBSD), dynamically linked, stripped # file /poudriere/jails/114i386/bin/ls /poudriere/jails/114i386/bin/ls: ELF 32-bit LSB executable, Intel 80386, ve= rsion 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, fo= r FreeBSD 11.4, FreeBSD-style, stripped --=20 Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet --qMRsYwQx6eggYDb+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJgyGdBAAoJEA2k8lmbXsY0lIYIAIUqjO17OYol7zR8/VGXRhgt +iMewfZDl9iwIOtaK2/atYxOKedE5oFaCIBmApTZH8r7hjjoJg/6S6QLkdAF/NGF uxnfwnNgADWhRSr8DNpfe1tq4GtbsrTblc1O5hutNpQxo0TukwKBl7B25gJEn2Mw Rl2O9eIpn1ns2+rJU7OzocpIXTHh2hgyTqedHzuq8yrz8kpdKm09TH1Y313lAvYU pBy4aonGXSgrSm6W8WtESGX8dpg8LSukycfhgwRYw8FafupNq7lx52xGS4d/C4Zv jVy8YIDYyWqgWrHwwQW+cAGEOgW+qzOR/x4/u1Kt+wCANR0Lix800e9gmuJo0kU= =xv+x -----END PGP SIGNATURE----- --qMRsYwQx6eggYDb+-- From owner-freebsd-questions@freebsd.org Tue Jun 15 18:50:01 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A8E16504FF for ; Tue, 15 Jun 2021 18:50:01 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4HS86TzPz4rjm for ; Tue, 15 Jun 2021 18:50:00 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G4HS74Qc5z3jFn for ; Tue, 15 Jun 2021 14:49:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623782999; bh=8DL0L6kR1WB2FIqEVgiUUArL7yqIHheoKYJq3k/qL7U=; h=Subject:To:References:From:Date:In-Reply-To; b=MC/cYKqnaUrewxkpSzaoX5vT+VJdQRpKr/QyQZpYhivX4xykibl4C8fzva1PJMlzn FKkKDiApV974MkJkdXYQwHYwOF17ilj2BytJcm/bpA7wwy3wLLJskRCWCTIYg9lhlN b6WbJWLV1yNh6aFw5FnIz8rP72oio2YZ+HdgWOjc= Subject: Re: Is a successful call to write(2) atomic? To: freebsd-questions@freebsd.org References: <22440.1623740785@segfault.tristatelogic.com> From: Kurt Hackenberg Message-ID: <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> Date: Tue, 15 Jun 2021 14:49:57 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <22440.1623740785@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4HS86TzPz4rjm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=MC/cYKqn; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; DKIM_TRACE(0.00)[panix.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 18:50:01 -0000 On 2021/06/15 03:06, Ronald F. Guilmette wrote: > This is deeply distrubing. I never knew about this. I am furiously reading > the FreeBSD & Linux man pages for open(2). (It appears that both support > that flags, O_DIRECT and O_SYNC, aqnd Linux also adds the O_DSYNC flag. No, write(2) is not guaranteed atomic, and that's not obvious. Probably a lot of people have learned that the hard way. All I know about those flags is what I just read in the man page, but I think they don't guarantee atomic writes either -- at least, they're not intended to. The sync stuff means the system call won't return until the data has been written to disk (as opposed to queuing the write to be executed sometime later). That doesn't say anything about interleaving with other processes. Direct -- non-cached -- sounds like sort of the same thing, but at a different level, and it isn't even guaranteed to do that. The man page doesn't say much. Either of those might slow things down a lot, without necessarily solving your problem. Either might make the problem less likely to occur, and so harder to debug. I suggest that you don't use those flags for this purpose. This is an old, general problem: concurrent access to a shared resource. There are two common solutions. Paul suggested one of them: serialize access through a single process. The other is to serialize it through some kind of lock, that can only be held by one process at a time. Each process acquires the lock, uses the shared resource briefly, and immediately releases the lock. Semaphores are that kind of lock, invented for that purpose. Unix file systems have file locking, which does that for all or part of a file; see fcntl(2). Note that Unix file locking is advisory -- voluntary -- not compulsory. It only works if all the processes agree to use it. Also, in the past, it has not always worked for files accessed across the network, through NFS. I don't know whether it works through modern NFS. It's best to use it only for local files. Both approaches work fine, if they're done correctly; they're both a little complicated to implement. Getting it right requires a clear understanding of the problem and the solution. Sounds like you have the idea now. From owner-freebsd-questions@freebsd.org Tue Jun 15 19:16:14 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93DB6650EE4 for ; Tue, 15 Jun 2021 19:16:14 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4J2P4JgTz4tJR for ; Tue, 15 Jun 2021 19:16:13 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x135.google.com with SMTP id x12so115287ill.4 for ; Tue, 15 Jun 2021 12:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q44Icndb2kP9YpYZ9Tt4eCkEvflDTf2AAXslKD785xo=; b=jJAy8c0PSzWvLa4ZlsiE3WM2ZHajceVmzhubwzlCh7sZ+WohwZiX7EVQpgQcuyRyb3 iNfo0Kgf1eqrVj3ohy6gt6BVSepkX7KvPnFNDAarIYniz0Ea9hU9cMc77mIH2FOqAXQ5 sZ3WClexuQlaD29T5Pf+kxQXllRFjNJJsXZHBwtkG4p5UFyLN3re+ATbo8+ouDmclcUa aINZVyGyIBLmh65WSnmzKfxQpuYOUe2M+xT18W5u2Rp2Cn1sEInTXXYrCwl12r6cjWnC as0xBEr287IbCW7IMhJPtD3FNw3cMu4C61OpXbU+6KCjaPM2IGzVLZS/4OpO6G3oxj/0 Qx5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q44Icndb2kP9YpYZ9Tt4eCkEvflDTf2AAXslKD785xo=; b=fp9N8D8wRX4OSTr/frt6M8MigUmB/pF+AwwZlcEtcUmgDzZk6JfWY2XA5UA/91/STi bMTdbGq7Uqb24KZ/Kg3X3h1IQfkHFpg03/vMZNGsOcXpwG6uwSrC8+jdtCQalJKUFoEl YPMmD75x8fpHHwDHxWHFZzkUwzPAPXIxosUFG4mfSyhBEvJVz/Igv5Q7DNJL6m+1SVzx YR4hRQn4fvHprhkHFRRMYjUmfwapzbh94MxncVFuaR5Ky+ea/1kWb9UIifuxwlr/GLm8 UeSlWBHojpXTWNkEXqx0Jx835PfeV3EWUN1Sjda8AzVUnxlmvcibGhYSzdv0wR/dVHLT YgtQ== X-Gm-Message-State: AOAM531igrzrAQskBACCZ+4WT0EqF75El0ojp85yzetMISxgwL0uXek7 QxfM2ji+okloZfGPvH//hCVIFPVK3A6YzsXkt8E= X-Google-Smtp-Source: ABdhPJyPTOWZbAwnzn37sfGJpim5dtrjL9gjaUm66jFhmFKdVNSVhdsYlJ5RsJFtuGQs+EeldzVRpJw2bUVtpqTfzfc= X-Received: by 2002:a92:d451:: with SMTP id r17mr764761ilm.109.1623784572338; Tue, 15 Jun 2021 12:16:12 -0700 (PDT) MIME-Version: 1.0 References: <22440.1623740785@segfault.tristatelogic.com> <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> In-Reply-To: <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> From: Michael Schuster Date: Tue, 15 Jun 2021 21:16:01 +0200 Message-ID: Subject: Re: Is a successful call to write(2) atomic? To: Kurt Hackenberg Cc: freeBSD Mailing List X-Rspamd-Queue-Id: 4G4J2P4JgTz4tJR X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jJAy8c0P; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::135 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-1.83 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::135:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.17)[0.173]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::135:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::135:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:16:14 -0000 On Tue, Jun 15, 2021 at 8:50 PM Kurt Hackenberg wrote: > On 2021/06/15 03:06, Ronald F. Guilmette wrote: > > > This is deeply distrubing. I never knew about this. I am furiously > reading > > the FreeBSD & Linux man pages for open(2). (It appears that both support > > that flags, O_DIRECT and O_SYNC, aqnd Linux also adds the O_DSYNC flag. > > No, write(2) is not guaranteed atomic, and that's not obvious. Probably > a lot of people have learned that the hard way. > > All I know about those flags is what I just read in the man page, but I > think they don't guarantee atomic writes either -- at least, they're not > intended to. > > The sync stuff means the system call won't return until the data has > been written to disk (as opposed to queuing the write to be executed > sometime later). That doesn't say anything about interleaving with other > processes. > > Direct -- non-cached -- sounds like sort of the same thing, but at a > different level, and it isn't even guaranteed to do that. The man page > doesn't say much. > I think what you're describing - synchronous or not - is orthogonal to what Ronald is asking. Let's take a step back: an atomic write() either writes everything or nothing - and that's all. There's nothing in that claim that says "everything must be in a contiguous block", nor, that all the data must be written in a single "operation" by the underlying system. So after consideration I don't think the observed behaviour is violating the claim that write() is atomic - I welcome correction, of course :-) regards Michael Either of those might slow things down a lot, without necessarily > solving your problem. Either might make the problem less likely to > occur, and so harder to debug. I suggest that you don't use those flags > for this purpose. > > This is an old, general problem: concurrent access to a shared resource. > There are two common solutions. Paul suggested one of them: serialize > access through a single process. The other is to serialize it through > some kind of lock, that can only be held by one process at a time. Each > process acquires the lock, uses the shared resource briefly, and > immediately releases the lock. Semaphores are that kind of lock, > invented for that purpose. > > Unix file systems have file locking, which does that for all or part of > a file; see fcntl(2). Note that Unix file locking is advisory -- > voluntary -- not compulsory. It only works if all the processes agree to > use it. Also, in the past, it has not always worked for files accessed > across the network, through NFS. I don't know whether it works through > modern NFS. It's best to use it only for local files. > > Both approaches work fine, if they're done correctly; they're both a > little complicated to implement. Getting it right requires a clear > understanding of the problem and the solution. Sounds like you have the > idea now. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From owner-freebsd-questions@freebsd.org Tue Jun 15 19:51:26 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36D11651AFC for ; Tue, 15 Jun 2021 19:51:26 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4Jq15ZJNz3CWk for ; Tue, 15 Jun 2021 19:51:25 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G4Jq11JGHz3nYQ for ; Tue, 15 Jun 2021 15:51:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623786685; bh=Tbh9QvR96WOpjfi+So+EUpS4xIskS3n1Q91oQgSzg58=; h=Subject:To:References:From:Date:In-Reply-To; b=bYrXgmHNOMdrQdJ1wY3B2z2gVCuu1X07phSVJjtE9vmjmsvLnZBUgdwSSaMUnQtnk v/4O01OhFofg+k9E4EGA6Xlcm/SLjHSSvevrKDOcke6so7O9IooBVjDP89aJ91Z8yv Jpeo3wJ3rP7AiaHVfdEWrdP/TW23ZeqHWIaJQFQY= Subject: Re: Is a successful call to write(2) atomic? To: freebsd-questions@freebsd.org References: <22440.1623740785@segfault.tristatelogic.com> <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> From: Kurt Hackenberg Message-ID: <034b6d41-218a-0782-052e-c1c74a007897@panix.com> Date: Tue, 15 Jun 2021 15:51:22 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4Jq15ZJNz3CWk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=bYrXgmHN; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:51:26 -0000 On 2021/06/15 15:16, Michael Schuster wrote: > Let's take a step back: an atomic write() either writes everything or > nothing - and that's all. There's nothing in that claim that says > "everything must be in a contiguous block", nor, that all the data must be > written in a single "operation" by the underlying system. > > So after consideration I don't think the observed behaviour is violating > the claim that write() is atomic - I welcome correction, of course :-) You're just talking about the exact meaning of that word "atomic". Ronald used it to mean indivisible, as atoms were once thought to be; you advocate a slightly different meaning. That's a digression. Ronald's problem is clear, no matter what word we use. Paul and I know the problem and have suggested two well-known solutions. From owner-freebsd-questions@freebsd.org Tue Jun 15 21:28:12 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 19D42653E4D for ; Tue, 15 Jun 2021 21:28:12 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4Lyg17PCz3P6n for ; Tue, 15 Jun 2021 21:28:10 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id CFA7C4E657; Tue, 15 Jun 2021 14:28:03 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25717.1623792483.1@segfault.tristatelogic.com> Date: Tue, 15 Jun 2021 14:28:03 -0700 Message-ID: <25718.1623792483@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4Lyg17PCz3P6n X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 21:28:12 -0000 In message <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com>, Kurt Hackenberg wrote: >This is an old, general problem: concurrent access to a shared resource. I guess. For the moment I personally prefer to characterize it as an "atomicity" problem. (DIGRESSION: My vague recollection is that certain of the message passing primitives... most probably the old System V Version 4 ones, which are the only ones I ever actually used... *do* provide some guarrantees that individual messages will be treated as indivisible units, and never broken up into parts.) >There are two common solutions. Paul suggested one of them: serialize >access through a single process. I stated in response that I was 100% sure that that would solve the problem. Upon further reflection however, I wish to withdraw that assertion. In fact, it now appear to me that the notion of using a pipe to pass (indivisible?) lines of data up to a parent/controller process from a number of child processes, and then allowing that parent to "sequentialize" those data lines onto disk actually just moves the problem around, without actually addressing it. Consider this: If single ("successful") call to write() (which returns a value indicating that all bytes were written) fails to guarantee that the entire written buffer will be treated as an indivisible unit, then it likely fails to provide that fundamental guarantee *regardless* of whether the specific file descriptor being written to is associated with either (a) a file on the local hard disk or (b) a pipe being used to communicate with a another process. Thus, even if I were to implenment the master/slave approach... which I am familiar with and which I have implemented previously in other contexts... it seems to me that the absence of an iron-clad guarantee of "atomicity" with repsect to the data written in any single call to write() is still a potential problem. Am I making sense? >The other is to serialize it through some kind of lock... Yes, but it isn't clear to me that even this would address the problem. If the kernel may, at its sole discretion, take a single line of output data that I pass to it in a single call to write() and if it can break that single line into different sub-parts and then *physically* write those parts at different times of its own pleasure/choosing, then even if I make use of a "sequentializing" lock on the output file, it seems to me that the kernel might still be free to write the first half of any given line to the physical output file while the lock is in place, and then it might be allowed to write the second half of the line to the physical medium sometime *after* the lock is released. Result? Garbled output lines in the physical file... like what I am seeing already. It all comes back to the issue of the "atomicity" of single (successful) calls to write(). If that is indeed not a guaranteed aspect of the semantics of write() then I'm not sure that there is any actual solution to the problem which would be "guaranteed" to work. Sigh. Given this context, for the moment I think that I'm going to go back to assuming what I had always previously assumed, i.e. that single successful calls to write() do indeed treat the written data as an indivisible unit, and that actually, the garbled output I am seeing in my output files is most likely just a product of my sloppy programming and some misdirected pointer my code that got away from me somehow. Occam's razor says that this is really still the most likely explanation, and that I should probably be looking harder for mistakes in my code before I go around questioning the permanence of the heavenly constellations, or other things that, in practice, have always previously seemed to me to be axiomatic features of the Universe, such a gravity and the atomicity of write()'s. Regards, rfg From owner-freebsd-questions@freebsd.org Tue Jun 15 21:40:39 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFB8A653F3F for ; Tue, 15 Jun 2021 21:40:39 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4MF26mcPz3PWR for ; Tue, 15 Jun 2021 21:40:38 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 108CE4E657; Tue, 15 Jun 2021 14:40:38 -0700 (PDT) From: "Ronald F. Guilmette" To: freeBSD Mailing List Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25765.1623793237.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2021 14:40:38 -0700 Message-ID: <25766.1623793238@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4MF26mcPz3PWR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 21:40:39 -0000 In message Michael Schuster wrote: >Let's take a step back: an atomic write() either writes everything or >nothing - and that's all. Well, it *could* just do a partial write, and then return a short write count, but my code checks for that and causes the process to die a horrible and abundantly noisy death if it ever happens. (In practice and over many many runs, it has not happened even once.) Anyway, my reading of the man page is that the only cases where write() = might return a short count is when the FD being written to is some sort of a network socket, which is not relevant in this case (because I am writing to a disk file). >There's nothing in that claim that says >"everything must be in a contiguous block", nor, that all the data must b= e >written in a single "operation" by the underlying system. Indeed, and arguably the kernel *must* break up a buffer full of data that was passed in a single call to write() into multple parts in some instances, e.g. when writing to either an SSD or a good old "spinning rust" hard drive would cross a physical block boundary. My hope, of course, is that the entire buffer passed to write() would stil= l end up being written contiguously on the physical medium. >So after consideration I don't think the observed behaviour is violating >the claim that write() is atomic - I welcome correction, of course :-) I frankly don't know. It seems highly likely to me that Posix is most probably very precise in defining the behavior, but one would have to wade through a hundred pages or so to find the exact and crisp answer. Regards, rfg From owner-freebsd-questions@freebsd.org Tue Jun 15 22:30:07 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A410D655610 for ; Tue, 15 Jun 2021 22:30:07 +0000 (UTC) (envelope-from 4250.82.1d4d20004ba2877.ccb876393aa6d69205f10de412cbe983@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4NL65Rhlz3j47 for ; Tue, 15 Jun 2021 22:30:06 +0000 (UTC) (envelope-from 4250.82.1d4d20004ba2877.ccb876393aa6d69205f10de412cbe983@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1623796207; x=1626388207; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:to:from:date:x-thread-info; bh=hjVuMcyHS+BPBRNiS6v67ZUBWb12G8fHcNmRmX9nzvw=; b=sr4GUljstmZnHN9FQr7AEt6IIRWqXrOTooGajcEQCA6msOf3ipB9A7kzS4U67VEkKkFOwfwmZwonZS4RSAI74/Z4P9/MCviXk5HKc8daTh3dZGQdPSxMRCJcu+mNz+8zYbgoYZQZpvT+BdzdFBQnkORDsWvr2OP9DYuoVVHfa+E= X-Thread-Info: NDI1MC4xMi4xZDRkMjAwMDRiYTI4NzcuZnJlZWJzZC1xdWVzdGlvbnM9ZnJlZWJzZC5vcmc= Received: from r2.h.in.socketlabs.com (r2.h.in.socketlabs.com [142.0.180.12]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Tue, 15 Jun 2021 18:29:54 -0400 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r2.h.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Tue, 15 Jun 2021 18:29:54 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1ltHZA-000PLO-Er for freebsd-questions@freebsd.org; Tue, 15 Jun 2021 23:29:52 +0100 Date: Tue, 15 Jun 2021 23:29:52 +0100 From: Steve O'Hara-Smith To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? Message-Id: <20210615232952.661a4fa1783c0c5bf1bb77d6@sohara.org> In-Reply-To: <22223.1623737465@segfault.tristatelogic.com> References: <22223.1623737465@segfault.tristatelogic.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4NL65Rhlz3j47 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=sr4GUljs; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d4d20004ba2877.ccb876393aa6d69205f10de412cbe983@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d4d20004ba2877.ccb876393aa6d69205f10de412cbe983@email-od.com X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[142.0.176.198:from]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[sohara.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[142.0.176.198:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; DKIM_TRACE(0.00)[email-od.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d4d20004ba2877.ccb876393aa6d69205f10de412cbe983@email-od.com]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d4d20004ba2877.ccb876393aa6d69205f10de412cbe983@email-od.com]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 22:30:07 -0000 On Mon, 14 Jun 2021 23:11:05 -0700 "Ronald F. Guilmette" wrote: > In other words: Is a block of data that is successfully written by a > single call to write() itself treated as being effectively atomic and > indivisible, i.e. with repsect to the physical output file? In a word ... no. There is no guarantee that a write(2) operation will result in contiguous data in the file. To ensure that you need locking or a single writer. -- Steve O'Hara-Smith From owner-freebsd-questions@freebsd.org Tue Jun 15 22:43:36 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2BD896555E5 for ; Tue, 15 Jun 2021 22:43:36 +0000 (UTC) (envelope-from 4250.82.1d4d20004bafe8c.1454481cb1f1e5d487d869eaf5c6e173@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4Ndg3nZnz3k0W for ; Tue, 15 Jun 2021 22:43:35 +0000 (UTC) (envelope-from 4250.82.1d4d20004bafe8c.1454481cb1f1e5d487d869eaf5c6e173@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1623797015; x=1626389015; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:cc:to:from:date:x-thread-info; bh=3FIBWjNh1eKCo8Kw6SeQvco4pcwsWFP/yy4aVlapvyA=; b=JXFe4y2xs5DqC92tOmWBBOVGulL3B/xWgXXSaU3h0faJi5HRX22gUjapg5ccHRg9X8xhcT6PjZG0kcGKyzL2kL1wSuqNYK3si4oqibrdDt4BX/+/shAxX3Z6VPGMsivm2LVsN20LSYRFv5rEvi3VwlHxG/ZIMisKYa5jBWc3nps= X-Thread-Info: NDI1MC4xMi4xZDRkMjAwMDRiYWZlOGMuZnJlZWJzZC1xdWVzdGlvbnM9ZnJlZWJzZC5vcmc= Received: from r3.sg.in.socketlabs.com (r3.sg.in.socketlabs.com [142.0.179.13]) by mxsg2.email-od.com with ESMTP; Tue, 15 Jun 2021 18:43:31 -0400 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r3.sg.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Tue, 15 Jun 2021 18:43:30 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1ltHmK-000PN8-UJ; Tue, 15 Jun 2021 23:43:29 +0100 Date: Tue, 15 Jun 2021 23:43:28 +0100 From: Steve O'Hara-Smith To: Kurt Hackenberg Cc: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? Message-Id: <20210615234328.b2de12c70efe6efaee17ec1e@sohara.org> In-Reply-To: <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> References: <22440.1623740785@segfault.tristatelogic.com> <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4Ndg3nZnz3k0W X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=JXFe4y2x; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d4d20004bafe8c.1454481cb1f1e5d487d869eaf5c6e173@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d4d20004bafe8c.1454481cb1f1e5d487d869eaf5c6e173@email-od.com X-Spamd-Result: default: False [-1.70 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[142.0.176.198:from]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sohara.org]; SPAMHAUS_ZRD(0.00)[142.0.176.198:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[email-od.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d4d20004bafe8c.1454481cb1f1e5d487d869eaf5c6e173@email-od.com]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d4d20004bafe8c.1454481cb1f1e5d487d869eaf5c6e173@email-od.com]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 22:43:36 -0000 On Tue, 15 Jun 2021 14:49:57 -0400 Kurt Hackenberg wrote: > No, write(2) is not guaranteed atomic, and that's not obvious. Probably > a lot of people have learned that the hard way. Strangely (after posting a confident no it isn't guaranteed) I noticed this in write(2) which implies that it is guaranteed to write a contiguous block (at least for seekable objects): -------------- On objects capable of seeking, the write() starts at a position given by the pointer associated with fd, see lseek(2). Upon return from write(), the pointer is incremented by the number of bytes which were written. -------------- I've always been sure it wasn't so this is something of a surprise. That being said there is no guarantee that another process won't see EOF at an intermediate point in the write and use that as the starting point for its write which would then cause corruption. -- Steve O'Hara-Smith From owner-freebsd-questions@freebsd.org Tue Jun 15 23:30:06 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 76C9F656049 for ; Tue, 15 Jun 2021 23:30:06 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4PgK0WkKz3pkm for ; Tue, 15 Jun 2021 23:30:04 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G4PgG70cMz42ZL for ; Tue, 15 Jun 2021 19:30:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623799803; bh=/Wh2uLJ3DRWYfUi9DOAFiLhBPOcHx+4ZuSnB7+tnHi4=; h=Subject:To:References:From:Date:In-Reply-To; b=R0dAyR7Qk+kugkfyVYnT4i9xS98I0v8kT9y/SyUkbaZC5uvhTH0Bs1DwFVc3TboRu YybgY2IjxN///UYNRJUeK013FNOLPIO/vyRtUGWvSm9ZtGfATAIS4pnjYxR1xpOyRR wvehonb+JmSgGrMP9iGgZnHtBfwuoh1RKged4DAk= Subject: Re: Is a successful call to write(2) atomic? To: freebsd-questions@freebsd.org References: <25718.1623792483@segfault.tristatelogic.com> From: Kurt Hackenberg Message-ID: Date: Tue, 15 Jun 2021 19:29:59 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <25718.1623792483@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4PgK0WkKz3pkm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=R0dAyR7Q; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 23:30:06 -0000 On 2021/06/15 17:28, Ronald F. Guilmette wrote: >> There are two common solutions. Paul suggested one of them: serialize >> access through a single process. > > I stated in response that I was 100% sure that that would solve the problem. > Upon further reflection however, I wish to withdraw that assertion. > > In fact, it now appear to me that the notion of using a pipe to pass > (indivisible?) lines of data up to a parent/controller process from a > number of child processes, and then allowing that parent to "sequentialize" > those data lines onto disk actually just moves the problem around, without > actually addressing it. > > Consider this: If single ("successful") call to write() (which returns a > value indicating that all bytes were written) fails to guarantee that > the entire written buffer will be treated as an indivisible unit, then > it likely fails to provide that fundamental guarantee *regardless* of > whether the specific file descriptor being written to is associated > with either (a) a file on the local hard disk or (b) a pipe being used > to communicate with a another process. You're right. Sorry, I didn't give enough attention to the details of that solution. But it works by just changing the messaging mechanism a little: Have many pipes, one for each sender, all sending to the single write process, which uses the system call select() to wait for activity on any of them. The write process still has to make sure it reads all of a message from a pipe before going on to another pipe, but that's straightforward, if it knows how much data to expect. Did you mentions lines -- each sender sends one line to be written, and each line must be atomic, but it's OK to write the many lines in any order? If so, the writer process just keeps reading a pipe until it gets a complete line. If it's not lines, then do something similar -- have an end-of-message marker, or precede each message with its length in bytes, or hard-code a fixed length for all messages -- any way for the writer process to know it has a complete message. From owner-freebsd-questions@freebsd.org Tue Jun 15 23:44:01 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FCB2655EF9 for ; Tue, 15 Jun 2021 23:44:01 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4PzN2gmyz3qBR for ; Tue, 15 Jun 2021 23:44:00 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: by mail-pf1-x434.google.com with SMTP id k6so670118pfk.12 for ; Tue, 15 Jun 2021 16:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vEz4RmfFxUjHvmV8N5ZxIS2CiPMz8x0SrSkqIO0Zobk=; b=lUQS889hK4r6cy3i9IRMd1hpuUMEyyO4WhpKg1AQgmjAHtWhIZSGeCg1inbi8GrEnk QB6wBPp8V26g2CdxrU8hOMPc390t8/3opTHVZ3lNA+W5sZo2OWtx9NreF9m6NMjGtOm/ cZyUkOuua2VPc5RLbBrWCY8ZEivtNrczIw30kI9+GNDAzwN8SpCX1UGaHthwjbp8gdcB qgT8nrJIX42l/FMBnSFxozwhpkaPCGfWi1gqeoHKsOZ0Q/bJCS6xcRJtVDOGy0kWoQAB KpC+5KPtbF2gZeG2uPsoU0nq3Wkv6FTi4b0pISscZi+y93B5dxQcdP3IDIadyysDZXy+ wFWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vEz4RmfFxUjHvmV8N5ZxIS2CiPMz8x0SrSkqIO0Zobk=; b=oqkB9ns3NEcbpexQvhtRiQ43OwmT+oDd0yGGXps5NtcFZnKo5h8Bs5xorSnM8ojWFe UVWHkvUzB5haRXpSe1a5EhjFG/1sb8FF8mXmnoWDvgnY6CPbrkw/Aq2V+PITlXcwj/G0 yWwRztSZsqvHQrnnEHSdIH0buxwNJFlADTa12AY/IZ/05BUAiAHg4LzZ8JmKMt14dG4F RiydNhJL3+HkvCXTn50xrcKjYkbL4YTbdC7w9J+4CpZazdCbOjCuYAKipDVjnszVH09s nLNzrk4DO0/YQsIEL76xVyzTZpPr/sxEBIhFhGKLjU1DnZebmi9OWrK7XQsej4cSWWC8 8WJg== X-Gm-Message-State: AOAM5332moCZ6YGPnxM5T4m0VjkHZY4qJQUrr0iWqk1VG/q/Q1VjOfG1 1OXexTKCq9TDfiCE0hLaAqEmgVWCwr0zUPPVA4VrZj3UjC5p X-Google-Smtp-Source: ABdhPJwpZVMZCTAjrjRhhqhG0wG3Olnh3La7doDkGgKBxmUUKBMAwoSi+hf2C39VFF0ItloUXUiASCLNXDkSwkQe6Tc= X-Received: by 2002:aa7:81c5:0:b029:2f7:d4e3:78e9 with SMTP id c5-20020aa781c50000b02902f7d4e378e9mr6737036pfn.31.1623800638757; Tue, 15 Jun 2021 16:43:58 -0700 (PDT) MIME-Version: 1.0 References: <25766.1623793238@segfault.tristatelogic.com> In-Reply-To: <25766.1623793238@segfault.tristatelogic.com> From: Paul Procacci Date: Tue, 15 Jun 2021 19:43:47 -0400 Message-ID: Subject: Re: Is a successful call to write(2) atomic? To: "Ronald F. Guilmette" Cc: freeBSD Mailing List X-Rspamd-Queue-Id: 4G4PzN2gmyz3qBR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=lUQS889h; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pprocacci@gmail.com designates 2607:f8b0:4864:20::434 as permitted sender) smtp.mailfrom=pprocacci@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::434:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::434:from:127.0.2.255]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::434:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 23:44:01 -0000 > I frankly don't know. It seems highly likely to me that Posix is most > probably very precise in defining the behavior, but one would have to > wade through a hundred pages or so to find the exact and crisp answer.-- > > I read some of them last night before responding to you to ensure all my ducks were in a row. ;) https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05_01 https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07 https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html The last link in particular ... used to read as: "This volume of POSIX.1-2008 does not specify behavior of concurrent writes to a file from multiple processes. Applications should use some form of concurrency control. " It now reads: This volume of POSIX.1-2017 does not specify the behavior of concurrent writes to a regular file from multiple threads, except that each write is atomic (see *Thread Interactions with Regular File Operations* ). Applications should use some form of concurrency control. In both cases, it states: "Applications should use some form of concurrency control". ~Paul __________________ :(){ :|:& };: From owner-freebsd-questions@freebsd.org Tue Jun 15 23:56:00 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4DF25656969 for ; Tue, 15 Jun 2021 23:56:00 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4QFC3JX1z3rQN for ; Tue, 15 Jun 2021 23:55:58 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id E8A2C4E680; Tue, 15 Jun 2021 16:55:56 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26203.1623801356.1@segfault.tristatelogic.com> Date: Tue, 15 Jun 2021 16:55:56 -0700 Message-ID: <26204.1623801356@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4QFC3JX1z3rQN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-1.41 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.11)[-0.107]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 23:56:00 -0000 In message , Kurt Hackenberg wrote: >But it works by just changing the messaging mechanism a little: Have >many pipes, one for each sender, all sending to the single write >process, which uses the system call select() to wait for activity on any >of them. You're correct! That sounds like a nice solution. >The write process still has to make sure it reads all of a message from >a pipe before going on to another pipe,... Yes. Obviously. >Did you mentions lines -- each sender >sends one line to be written, and each line must be atomic, but it's OK >to write the many lines in any order? In the context of what I'm doing, yes. The ordering of the lines within the output file is of no special importance. It's only important that each line remains as a single unit and that it does not get mashed up with parts from any other line. >If it's not lines, >then do something similar -- have an end-of-message marker, or precede >each message with its length in bytes... Yes, and yes. No worries. Each separate line ends with \n, so the exact extent of each separate line is totally unambiguous. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 00:09:02 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E43C165716B for ; Wed, 16 Jun 2021 00:09:02 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4QXG28rYz3sNm for ; Wed, 16 Jun 2021 00:09:02 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 786C34E657; Tue, 15 Jun 2021 17:09:01 -0700 (PDT) From: "Ronald F. Guilmette" To: freeBSD Mailing List Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26257.1623802141.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2021 17:09:01 -0700 Message-ID: <26258.1623802141@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4QXG28rYz3sNm X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-0.33 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.965]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 00:09:03 -0000 In message Paul Procacci wrote: >It now reads: > >This volume of POSIX.1-2017 does not specify the behavior of concurrent >writes to a regular file from multiple threads, except that each write is >atomic (see *Thread Interactions with Regular File Operations* >). >Applications should use some form of concurrency control. > >In both cases, it states: "Applications should use some form of >concurrency control". Sigh. The above (revised) verbage isn't my personal idea of unambiguous clarity. I mean it isn't even clear what -they- mean by "atomic" in this context. They may intend it to mean exactly what I have been using it to mean here, but if I have learned anything about Posix, it is that their documents are sometimes subtle in their use of terminology. (I sustained some serious verbal abuse on one Posix mailing list some months ago for my failure to fully appreciate this.) More to the point, if indeed each call to write() *is* "atomic"... at leas= t in the sense that the given buffer will be treated like an indivisable who= le, all of the way along its journey to some physical device... then why are users nontheless being encouraged, still, to "use some form of concurrency control"? I mean what would be the point of that if in fact write() never busts up the hunks of data given to it into separate sub-hunks? Sounds to me like they are saying "Here, we are giving you this belt, but we advise you to wear your suspenders also, just in case." This seems goofy on the face of it. Regards, rfg P.s. Thanks Paul, for researching the relevant Posix pronouncements. From owner-freebsd-questions@freebsd.org Wed Jun 16 00:19:48 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 001A76573CD for ; Wed, 16 Jun 2021 00:19:47 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4Qmg4ZrTz3tKZ for ; Wed, 16 Jun 2021 00:19:47 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G4Qmf6Wg4z44Rp for ; Tue, 15 Jun 2021 20:19:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623802786; bh=n4mdINq+DvqxagqA09qJyI7aotCVzfVrFbHjaGjwkEo=; h=Subject:To:References:From:Date:In-Reply-To; b=mg+NHjvjFXvEXmQl6jxbxexyIs91lIB1wT5aR370+2VpIWinN3i+C2ZLvY+CSx9pp yzIaMJRcT+yImo2xGGrmOZqI79pxXCc1faXIUgQbzokI3yRnDRJUqmjhRRKQzH9e5G QjemKAwF+fNvZJvSghHT1XKYuhYqBvLi8MUsbLCw= Subject: Re: Is a successful call to write(2) atomic? To: freebsd-questions@freebsd.org References: <26204.1623801356@segfault.tristatelogic.com> From: Kurt Hackenberg Message-ID: <303bd83e-0e32-85a2-58c0-59c90834a6f2@panix.com> Date: Tue, 15 Jun 2021 20:19:44 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <26204.1623801356@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4Qmg4ZrTz3tKZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=mg+NHjvj; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16:c]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 00:19:48 -0000 On 2021/06/15 19:55, Ronald F. Guilmette wrote: >> But it works by just changing the messaging mechanism a little: Have >> many pipes, one for each sender, all sending to the single write >> process, which uses the system call select() to wait for activity on any >> of them. > > You're correct! That sounds like a nice solution. On reread, I see that Paul suggested that originally, many pipes, and that's what I was thinking. Paul's writing may not have been perfectly clear. Let us know whether it works. From owner-freebsd-questions@freebsd.org Wed Jun 16 00:34:15 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 55FB06577A4 for ; Wed, 16 Jun 2021 00:34:15 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4R5L0yRKz3vcT for ; Wed, 16 Jun 2021 00:34:13 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G4R5K3wqcz44sP for ; Tue, 15 Jun 2021 20:34:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623803653; bh=FdV1QE76EMwhMoSLIUUkHzRyMtm0+ILB1jvqBvrn/e0=; h=Subject:To:References:From:Date:In-Reply-To; b=n3AelY0bBI/zZykj9qJ2EsXQYNsJ9GzNyVDBDKzobGosXi2MdrsIDDxHlcnpKHwbp fqlnUVtaribuVhvvkYubFRshSyrJJPQ08eMJoiLH1aUv0TGWiivQFpT5K/UNoA9VKv 9AZSrkBf5oNY9BlI25oWDOMGZeS5Dl7ngduNkgwo= Subject: Re: Is a successful call to write(2) atomic? To: freebsd-questions@freebsd.org References: <22440.1623740785@segfault.tristatelogic.com> <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> <20210615234328.b2de12c70efe6efaee17ec1e@sohara.org> From: Kurt Hackenberg Message-ID: <76ccd29b-d54b-803f-4b02-a565bb649eca@panix.com> Date: Tue, 15 Jun 2021 20:34:10 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210615234328.b2de12c70efe6efaee17ec1e@sohara.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4R5L0yRKz3vcT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=n3AelY0b; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16:c]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 00:34:15 -0000 On 2021/06/15 18:43, Steve O'Hara-Smith wrote: >> No, write(2) is not guaranteed atomic, and that's not obvious. Probably >> a lot of people have learned that the hard way. > > Strangely (after posting a confident no it isn't guaranteed) I > noticed this in write(2) which implies that it is guaranteed to write a > contiguous block (at least for seekable objects): > > -------------- > On objects capable of seeking, the write() starts at a position given > by the pointer associated with fd, see lseek(2). Upon return from write(), > the pointer is incremented by the number of bytes which were written. That's talking about the pointer associated with the file descriptor. The system call fork() gives the child process *copies* of file descriptors. Not clear whether that pointer is also copied. That man page doesn't discuss concurrent writes; I wouldn't swear to the exact meaning of that quote. I think Ronald has effectively written test code, and got garbled output. From owner-freebsd-questions@freebsd.org Wed Jun 16 01:13:21 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 533F86582AB for ; Wed, 16 Jun 2021 01:13:21 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4RyS4ZhXz4Rgy for ; Wed, 16 Jun 2021 01:13:20 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 729FE4E657; Tue, 15 Jun 2021 18:13:19 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <76ccd29b-d54b-803f-4b02-a565bb649eca@panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26478.1623805999.1@segfault.tristatelogic.com> Date: Tue, 15 Jun 2021 18:13:19 -0700 Message-ID: <26479.1623805999@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4RyS4ZhXz4Rgy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 01:13:21 -0000 In message <76ccd29b-d54b-803f-4b02-a565bb649eca@panix.com>, Kurt Hackenberg wrote: >> On objects capable of seeking, the write() starts at a position given >> by the pointer associated with fd, see lseek(2). Upon return from write(), >> the pointer is incremented by the number of bytes which were written. > >That's talking about the pointer associated with the file descriptor. >The system call fork() gives the child process *copies* of file >descriptors. Not clear whether that pointer is also copied. If i am remembering correctly, this is the exact issue that I got verbally beaten up about on a Posix standards group mailing list some months back, simply because there were two -very- similar bits of terminology which had important *but critically different* semantics associated with them. (I don't even remember what the two terms in question were... something like "file descriptor" and "file description"... or at any rate, some two terms that were approximately that close to one another, lexigraphically speaking, and which were thus VERY easy to confuse with one another.) Anyway, if I am rembering correctly, the outcome of my brief foray onto the Posix list in question was that indeed, a fork() causes the child to receive "a copy of" the file descriptor that is open in the parent, *but* that after that each process is effectively on its own and they *do not* thereafter *share* a single common file descriptor but instead each maintains its own separate copy thereof after the fork() (and perhaps also its own separate file pointer, if i am remembering correctly). Thanks for forcing me to remember all this. Now that I have, I see that this may in fact be the explanation for the garbled output files I've seen. I will have to go back and review that email conversation, but again, my recollection is that I got abused because I had failed to grasp that after a fork, both parent & child have their own independent (and initially identical) *copies* of any open file descriptors, but that after the fork, each (copied) "fd" is a separate and distinct thing... *HOWEVER* there is also some thing which exists at an even lower level and which represents the kernel's direct interface to the (opened) output device or file. I need to do some programming now, but now I think I may now understand the actual problem. If I do, then just sending all the output data to some "master" process and having it be the only one making calls to write() may indeed solve the problem. (If it does, then I'll declare that... in my opinion... write() *does not* have any kind of "atomicity" problem, but rather, allowing a child process to write to any given fd which it inherited (a copy of) via fork(), even as other processes within the same process group do likewise will almost always lead to heartache, misery, and garbled output.) Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 01:26:09 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D5F35658748 for ; Wed, 16 Jun 2021 01:26:09 +0000 (UTC) (envelope-from johnl@iecc.com) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gal.iecc.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4SFD2zfYz4SB6 for ; Wed, 16 Jun 2021 01:26:08 +0000 (UTC) (envelope-from johnl@iecc.com) Received: (qmail 30474 invoked from network); 16 Jun 2021 01:26:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=76e8.60c9532f.k2106; bh=PIpD/mv7BOPOP//RO+z/xoCXK2tvMXpWEVE8QI3IOtU=; b=ftf1rkF3Tp1cDalMJ/QsawlRJVOYyg3BiI9cUrwG/aUBJMQEKG78sGqw9VP2e6/rcaig6nPS3BcDuz9HRPPDk4lSifTppX+Bez1yVXwPBUqEjjdRjZsiUx1SMmuo9XACa++joLbKKcbNvQtXb1C0uSwzMlzR83Wora2unKYxD7xxDVdJ5mMNEe3I2Z8utJ60+Mz6bocdgfAGR9tAOqMU0Ubq/pzTnjoYJYHmG7gRBiMDqTcZKdy5AknQgGtPgKPgtCUfFadJ9JkwIXTfC+KlzYwXkimLNCd0qRbXvzuh46q7T1euwDNgjL3RmLoUtduuzVYK56OZzTPulll3flF5OA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Jun 2021 01:26:06 -0000 Received: by ary.qy (Postfix, from userid 501) id 3C77A1183464; Tue, 15 Jun 2021 21:26:04 -0400 (EDT) Date: 15 Jun 2021 21:26:04 -0400 Message-Id: <20210616012606.3C77A1183464@ary.qy> From: "John Levine" To: freebsd-questions@freebsd.org Cc: rfg@tristatelogic.com Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <26258.1623802141@segfault.tristatelogic.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit X-Rspamd-Queue-Id: 4G4SFD2zfYz4SB6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=iecc.com header.s=76e8.60c9532f.k2106 header.b=ftf1rkF3; dmarc=pass (policy=none) header.from=iecc.com; spf=pass (mx1.freebsd.org: domain of johnl@iecc.com designates 2001:470:1f07:1126:0:43:6f73:7461 as permitted sender) smtp.mailfrom=johnl@iecc.com X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:1f07:1126:0:43:6f73:7461:from]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f07:1126::/64]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[2001:470:1f07:1126:0:43:6f73:7461:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[iecc.com:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2001:470:1f07:1126:0:43:6f73:7461:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[iecc.com:s=76e8.60c9532f.k2106]; DMARC_POLICY_ALLOW(-0.50)[iecc.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 01:26:09 -0000 It appears that Ronald F. Guilmette said: >More to the point, if indeed each call to write() *is* "atomic"... at least >in the sense that the given buffer will be treated like an indivisable whole, >all of the way along its journey to some physical device... then why are >users nontheless being encouraged, still, to "use some form of concurrency >control"? I mean what would be the point of that if in fact write() never >busts up the hunks of data given to it into separate sub-hunks? I think it depends on the device. If I just want to write stuff to a log file and not get it scrambled, this should do the trick: fd = open("somefile", O_CREAT|O_WRONLY|O_APPEND); /* put some stuff in buf[] */ flock(fd, LOCK_EX); write(fd, buf, strlen(buf)): /* O_APPEND ensures it's added at the end */ flock(fd, LOCK_UN); R's. John From owner-freebsd-questions@freebsd.org Wed Jun 16 02:40:35 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8E783658F7B for ; Wed, 16 Jun 2021 02:40:35 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4Tv66Zssz4W3D for ; Wed, 16 Jun 2021 02:40:34 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: by mail-pf1-x42d.google.com with SMTP id g6so1001031pfq.1 for ; Tue, 15 Jun 2021 19:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3atOTmtgX7Ob7Qugd7sx0x6VFQIaZYr4TXgYFE+Oh+Q=; b=HNsGBSJfYZYY1tENRKAb9eaxG7ZPvDFnfIo2BI8DaIKTv5UeCckktWeUKQvP0d7t7m ThbN9qWYEFohgefCwhTaoe/En1cMPuQoPMcabjZIsrRg0YvFlBr53thHTak6H+rrvKZv s41BKcCCNVPfWUBmdeNZU+9CYw4CGW7XJnmEc8tVOhwI8GqZQ7gA8gVF7QlP2p0K33Gl auPCNmqIKs4QbRRJJZzjPMhYwf62nMRHUTJ0rq9kj7EIAK0FYhXv8a3RvZHUYM2RwttP 6KODbIr01qqFWjEDYoNQPX7azTFxWbHW9uTILTmS0KrueOORlmVe2K49P9hT/Bzz2vVK jRIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3atOTmtgX7Ob7Qugd7sx0x6VFQIaZYr4TXgYFE+Oh+Q=; b=Qcdwy+DUYU6vjbO25diW67y4ZhJI71T0C8hX7tZFsPycCGt+XeBvr3jjB4bVH31Evi HlMFqiQlQni7MpxNJi8G5HZ5Tv1IJRLhGxUIvj5r8eRGyIaSmNWalE4uULX1C8ALlV68 ZcM0i/zmP6Gdm17iaoDXasZvBakJCswj3Ce8bQeVJRk4Mb812bJBPowgGfBYX3BljPGd iDDB37U8nz5E3rXNbAx4ac2RCt0WBeTom1RoBvRqeoEOOSu4bZUgyR03dAcIREOi/WG1 FKkOTKXofVuW6o3KgP+OCdhd/LuHXBhfFATnOVx7oL0/ZoviNuk15Mo/77+KB10wkrsN WBxQ== X-Gm-Message-State: AOAM530SSRGRI4uTYixvTptYbOzFx0yFVwwYb3+Qkr2NrIHRSBuKonfT lPxgoG7/vFeYKmTbg+lhRKHIxYvFdEgMQEy8Yw== X-Google-Smtp-Source: ABdhPJyNms4dzFw1j9r7T2kQ3AfXq6wBMPMA9aSXnOGIzd6W3qiEDUn7wBb1ZEla45kAGwb01fUIaIgQQj+sdr8CsHU= X-Received: by 2002:a63:4b59:: with SMTP id k25mr2652934pgl.252.1623811233680; Tue, 15 Jun 2021 19:40:33 -0700 (PDT) MIME-Version: 1.0 References: <26204.1623801356@segfault.tristatelogic.com> <303bd83e-0e32-85a2-58c0-59c90834a6f2@panix.com> In-Reply-To: <303bd83e-0e32-85a2-58c0-59c90834a6f2@panix.com> From: Paul Procacci Date: Tue, 15 Jun 2021 22:40:22 -0400 Message-ID: Subject: Re: Is a successful call to write(2) atomic? To: Kurt Hackenberg Cc: FreeBSD Questions X-Rspamd-Queue-Id: 4G4Tv66Zssz4W3D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=HNsGBSJf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pprocacci@gmail.com designates 2607:f8b0:4864:20::42d as permitted sender) smtp.mailfrom=pprocacci@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::42d:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::42d:from:127.0.2.255]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42d:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 02:40:35 -0000 >> On reread, I see that Paul suggested that originally, many pipes, and >> that's what I was thinking. Paul's writing may not have been perfectly >> clear. This is what I was advocating for. Sorry if that wasn't clear. It might make sense to provide a visual representation using C pseudo code: while(children_needed){ int pipes[2]; pipe(pipes); switch(vfork()){ case -1: _exit(123); case 0: /** Remove/Move unnecessary fds - fcntl(2) for example - make one end of the pipe the child's stdout maybe? */ exec(); _exit(123); } /** Remove/Move unnecessary fds - fcntl(2) for example */ /** Store other end of pipe fd to poll later - can use an fdset for use with select(2) or kqueue(2) */ --children_needed; } The above, again just pseudo code, describes what I meant, which is essentially ... a Parent orchestrating the children .... reading their ends of the pipes for their childrens input ... and then later on (not shown in the pseudo code), doing something with that data. The above is probably a bit winded, but I felt the need to describe what I specifically meant, and there's no better way to do that with actual code, even if it's pseudo code. By the looks of it, I think we both meant the same exact thing. ;) ~Paul * Full Warning - The above code needs a lot of work like checking return values of syscalls and acting accordingly. Do not use it as is. It was only thrown together to provide a quick visual representation. On Tue, Jun 15, 2021 at 8:19 PM Kurt Hackenberg wrote: > On 2021/06/15 19:55, Ronald F. Guilmette wrote: > > >> But it works by just changing the messaging mechanism a little: Have > >> many pipes, one for each sender, all sending to the single write > >> process, which uses the system call select() to wait for activity on any > >> of them. > > > > You're correct! That sounds like a nice solution. > > On reread, I see that Paul suggested that originally, many pipes, and > that's what I was thinking. Paul's writing may not have been perfectly > clear. > > Let us know whether it works. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > -- __________________ :(){ :|:& };: From owner-freebsd-questions@freebsd.org Wed Jun 16 02:54:20 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 42458659167 for ; Wed, 16 Jun 2021 02:54:20 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4VBy6gdRz4WWJ for ; Wed, 16 Jun 2021 02:54:18 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G4VBy2mGcz497Z for ; Tue, 15 Jun 2021 22:54:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623812058; bh=lAapByGGKrXEKHAOvw6+bk4Qdur9QEc4pHmOoDz1BS4=; h=Subject:To:References:From:Date:In-Reply-To; b=FJY8X6vxvdMLEv4JOlw0ZvlfV/A3BprFQKF3ufXUgnZWYJUfcp0Y4I3Q65X5ZtVjC AlEblMjUC8bu10McmCpiPseGeV4f4S0SCs9waj7Dxb4Zn9jEtXI0v27M3SUE8ZLdPT SaxDHY802ON96dXjVjbDOwEh/chJvNg7Nuzg9w8I= Subject: Re: Why doesn't cc -ansi disable conflicting type for getline from stdio.h? To: freebsd-questions@freebsd.org References: From: Kurt Hackenberg Message-ID: <4018acc9-2607-67ed-0327-8a3c9bc647b8@panix.com> Date: Tue, 15 Jun 2021 22:54:14 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4VBy6gdRz4WWJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=FJY8X6vx; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16:c]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 02:54:20 -0000 On 2021/06/14 17:10, Edward Sanford Sutton, III wrote: > Trying to work on properly learning C so following K&R second edition > of C Programming Language. Found in manpage that -std=c89 or -ansi can > be passed to setup a more compatible set of build rules which hid > warnings about how main is defined. > My understanding is that this should also cause getline to not be > defined in /usr/include/stdio.h. Is there a reason that "#if > __POSIX_VISIBLE >= 200809" should trigger as true in there with > -std=c89? Huh. I didn't know about that function getline() as part of the C library. The latest C reference I have is for C99, 1999; it doesn't include getline(). You may have run across dueling standards or something. Posix defines a standard Unix, and apparently also defines a C standard library that's a little larger than the C standard library defined by the C standard, even though Posix doesn't define C. (Yes, that's a little weird.) The boundary between C and Unix has always been blurred a little in practice. It's good to keep the boundary clear in your mind, but you might have to accept some imperfection in software. I suggest you take that getline() thing as a glitch, the kind of thing that shows up in old software[1], and work around it without worrying about it too much. Definitely rename the function in the sample program. As for learning C, K & R is the classic for that, but it's 30 years old. I suggest that you go through that, and when you more or less have a handle on the language, also look at more modern versions of C. There were significant changes in 1999 and 2011 -- not fundamental changes, but some useful additions. [1] C and Unix are 50 years old! That's pretty damn old for software. From owner-freebsd-questions@freebsd.org Wed Jun 16 06:03:38 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4F46A65B894 for ; Wed, 16 Jun 2021 06:03:38 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4ZPP00MBz4jgp for ; Wed, 16 Jun 2021 06:03:36 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 853274E657; Tue, 15 Jun 2021 23:03:35 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <20210616012606.3C77A1183464@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27544.1623823415.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2021 23:03:35 -0700 Message-ID: <27545.1623823415@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4ZPP00MBz4jgp X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-0.29 / 15.00]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 06:03:38 -0000 In message <20210616012606.3C77A1183464@ary.qy>, = "John Levine" wrote: >It appears that Ronald F. Guilmette said: >>More to the point, if indeed each call to write() *is* "atomic"... at le= ast >>in the sense that the given buffer will be treated like an indivisable w= hole, >>all of the way along its journey to some physical device... then why are >>users nontheless being encouraged, still, to "use some form of concurren= cy >>control"? I mean what would be the point of that if in fact write() nev= er >>busts up the hunks of data given to it into separate sub-hunks? > >I think it depends on the device. If I just want to write stuff to a log >file and not get it scrambled, this should do the trick: > > fd =3D open("somefile", O_CREAT|O_WRONLY|O_APPEND); > > /* put some stuff in buf[] */ > flock(fd, LOCK_EX); > write(fd, buf, strlen(buf)): /* O_APPEND ensures it's added at the end = */ > flock(fd, LOCK_UN); Thanks John, but as I noted earlier in this thread, if the data passed to write() in a single call isn't treated as an indivisible whole OR if each of the (mutltiple) processes that are making the calls (using code as you have written above) is maintaining its own separate file pointer, then it isn't 100% clear that what you suggested will actually solve the "garbling" problem. I'm going to try passing all lines up to a parent process which will then be the only one writing to the file, and see if that resolves the issue. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 06:11:08 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 86AEE65B074 for ; Wed, 16 Jun 2021 06:11:08 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4ZZ36zPLz4jtl for ; Wed, 16 Jun 2021 06:11:07 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 0A7E54E657; Tue, 15 Jun 2021 23:11:07 -0700 (PDT) From: "Ronald F. Guilmette" To: FreeBSD Questions Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27578.1623823866.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2021 23:11:07 -0700 Message-ID: <27579.1623823867@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4ZZ36zPLz4jtl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-0.06 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.76)[-0.757]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 06:11:08 -0000 In message Paul Procacci wrote: >This is what I was advocating for. Sorry if that wasn't clear. >It might make sense to provide a visual representation using C pseudo cod= e: >{... snipped...} Thank you Paul. I have the general idea, and I can take it from here. Note that I was -already- having the master/parent process read input and then pass down bits of work-to-be-done to the various "worker bee" child proceses, so I do understand how to code all this up properly. Now I just have to add in some more pipes to pass lines of completed results back up to the parent, in addition to the parent sending stuff down to the children via pipes. Piece of cake. I just hope and trust (and believe) that adding that into my existing code will solve the problem. I think it will. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 06:18:43 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BE4C065BA4D for ; Wed, 16 Jun 2021 06:18:43 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4Zkp6kGZz4kDG for ; Wed, 16 Jun 2021 06:18:42 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id EC5454E657; Tue, 15 Jun 2021 23:18:41 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Why doesn't cc -ansi disable conflicting type for getline from stdio.h? In-Reply-To: <4018acc9-2607-67ed-0327-8a3c9bc647b8@panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27605.1623824321.1@segfault.tristatelogic.com> Date: Tue, 15 Jun 2021 23:18:41 -0700 Message-ID: <27606.1623824321@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4Zkp6kGZz4kDG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-0.29 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 06:18:43 -0000 In message <4018acc9-2607-67ed-0327-8a3c9bc647b8@panix.com>, Kurt Hackenberg wrote: >The boundary between C and Unix has always been blurred a little in >practice. It's good to keep the boundary clear in your mind... But but but...that's no longer necessary now that EVERYTHING is UNIX, right? So if you have a C compiler, and it isn't cross targeting for some embedded sysetem, then you likely have all of the UNIX primitives and all of the standard UNIX anmd POSIX C libraries at your disposal. Didn't a read a few years ago that Windoze had basically absorbed all of UNIX and that it now provides al of the same stuff, via libraries? Or maybe I misunderstood. It certainly seemed consistant with Microsoft's well publicised "embrace, extend, and destroy" philosophy at the time I read that. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 06:26:41 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E4A7265BDB9 for ; Wed, 16 Jun 2021 06:26:41 +0000 (UTC) (envelope-from 4250.82.1d4d20004be8b04.11c3ae653a781d67f5eb0104b0418eb7@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4Zw06vyhz4kTj for ; Wed, 16 Jun 2021 06:26:39 +0000 (UTC) (envelope-from 4250.82.1d4d20004be8b04.11c3ae653a781d67f5eb0104b0418eb7@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1623824801; x=1626416801; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:cc:to:from:date:x-thread-info; bh=RUhLRdazuCG1OilE5PVYWKpAQJd5V9/fz9C05gVpKbA=; b=VXHQYlReNhPxb28hRzLjDXr6+xJWq0m5dZJvw30bxlFx3kXdDesVc3Z0ZzhR/1LN6qisfV3oq2lmoMqUsTUv1GQERUYtMuhwErOM+B+sOypT+hRs574gIPZwzpcodV6KS3yV67Ax0MYsdFwF0V9lvC7jF65VWIvLmcn7Q3ViblY= X-Thread-Info: NDI1MC4xMi4xZDRkMjAwMDRiZThiMDQuZnJlZWJzZC1xdWVzdGlvbnM9ZnJlZWJzZC5vcmc= Received: from r2.h.in.socketlabs.com (r2.h.in.socketlabs.com [142.0.180.12]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Wed, 16 Jun 2021 02:26:35 -0400 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r2.h.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Wed, 16 Jun 2021 02:26:35 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1ltP0T-0003Ge-GH; Wed, 16 Jun 2021 07:26:33 +0100 Date: Wed, 16 Jun 2021 07:26:33 +0100 From: Steve O'Hara-Smith To: "Ronald F. Guilmette" Cc: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? Message-Id: <20210616072633.e4bd29839249465e385bbf6f@sohara.org> In-Reply-To: <27545.1623823415@segfault.tristatelogic.com> References: <20210616012606.3C77A1183464@ary.qy> <27545.1623823415@segfault.tristatelogic.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4Zw06vyhz4kTj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=VXHQYlRe; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d4d20004be8b04.11c3ae653a781d67f5eb0104b0418eb7@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d4d20004be8b04.11c3ae653a781d67f5eb0104b0418eb7@email-od.com X-Spamd-Result: default: False [0.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sohara.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[142.0.176.198:from]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[142.0.176.198:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[email-od.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d4d20004be8b04.11c3ae653a781d67f5eb0104b0418eb7@email-od.com]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d4d20004be8b04.11c3ae653a781d67f5eb0104b0418eb7@email-od.com]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 06:26:42 -0000 On Tue, 15 Jun 2021 23:03:35 -0700 "Ronald F. Guilmette" wrote: > In message <20210616012606.3C77A1183464@ary.qy>, > "John Levine" wrote: > > >It appears that Ronald F. Guilmette said: > >>More to the point, if indeed each call to write() *is* "atomic"... at > >>least in the sense that the given buffer will be treated like an > >>indivisable whole, all of the way along its journey to some physical > >>device... then why are users nontheless being encouraged, still, to > >>"use some form of concurrency control"? I mean what would be the point > >>of that if in fact write() never busts up the hunks of data given to it > >>into separate sub-hunks? Write never divides the hunks of data by position but it does by time. It will write it in a concurrent block but not necessarily in a single operation so other processes can read and write to the file while the write is in progress. Nothing prevents other processes (forked or independent) from writing in the same place and nothing stops other processes from finding the end of the file while a write is partially completed and using that point to start their own appends. Nothing guarantees the order in which multiple processes write chunks out. Where they put it is guaranteed but not when. IOW if one process writes ABC and another writes DEF both at the end of file you might get ABCDEF but you won't get ABDCEF you might also get ABDEF as D overwrites C or even ADCF as D overwites B and then C overwrites E. > >I think it depends on the device. If I just want to write stuff to a log > >file and not get it scrambled, this should do the trick: > > > > fd = open("somefile", O_CREAT|O_WRONLY|O_APPEND); > > > > /* put some stuff in buf[] */ > > flock(fd, LOCK_EX); > > write(fd, buf, strlen(buf)): /* O_APPEND ensures it's added at the end > > */ flock(fd, LOCK_UN); > > Thanks John, but as I noted earlier in this thread, if the data passed to > write() in a single call isn't treated as an indivisible whole OR if each It is. > of the (mutltiple) processes that are making the calls (using code as > you have written above) is maintaining its own separate file pointer, They do. > then it isn't 100% clear that what you suggested will actually solve > the "garbling" problem. John's code will work (it is the standard solution) - provided *every* writer uses it - without the O_APPEND you would need to put a seek to EOF inside the locked section which is the pattern I most often wind up with. -- Steve O'Hara-Smith From owner-freebsd-questions@freebsd.org Wed Jun 16 07:39:29 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A55F965C8A6 for ; Wed, 16 Jun 2021 07:39:29 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4cX062brz4qkd for ; Wed, 16 Jun 2021 07:39:28 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id B1F814E680; Wed, 16 Jun 2021 00:39:27 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <20210616072633.e4bd29839249465e385bbf6f@sohara.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27899.1623829167.1@segfault.tristatelogic.com> Date: Wed, 16 Jun 2021 00:39:27 -0700 Message-ID: <27900.1623829167@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4cX062brz4qkd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-0.29 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 07:39:29 -0000 In message <20210616072633.e4bd29839249465e385bbf6f@sohara.org>, Steve O'Hara-Smith wrote: > IOW if one process writes ABC and another writes DEF both at the >end of file you might get ABCDEF but you won't get ABDCEF you might also get >ABDEF as D overwrites C... Yup. Some of the "garbled" lines I have been getting look suspiciously like the "ABDEF" in your example. > John's code will work (it is the standard solution) - provided >*every* writer uses it - without the O_APPEND you would need to put a seek >to EOF inside the locked section which is the pattern I most often wind up >with. So the O_APPEND by itself isn't enough to fix the problem? I still have to wrap the calls to write() inside some sort of locking code? I'll try both... O_APPEND, with and without locking... but it kind of seems to me that if O_APPEND, by itself, were actually doing what the man page says it does, then that alone ought to be enough to prevent garbling of the output lines. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 08:12:04 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 60A6A65D2F1 for ; Wed, 16 Jun 2021 08:12:04 +0000 (UTC) (envelope-from 4250.82.1d4d20004c2456d.63a659b144b62c0216a3c834299972b8@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4dFb4Rtdz4sWB for ; Wed, 16 Jun 2021 08:12:03 +0000 (UTC) (envelope-from 4250.82.1d4d20004c2456d.63a659b144b62c0216a3c834299972b8@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1623831124; x=1626423124; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:cc:to:from:date:x-thread-info; bh=q6lrP7AfFdfvgCByaM/PB++pPkk4oIGK/jzi7G5uil8=; b=lazPBuD1xQlarXMh3QLsfSjm3dYq/OX2RMnE4KEF7daxk9kidZenWc/KQVUxftdN6dbDw6tLex1TpP57TLP5UUOxqF2j8fXNOOcFdLWJuLgxwob7GOWRAwTZXjn4bmfGBhLKK5mpXbuWLJHRQ9kw61t/9f+X1b7BqvJJ3LRlTz4= X-Thread-Info: NDI1MC4xMi4xZDRkMjAwMDRjMjQ1NmQuZnJlZWJzZC1xdWVzdGlvbnM9ZnJlZWJzZC5vcmc= Received: from r2.sg.in.socketlabs.com (r2.sg.in.socketlabs.com [142.0.179.12]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Wed, 16 Jun 2021 04:12:01 -0400 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r2.sg.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Wed, 16 Jun 2021 04:12:00 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1ltQeU-0003w2-H1; Wed, 16 Jun 2021 09:11:58 +0100 Date: Wed, 16 Jun 2021 09:11:58 +0100 From: Steve O'Hara-Smith To: "Ronald F. Guilmette" Cc: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? Message-Id: <20210616091158.313f9d26a415bf42ee0ebf94@sohara.org> In-Reply-To: <27900.1623829167@segfault.tristatelogic.com> References: <20210616072633.e4bd29839249465e385bbf6f@sohara.org> <27900.1623829167@segfault.tristatelogic.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4dFb4Rtdz4sWB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=lazPBuD1; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d4d20004c2456d.63a659b144b62c0216a3c834299972b8@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d4d20004c2456d.63a659b144b62c0216a3c834299972b8@email-od.com X-Spamd-Result: default: False [0.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sohara.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[142.0.176.198:from]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[142.0.176.198:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[email-od.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d4d20004c2456d.63a659b144b62c0216a3c834299972b8@email-od.com]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d4d20004c2456d.63a659b144b62c0216a3c834299972b8@email-od.com]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 08:12:04 -0000 On Wed, 16 Jun 2021 00:39:27 -0700 "Ronald F. Guilmette" wrote: > In message <20210616072633.e4bd29839249465e385bbf6f@sohara.org>, > Steve O'Hara-Smith wrote: > > > IOW if one process writes ABC and another writes DEF both at the > >end of file you might get ABCDEF but you won't get ABDCEF you might also > >get ABDEF as D overwrites C... > > Yup. Some of the "garbled" lines I have been getting look suspiciously > like the "ABDEF" in your example. > > > John's code will work (it is the standard solution) - provided > >*every* writer uses it - without the O_APPEND you would need to put a > >seek to EOF inside the locked section which is the pattern I most often > >wind up with. > > So the O_APPEND by itself isn't enough to fix the problem? I still have > to wrap the calls to write() inside some sort of locking code? Correct, the O_APPEND just ensures that the write will start at the EOF at the time the write is called. > I'll try both... O_APPEND, with and without locking... but it kind of > seems to me that if O_APPEND, by itself, were actually doing what the man > page says it does, then that alone ought to be enough to prevent garbling > of the output lines. No, in the ABDEF example the ABC process calls write and finds the end of file and sets up ABC to be written there then the DEF process calls write and finds EOF when the A and B have been written out but not C however C gets written between the DEF process finding the end of file and writing D out so C gets written and then overwritten. The O_APPEND guarantee that the blocks are written contiguously starting at EOF is held but nothing prevents the blocks from two writers interleaving and writing over each other. -- Steve O'Hara-Smith From owner-freebsd-questions@freebsd.org Wed Jun 16 08:15:45 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C67065D6D9 for ; Wed, 16 Jun 2021 08:15:45 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4dKr3Qdwz4sjj for ; Wed, 16 Jun 2021 08:15:44 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 27EC84E69D; Wed, 16 Jun 2021 01:15:43 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <20210616091158.313f9d26a415bf42ee0ebf94@sohara.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28133.1623831342.1@segfault.tristatelogic.com> Date: Wed, 16 Jun 2021 01:15:43 -0700 Message-ID: <28134.1623831343@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4dKr3Qdwz4sjj X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [3.70 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[0.996]; NEURAL_HAM_LONG(-1.00)[-1.000]; MISSING_TO(2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 08:15:45 -0000 In message <20210616091158.313f9d26a415bf42ee0ebf94@sohara.org>, Steve O'Hara-Smith wrote: >> I'll try both... O_APPEND, with and without locking... but it kind of >> seems to me that if O_APPEND, by itself, were actually doing what the man >> page says it does, then that alone ought to be enough to prevent garbling >> of the output lines. > > No, in the ABDEF example the ABC process calls write and finds the >end of file and sets up ABC to be written there then the DEF process calls >write and finds EOF when the A and B have been written out but not C however >C gets written between the DEF process finding the end of file and writing >D out so C gets written and then overwritten. The O_APPEND guarantee that >the blocks are written contiguously starting at EOF is held but nothing >prevents the blocks from two writers interleaving and writing over each >other. ACK. Thank you. I'll do both and hope for the best. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 13:17:42 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4C8D0662F1C for ; Wed, 16 Jun 2021 13:17:42 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from mailout.qeng-ho.org (mailout.qeng-ho.org [217.155.128.244]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4m2F336fz3qbJ for ; Wed, 16 Jun 2021 13:17:41 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from arthur.home.qeng-ho.org (unknown [IPv6:2a02:8010:64c9:1::2]) by mailout.qeng-ho.org (Postfix) with ESMTP id 8766D20071; Wed, 16 Jun 2021 14:17:26 +0100 (BST) Subject: Re: Is a successful call to write(2) atomic? To: "Ronald F. Guilmette" , freeBSD Mailing List References: <26258.1623802141@segfault.tristatelogic.com> From: Arthur Chance Message-ID: <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> Date: Wed, 16 Jun 2021 14:17:23 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <26258.1623802141@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4m2F336fz3qbJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@qeng-ho.org designates 217.155.128.244 as permitted sender) smtp.mailfrom=freebsd@qeng-ho.org X-Spamd-Result: default: False [0.55 / 15.00]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.155.128.244:from]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.155.128.240/29]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[qeng-ho.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[217.155.128.244:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.15)[-0.150]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13037, ipnet:217.155.0.0/16, country:GB]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 13:17:42 -0000 On 16/06/2021 01:09, Ronald F. Guilmette wrote: > In message > Paul Procacci wrote: > >> It now reads: >> >> This volume of POSIX.1-2017 does not specify the behavior of concurrent >> writes to a regular file from multiple threads, except that each write is >> atomic (see *Thread Interactions with Regular File Operations* >> ). >> Applications should use some form of concurrency control. >> >> In both cases, it states: "Applications should use some form of >> concurrency control". > > Sigh. The above (revised) verbage isn't my personal idea of unambiguous > clarity. I mean it isn't even clear what -they- mean by "atomic" in this > context. They may intend it to mean exactly what I have been using it > to mean here, but if I have learned anything about Posix, it is that their > documents are sometimes subtle in their use of terminology. (I sustained > some serious verbal abuse on one Posix mailing list some months ago for > my failure to fully appreciate this.) >From Posix documentation on write(2): Atomic/non-atomic: A write is atomic if the whole amount written in one operation is not interleaved with data from any other process. However, only two cases are guaranteed to be atomic: 1) writes to a pipe/FIFO of <= PIPE_BUF bytes See the beginning of the Rationale section of https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html 2) writes to a regular file from different pthreads *within the same process* See https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07 Apart from the first case there is no requirement for atomic writes in Posix when multiple processes are involved. > More to the point, if indeed each call to write() *is* "atomic"... at least > in the sense that the given buffer will be treated like an indivisable whole, > all of the way along its journey to some physical device... then why are > users nontheless being encouraged, still, to "use some form of concurrency > control"? I mean what would be the point of that if in fact write() never > busts up the hunks of data given to it into separate sub-hunks? > > Sounds to me like they are saying "Here, we are giving you this belt, but > we advise you to wear your suspenders also, just in case." More like "we think the builders may have installed the floors in this darkened building, but we suggest a flashlight and safety harness" > This seems goofy on the face of it. The problem is that when Posix first arrived it attempted to codify the lowest common denominator of (then) existing Unix implementations and has grown from that very low base. -- Lebowskisort, aka dudesort, an O(1) sorting algorithm: "Man, the array is cool as it is. Let's go bowling." From owner-freebsd-questions@freebsd.org Wed Jun 16 13:36:25 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 38251663125 for ; Wed, 16 Jun 2021 13:36:25 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from mailout.qeng-ho.org (mailout.qeng-ho.org [217.155.128.244]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4mRr3PTDz3rRv for ; Wed, 16 Jun 2021 13:36:24 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from arthur.home.qeng-ho.org (unknown [IPv6:2a02:8010:64c9:1::2]) by mailout.qeng-ho.org (Postfix) with ESMTP id CD92C20093; Wed, 16 Jun 2021 14:36:21 +0100 (BST) Subject: Re: Why doesn't cc -ansi disable conflicting type for getline from stdio.h? To: "Ronald F. Guilmette" , freebsd-questions@freebsd.org References: <27606.1623824321@segfault.tristatelogic.com> From: Arthur Chance Message-ID: <8033286d-cfb8-59a3-600d-e752f7f963a3@qeng-ho.org> Date: Wed, 16 Jun 2021 14:36:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <27606.1623824321@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4mRr3PTDz3rRv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@qeng-ho.org designates 217.155.128.244 as permitted sender) smtp.mailfrom=freebsd@qeng-ho.org X-Spamd-Result: default: False [-0.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.155.128.240/29]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[qeng-ho.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[217.155.128.244:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.155.128.244:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:13037, ipnet:217.155.0.0/16, country:GB]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 13:36:25 -0000 On 16/06/2021 07:18, Ronald F. Guilmette wrote: > In message <4018acc9-2607-67ed-0327-8a3c9bc647b8@panix.com>, > Kurt Hackenberg wrote: > >> The boundary between C and Unix has always been blurred a little in >> practice. It's good to keep the boundary clear in your mind... > > But but but...that's no longer necessary now that EVERYTHING is UNIX, > right? So if you have a C compiler, and it isn't cross targeting for > some embedded sysetem, then you likely have all of the UNIX primitives > and all of the standard UNIX anmd POSIX C libraries at your disposal. Technically the C standard allows for hosted C environments on any operating system, so there may be a C17 implementation running on an emulation of Multics somewhere. > Didn't a read a few years ago that Windoze had basically absorbed all of > UNIX and that it now provides al of the same stuff, via libraries? > > Or maybe I misunderstood. > > It certainly seemed consistant with Microsoft's well publicised "embrace, > extend, and destroy" philosophy at the time I read that. You're thinking of WSL (Windows System for Linux). With the release of WSL 2 you've got Linux compatibiity (and it's sometimes faster than native Windows code). -- Lebowskisort, aka dudesort, an O(1) sorting algorithm: "Man, the array is cool as it is. Let's go bowling." From owner-freebsd-questions@freebsd.org Wed Jun 16 16:12:14 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25835664955 for ; Wed, 16 Jun 2021 16:12:14 +0000 (UTC) (envelope-from joneum@FreeBSD.org) Received: from toco-domains.de (mail.toco-domains.de [IPv6:2a01:4f8:151:4202::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4qvd5SJNz4h8l for ; Wed, 16 Jun 2021 16:12:13 +0000 (UTC) (envelope-from joneum@FreeBSD.org) Received: from MacBook-Pro.fritz.box (p200300e2b71e9d0089e8be3ea8a97cb1.dip0.t-ipconnect.de [IPv6:2003:e2:b71e:9d00:89e8:be3e:a8a9:7cb1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by toco-domains.de (Postfix) with ESMTPSA id 9E66B3BCAC for ; Wed, 16 Jun 2021 18:12:05 +0200 (CEST) To: freebsd-questions@freebsd.org From: Jochen Neumeister Subject: Problem with i386 jails on poudriere Message-ID: Date: Wed, 16 Jun 2021 18:12:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: de-DE X-Rspamd-Queue-Id: 4G4qvd5SJNz4h8l X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; local_wl_from(0.00)[FreeBSD.org] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 16:12:14 -0000 i just have the problem that no i386 jail runs on poudriere. all amd64 jails do not make problems, only i386. It always aborts with the following message: [00:00:28] Starting jail 114i386-ports. ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap [00:00:28] Error: Unable to execute id(1) in jail. Emulation or ABI wrong. [00:00:28] Cleaning up [00:00:28] Unmounting file systems FreeBSD joneumbox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-07d72396f: Fri Jun 11 07:54:06 CEST 2021     root@joneumbox.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64 does anyone here have a tip? From owner-freebsd-questions@freebsd.org Wed Jun 16 16:47:05 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8463F6655E3 for ; Wed, 16 Jun 2021 16:47:05 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4rgs3B2Yz4nRL; Wed, 16 Jun 2021 16:47:05 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1623862025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=k8VL1DIQi49p2cxsDjTGTBusO+KtOpcOEZr3Wj2lh1I=; b=kawz6Wqf+PB6fmNhanlW+MHjlhQ+uWO3IrsWDuOAotpSwF94Gulbac9C3LnObvLuP09+oJ Y/UkJzdhquPwrq/y5ne5K+n0B89tWyuqLXJ666k/cS0Wm/wqcjQbmFG6lLKDL13DUuBV6y nL3hobozx43YY+dakpkpfo/pw9la/09xkUxLvOHWfQvD9RUhjiyqi50NjCZK7owgkovhta DLKVghMlnaVpGZU6Myxn0SLyMwczuHqT523mKZa75mBQl6s4EalOnuOHxiieyjFwrv5SHc rlhvzRfc26tu+pyxq9Wz2XuOAkjPcGMQniWWlELGYdeEK3vQbGUouDlXl1t6FA== Received: by freefall.freebsd.org (Postfix, from userid 1354) id 474FFF8F5; Wed, 16 Jun 2021 16:47:05 +0000 (UTC) From: Jan Beich To: Victor Sudakov Cc: freebsd-pkg@freebsd.org, freebsd-questions@freebsd.org Subject: Re: pourdiere broken for i386 jails ? (or maybe not poudriere per se) References: Date: Wed, 16 Jun 2021 18:47:01 +0200 In-Reply-To: (Victor Sudakov's message of "Sun, 13 Jun 2021 16:25:17 +0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1623862025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=k8VL1DIQi49p2cxsDjTGTBusO+KtOpcOEZr3Wj2lh1I=; b=XXHT1EqhGNlRui949Z57hZEFT66JfnsfZAhbZ4ONOgasrrbkMJiDP8U/TktTGx5b/BWibp /9rqgMoiO8QXpy/HBbdBOnyn9DirUSkHRq6yr4nBJX0Ieqk8o2dMTLi0IMdhOfNbcWfW+s 12WEGutbDU9YK8EUvY5G1826432DITlai2KkO7NvV9DF+7WlK0L3rvCRmVlkQVlqq77QCW QUXXZm5+2PRSGuMNLuI8sQHF7EfkJBIKuTD4rd3We9BCb7/OuUuugTIfKd3M3/EyMEjXIg unzX24NdlOxrzeaalgRnSy6LdQrjs4imzRM02PUjXjsgVO1Kz7MDIcSnR6xoZg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1623862025; a=rsa-sha256; cv=none; b=ih7dCBZpPHy8DHfbyI8Ucuo6h/R9KEZ41lJU2ZJY4aTYfzzVqAYhInAmUhLF+OSCVMOkAa XTaIvIaSbQs+nGyfng/Tj8VggBb9Kt9Xu5F+pznSmvAWG9TCDiI0XJ6vb9E5EoLzH4AOsG 85JYGJJJB52Yw4a5hfxhVu5AR5dkup0KF1Tmbl5lDCY3oVxsT4QaBB0aHZR+dWg+tB0qpt NG1PzHDfZ1Q8zIhqFU5I6I4lrJnoShbbHQsuF18JRiD7GB/+nGHmfle+3odFtmRjTaxtXb FHfpeVNkwjJI73YMCDwY3GubROPEanyrB39iJ5om8YVcY2buZRy2KN0lYZQ8zA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 16:47:05 -0000 Victor Sudakov writes: > Dear Colleagues, > > Suddenly poudriere and poudriere-devel stopped working for i386 jails. I > can't say when exactly this happened but probably after a recent > freebsd-update. > > root@svn:~ # uname -rm > 12.2-RELEASE-p7 amd64 Maybe try asking on ports@ list. 11.4/12.2/13.0/14.0 i386 jails work fine for me on 14.0 amd64 host. IIRC, pkg.freebsd.org for i386 are built in a similar way but it's hard to confirm because the host arch doesn't show up in build logs. > root@svn:~ # file /poudriere/jails/114i386/libexec/ld-elf.so.1 > /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared > object, x86-64, version 1 (FreeBSD), dynamically linked, stripped I wanted to suggest to re-create the jails with "-a i386" but... $ file /poudriere/jails/*i386/libexec/ld-elf.so.1 /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped /poudriere/jails/122i386/libexec/ld-elf.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, stripped /poudriere/jails/130i386/libexec/ld-elf.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 (1300139), stripped /poudriere/jails/main-i386/libexec/ld-elf.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 14.0 (1400023), not stripped See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256652 From owner-freebsd-questions@freebsd.org Wed Jun 16 16:49:51 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 505A26659E5 for ; Wed, 16 Jun 2021 16:49:51 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4rl30g3Gz4nZd; Wed, 16 Jun 2021 16:49:51 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1623862191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5vybYXLBS+4TYHK+chKJ1UrqFz0b1FaUIZQyzrS/5L8=; b=bvmACDpB1/DK4gnhLHy7OgtAlDBYVqzkvc1KiRbkXaWyeqRs7qh0NY/ZNNkPGMtj7ZCwcW +BaoEZdxR2/5sOGr8OzKjNm78mbTYIaEBft9qpRyndn+IeZybduZtnUfwmrwD/wmtY7H9j ltLJW+CDfDc/r2lcq+yqlK4enPF3dsXuNJVOxf3D6nY4ObbLsZpYkTr2umvA8J0j7QTBue /hrwIgRCI3jFJ+dAL7N5QHMK7gIOGjqJZ53n3Backj4O5m/hCwbEEuQs8Eo/+hemJmU1d+ TbZhYBFV267KClEPFyLMi89DiI5Rn+iI5ttPJDNXTtH/BFh+xCtqHKdpSng2Vw== Received: by freefall.freebsd.org (Postfix, from userid 1354) id F2615F9EB; Wed, 16 Jun 2021 16:49:50 +0000 (UTC) From: Jan Beich To: Jochen Neumeister Cc: freebsd-questions@freebsd.org Subject: Re: Problem with i386 jails on poudriere References: Date: Wed, 16 Jun 2021 18:49:47 +0200 In-Reply-To: (Jochen Neumeister's message of "Wed, 16 Jun 2021 18:12:05 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1623862191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5vybYXLBS+4TYHK+chKJ1UrqFz0b1FaUIZQyzrS/5L8=; b=aEUlbJOENap74tJewdDMOy0qb5MeRvhe+NthEptpYw+Fyge4E9K6yOHiNIbLdbciBJarb8 e0SWUs88mnDOPb+3VRzZox5PZSxIdJfg6ArcRna7lphaU7QrAouwolUUBrmAYKMzo6NkQP i3kImCuHE5r8u94BNBOD+4Hd+S5chV4cnSW7a3qwo+VI/GIMyzP1YRUU4tihW0mWuCuARK omU6XL/uyLmfLLk9Zkomah52jIWOL6s4xTYjLTlCUsnynCKpo2OqlTXi6DdLNUdVpl9609 0gMdzBpclem9hKqujLm40Qokt2atIXvRQP27Zpnab4Sk8rP1BkE1MYPYEBLGUA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1623862191; a=rsa-sha256; cv=none; b=nP15bs7Mg0d7MT8x4iPqKw7BcA2iM7id3QSiBGyVkgz1CRMH31LkOnD3FdUnv45p/o4rvb cWGPhrsDNm65A1y65nBpTJR9OWD8vxqPyzZrjmMFJW+JyS3I9DCvWJA1tOSnh/Huu+nAxZ oGtOFY2nR2BTYxYulq4/3a/ehBfYPb7ljaeg70ntZhQ0az3qoPCj7qSYDozyxsPaquf9Ho m/dOvGnb60pT1Wrdemxkz0Vj2fy8ZhrmuSbpS+Vs+dMP+ykUsmikORE+g9HNXZ4opopuG1 jbPb/zYz4B8E6yYfD71e9ZzDlClwQkLWrNBmAWTSZcJPb1OK+PiKzYVobIzCdw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 16:49:51 -0000 Jochen Neumeister writes: > i just have the problem that no i386 jail runs on poudriere. all amd64 > jails do not make problems, only i386. > > It always aborts with the following message: > > [00:00:28] Starting jail 114i386-ports. > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > [00:00:28] Error: Unable to execute id(1) in jail. Emulation or ABI wrong. Likely https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256652 From owner-freebsd-questions@freebsd.org Wed Jun 16 17:02:14 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 61498665C33 for ; Wed, 16 Jun 2021 17:02:14 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4s1L29x8z4pHW; Wed, 16 Jun 2021 17:02:14 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1623862934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=RF1sXAN4ZnE6xY1q3mwktyVyOT24LBqCExPP+weG3Ws=; b=A8OScqGzv0MINZJVF5tBaxKgBVYVvFgT/5nJ9JmMvG0Us6CkABKValwyT4GOVWeaQVVoWz I1jMOaJNLn7mnRGmXLKDUmq0P/H5hAvtjNkieplBVN7fU0C56qdyAGGsi8e7/JZXK5ncHV IhpgyYO58bQddFVUWxD3kHZtCUrGFrvkrOG0Ibh/HXID9OUOiEvjY73z7R3qUXHXLvZNM3 ZaHnjEOHWyQRgEbPB+aoKLErz/4MP0hcYyJTekb8RsuE54djal+H1gAd66gsv76F+KM/Al 4MJmeVV6HhLu1D+ZKC7/5vbhUqg4vHUQhCAdiqSLjGxG2sHack/2gUkhRRxKkQ== Received: by freefall.freebsd.org (Postfix, from userid 1354) id 2EF46FAE5; Wed, 16 Jun 2021 17:02:14 +0000 (UTC) From: Jan Beich To: Victor Sudakov Cc: freebsd-pkg@freebsd.org, freebsd-questions@freebsd.org Subject: Re: pourdiere broken for i386 jails ? (or maybe not poudriere per se) References: Date: Wed, 16 Jun 2021 19:02:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1623862934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=RF1sXAN4ZnE6xY1q3mwktyVyOT24LBqCExPP+weG3Ws=; b=ut5iz0H5GLiNemyznqRSMCIXGK1hsrxm6NBnA9/fTMc/9MHFq2+CzSAWMrAt/fVbhceTde PCQLkvw/lb59jAOd5j0kycCPhhxjjkyWAvMq5FY91wUNOjjxexXYG3rrQk+4PgKmr+yvl3 hqACm3KipncQ0zST0XmmhRBcmPLpi1Jv4LOPydFpsUOoPvm5vMO+CTwGlhE96wqq16xbjm oMGXUY0BTr5DlQEXL3Xima33MxyZ83o09gNhWoCMcF1IzBYy1Nd8qnCDO6cEqaBH79bKWO Z4GrMS5StWn+Mkk/leDBYN7neKfVUNJyYefM2vrDzcY/846YDn6v+K1ekXr0jg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1623862934; a=rsa-sha256; cv=none; b=Rmn7FA6rHhtYDxtAjnN3HZVKxHYTsHJn57lOkvMns+f38MRtpuj/ABqirBEW93tfBt2bD5 7j9MH10ESMhyM8Ybq5Fkfl7a43bjOHEK0DWUny6KIESFcMHTk49kmoWstdJIitkde0oVQF q8OVmNCMRRZa/TNWnHhVedAL7ns7WvWm2haJp2GvJFM82lpAlNL5sY7q0ncE+zwn6iuFz4 arHEwc0fTjfzK+2IYhz6vWcwneuI9hS4NvHGX/CSb8b8bGjdlb6dTciiJ8HwNtyDlJe7BV KUwRgJoRjZYtYkIyJPFtO71VrtHALAjx/C4zU4SC4U1ULjgs5ivmFlVAYxoimQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 17:02:14 -0000 Jan Beich writes: >> root@svn:~ # file /poudriere/jails/114i386/libexec/ld-elf.so.1 >> /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared >> object, x86-64, version 1 (FreeBSD), dynamically linked, stripped > > I wanted to suggest to re-create the jails with "-a i386" but... > > $ file /poudriere/jails/*i386/libexec/ld-elf.so.1 > /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped To clarify, my 114i386 jail only became mixed 64-bit after the recent freebsd-update, performed while replying to Victor's mail. It ran fine for months before that, including past freebsd-update runs. From owner-freebsd-questions@freebsd.org Wed Jun 16 22:07:08 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 02CB7644D4A for ; Wed, 16 Jun 2021 22:07:08 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G4zn71flsz3wFn for ; Wed, 16 Jun 2021 22:07:06 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 326984E657; Wed, 16 Jun 2021 15:06:59 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Why doesn't cc -ansi disable conflicting type for getline from stdio.h? In-Reply-To: <8033286d-cfb8-59a3-600d-e752f7f963a3@qeng-ho.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31516.1623881218.1@segfault.tristatelogic.com> Date: Wed, 16 Jun 2021 15:06:59 -0700 Message-ID: <31517.1623881219@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G4zn71flsz3wFn X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [1.70 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 22:07:08 -0000 In message <8033286d-cfb8-59a3-600d-e752f7f963a3@qeng-ho.org>, Arthur Chance wrote: >> Didn't a read a few years ago that Windoze had basically absorbed all of >> UNIX and that it now provides al of the same stuff, via libraries? >> >> Or maybe I misunderstood. >> >> It certainly seemed consistant with Microsoft's well publicised "embrace, >> extend, and destroy" philosophy at the time I read that. > >You're thinking of WSL (Windows System for Linux). Yes, apparently. (I'm reading the Wikipedia page on that now. Thanks for giving me the name of the thing, so that I could google it.) I'm sure that this "WSL 2" thing is swell for some projects, but for me personally it just looks like more lipstick on the pig. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 22:17:15 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C471645CEC for ; Wed, 16 Jun 2021 22:17:15 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mail.sermon-archive.info (sermon-archive.info [47.181.130.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4G500p2Qmdz4SQv for ; Wed, 16 Jun 2021 22:17:13 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from smtpclient.apple (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 4G500g3s32z2fjQ4 for ; Wed, 16 Jun 2021 15:17:07 -0700 (PDT) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Is a successful call to write(2) atomic? Date: Wed, 16 Jun 2021 15:17:07 -0700 References: <26258.1623802141@segfault.tristatelogic.com> <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> To: freeBSD Mailing List In-Reply-To: <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> Message-Id: <331B1E28-0643-4F85-8682-C2C04235C6BF@sermon-archive.info> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Virus-Scanned: clamav-milter 0.103.1 at mail X-Virus-Status: Clean X-Rspamd-Queue-Id: 4G500p2Qmdz4SQv X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bc979@lafn.org designates 47.181.130.121 as permitted sender) smtp.mailfrom=bc979@lafn.org X-Spamd-Result: default: False [2.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.999]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[47.181.130.121:from]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[lafn.org: no valid DMARC record]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[47.181.130.121:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5650, ipnet:47.181.128.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 22:17:15 -0000 My approach to this problem was to create a daemon that listened to a = named pipe. It then wrote the data to the file. This approach has the = advantage that the calling process is not waiting for the daemon to = complete. In my case, the data was retrieved form a database by the = daemon so that the calling process only had to send a unique id for the = specific record. However, I have also used this approach to send email = and the calling process had to send the email text as well as the header = info. The text messages were fairly short so didn't run into any size = limits on the pipe. -- Doug From owner-freebsd-questions@freebsd.org Wed Jun 16 22:39:57 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2ADCE6465E2 for ; Wed, 16 Jun 2021 22:39:57 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G50W02HLqz4WW0 for ; Wed, 16 Jun 2021 22:39:55 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 30B9D4E680; Wed, 16 Jun 2021 15:39:55 -0700 (PDT) From: "Ronald F. Guilmette" To: freeBSD Mailing List Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31697.1623883194.1@segfault.tristatelogic.com> Date: Wed, 16 Jun 2021 15:39:55 -0700 Message-ID: <31698.1623883195@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G50W02HLqz4WW0 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [1.70 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 22:39:57 -0000 In message <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org>, Arthur Chance wrote: >>From Posix documentation on write(2): > >Atomic/non-atomic: A write is atomic if the whole amount written in one >operation is not interleaved with data from any other process. > >However, only two cases are guaranteed to be atomic: > >1) writes to a pipe/FIFO of <= PIPE_BUF bytes > >See the beginning of the Rationale section of > >https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html > >2) writes to a regular file from different pthreads *within the same process* Ohhhhhhh! Thank you for fishing all of this info out for me! It certainly puts a different complexion on the whole matter. >Apart from the first case there is no requirement for atomic writes in >Posix when multiple processes are involved. Yes. Got it. Thanks. And to make matters even slightly MORE annoying, here on my FreeBSD 12.2 system it seems that PIPE_BUF is defined in to what I consider to be an unfortunately low number... obviously a relic of ancient times, i.e. 512. (Some of my output lines are quite likely to exceed this.) The only reason I mention that is because I've just tried changing my code so that the FD (#1) gets O_APPEND set on it at startup time and then the calls to write() are wrapped in calls to flock() just as John Levine and others suggested. Result? Output is still garbled. Thus, I am off to pursue plan C, i.e. passing completed lines up from the "worker bee" children to the master/parent process which will then be responsible for doing all of the actual writing of lines to FD #1. I had hoped that maybe I could do this simply and just have a single common "up" pipe to carry completed lines from the children to the parent, but because POSIX only assures me that lines up to 512 bytes may be written atomically to that pipe, and because some of my output lines may exceed that, I guess that I have to use separate "up" pipes for -each- child process (and then make calls to select(), within the parent, as was suggested here, and having the master read from whichever ones of those have data available at any given point in time). Anyway, I'll be trying that next. The one really odd thing about all of this is that I already have, and have had, for a long time now, *many* programs that I've built and that I have been using, also for a long time, that follow this same general model, i.e. a parent a a lot of "worker bee" child processes where each of the children, after completing a work item, does itself write a single line of output, and *those* programs have all seemed to work flawlessly (i.e. no output garbling) over a long period of time.... HOWEVER they are all using the stdio functions to write to stdout, rather than calling write() directly to write to FD #1. I only changed *this* one program of mine to call write() directly because I've been perpetually worried that having a lot of independend child processes all writing to their (shared) stdout in a totally uncoordinated and asynchronous manner was just asking for trouble. But now, instead of -avoiding- trouble (by switching from calling stdio functions to making direct calls to write()) I seem to have possibly created trouble for myself instead! Obviously, I have no good explanation for this, but I do think that before I try anything else I may just try changing the child processes in this program so that the child processes call fwrite() rather than write()... just to see if that makes any difference. I can't see any clear reason why using fwrite() rather than write() could, would, or should help, but what do I know? Meanwhile, later that same day... OK, so I tried swapping out calls to write() to call to fwrite()... Result: Some output lines still garbled. So I'm either getting bitten by the non-atomicity of {f}writes or else I've just got a loose pointer in my code somplace. I will be checking both theories and following up here with more results, when and as I have them. Meanwhile, my thanks to everyone who has chimed in. Regards, rfg From owner-freebsd-questions@freebsd.org Wed Jun 16 23:12:59 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0865964716F for ; Wed, 16 Jun 2021 23:12:59 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G51F62cB0z4YnH for ; Wed, 16 Jun 2021 23:12:58 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G51F53Hq6z4925 for ; Wed, 16 Jun 2021 19:12:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623885177; bh=3gl4kE5u+dpnCPphl/8n0eEAAGSWwdwVvu7e5QDgFqo=; h=Subject:To:References:From:Date:In-Reply-To; b=Hj28Ck8Tfl0RxZrSqKSu00UkLrk5DEyf1oR2V/uM9GNdiuobJrxRiQXstOR2X/KnL laQ16H24H9rhI9wsMNNjV2fkbGfvVuD6Mit7KoGGSEhduw+cCyhuhrH7TsNU65vXou I45E4DMQfeUVE/kqnoRKtkWf5OlQlfyChn8pz890= Subject: Re: Is a successful call to write(2) atomic? To: freebsd-questions@freebsd.org References: <31698.1623883195@segfault.tristatelogic.com> From: Kurt Hackenberg Message-ID: Date: Wed, 16 Jun 2021 19:12:54 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <31698.1623883195@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G51F62cB0z4YnH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=Hj28Ck8T; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-2.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; DKIM_TRACE(0.00)[panix.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 23:12:59 -0000 On 2021/06/16 18:39, Ronald F. Guilmette wrote: > The only reason I mention that is because I've just tried changing my > code so that the FD (#1) gets O_APPEND set on it at startup time and > then the calls to write() are wrapped in calls to flock() just as > John Levine and others suggested. Result? Output is still garbled. John Levine's sample code opened and closed the file around each write. Here is that code: fd = open("somefile", O_CREAT|O_WRONLY|O_APPEND); /* put some stuff in buf[] */ flock(fd, LOCK_EX); write(fd, buf, strlen(buf)): /* O_APPEND ensures it's added at the end */ flock(fd, LOCK_UN); Since you only open the file once, you should seek to end of file before each write, as somebody else pointed out. You should do that seek, and the write, while holding the file lock. That is: lock file seek to EOF write unlock file Does your code do that? The reason, of course, is that some other process could move end of file out from under you while you do not hold the file lock. > The one really odd thing about all of this is that I already have, and > have had, for a long time now, *many* programs that I've built and that > I have been using, also for a long time, that follow this same general > model, i.e. a parent a a lot of "worker bee" child processes where each > of the children, after completing a work item, does itself write a single > line of output, and *those* programs have all seemed to work flawlessly > (i.e. no output garbling) over a long period of time.... HOWEVER they > are all using the stdio functions to write to stdout, rather than > calling write() directly to write to FD #1. Those C library functions buffer the I/O operations within the user-mode process. The system calls don't do that. That C library buffering could change the internal details of concurrent access. > OK, so I tried swapping out calls to write() to call to fwrite()... > > Result: Some output lines still garbled. No surprise. You should lock the file, seek to end, write, unlock. From owner-freebsd-questions@freebsd.org Wed Jun 16 23:18:24 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 73B98646C4F for ; Wed, 16 Jun 2021 23:18:24 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G51MM4N4zz4Ytg for ; Wed, 16 Jun 2021 23:18:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 7C09F4E657; Wed, 16 Jun 2021 16:18:22 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31903.1623885502.1@segfault.tristatelogic.com> Date: Wed, 16 Jun 2021 16:18:22 -0700 Message-ID: <31904.1623885502@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G51MM4N4zz4Ytg X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [1.69 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.99)[0.992]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 23:18:24 -0000 In message , Kurt Hackenberg wrote: >Since you only open the file once, you should seek to end of file before >each write, as somebody else pointed out. You should do that seek, and >the write, while holding the file lock. That is: > > lock file > seek to EOF > write > unlock file > >Does your code do that? Nope. I'll give it a try. Thanks! >The reason, of course, is that some other process could move end of file >out from under you while you do not hold the file lock. Sounds entirely plausible. Regards, rfg From owner-freebsd-questions@freebsd.org Thu Jun 17 00:21:04 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2535D648215 for ; Thu, 17 Jun 2021 00:21:04 +0000 (UTC) (envelope-from Norman.Gray@glasgow.ac.uk) Received: from hillend.cent.gla.ac.uk (hillend.cent.gla.ac.uk [130.209.16.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G52lf5dytz4c6k for ; Thu, 17 Jun 2021 00:21:02 +0000 (UTC) (envelope-from Norman.Gray@glasgow.ac.uk) Received: from cas08.campus.gla.ac.uk ([130.209.14.165]) by hillend.cent.gla.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1ltfmG-0000n1-GE; Thu, 17 Jun 2021 01:21:00 +0100 Received: from cas07.campus.gla.ac.uk (130.209.14.164) by cas08.campus.gla.ac.uk (130.209.14.165) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Jun 2021 01:20:59 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.50) by cas07.campus.gla.ac.uk (130.209.14.164) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 17 Jun 2021 01:20:59 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PGFDrXvaBhjJHQVTQ21xWQKFGivja4bso5MnhCpqx+cNECus3W9WKUAy3/HFwsBd3rONtFRfRCRPb+XXYHHVQ31fJSl2zAN6b8B5w0/xeGA/ZQVUfezmoNbhVGOZSBiKMZ0HtmoFJW21Dvt+HjoSgvk0AUPDTefYcPdHLzFTeBW5Sg1QN7C+i9DYZi5jXCv8xz7aFmWf2aMOuBpWqht2jTp2JFusaeK8slJLhgxaWVBbk5HyQ+d7jvT/kNEkONf3UxHgzqWX0KMavWwFALBT2YndnCL7vf3i3E5WUDdLpvG59OwoA2cqt0pH09aTu4sSeNCRkhbZrU/+QliBvPJcxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h9D1vEvtQ+8JrU9jOX3NIZU6neVGuxzblU3biuJyYxg=; b=Ttb/WqC3XqpSJiVTF6y9SzcugExD865m/lpLvBxIghjYseKRsG3UK+q0qd61cNSEhgm4DSz3Ea8xK+kgIW0Mwhct0ULnqaUWxdFvNs4K447Tn1lnmkFvMK4Bh/acxrUxRNOjVIgWzNIgEh5I9XQRJ5blv7os5oD4GAVH3solLAxa/NCFtOUhhgxBbUDeDWI1yYh+wFbpjWxihf45b8wDzsBKrsuvuJE6wKRPS8f743IlbjH1V3oVD3FStd0I78akgsckItdVP54Vxc6lKcRAHeHAAguuRpdVustV5gMkPbxnrP56Lce2Yhi3Zy8CDvckJ4qzpMq6mLMwvq8z2HDu5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=glasgow.ac.uk; dmarc=pass action=none header.from=glasgow.ac.uk; dkim=pass header.d=glasgow.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gla.onmicrosoft.com; s=selector2-gla-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h9D1vEvtQ+8JrU9jOX3NIZU6neVGuxzblU3biuJyYxg=; b=OK29U0/JTxlUHZ1metxAxCdsrNAk9TkR06ODErzKh2FmMw1Ar8Rui32loAMvvtAZAM0ybJpR2XrYNhktjPrBv2xPrfbqq/S1a72+SLDxR1N5FAJ4Gm+xS4W06GwmVgfGSdblInTMdlHN+h/YHw/U5PNSs5wEozlA3dvUQNkUPyU= Received: from CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:d4::7) by CWLP265MB3266.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:e3::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.24; Thu, 17 Jun 2021 00:20:59 +0000 Received: from CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM ([fe80::977:cd20:64d7:e0bf]) by CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM ([fe80::977:cd20:64d7:e0bf%4]) with mapi id 15.20.4242.018; Thu, 17 Jun 2021 00:20:59 +0000 From: Norman Gray To: "Ronald F. Guilmette" CC: Subject: Re: Why doesn't cc -ansi disable conflicting type for getline from stdio.h? Date: Thu, 17 Jun 2021 01:20:58 +0100 X-Mailer: MailMate (1.14r5769) Message-ID: In-Reply-To: <31517.1623881219@segfault.tristatelogic.com> References: <31517.1623881219@segfault.tristatelogic.com> Content-Type: text/plain; format=flowed X-Originating-IP: [81.2.70.164] X-ClientProxiedBy: LO2P265CA0370.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::22) To CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:d4::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [130.209.150.74] (81.2.70.164) by LO2P265CA0370.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Thu, 17 Jun 2021 00:20:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ab9689d3-7228-4a5b-a39f-08d93125c809 X-MS-TrafficTypeDiagnostic: CWLP265MB3266: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3vGi2jrr4gShOy3kVCI1pbPIgb0CeHSUiDskzTizd9OLUS/WHDSXWr+smYgyod80wScpl3W1WDTvpme7D+UbYUXoJl8buKIbDtQeLWWSGsNkfV/io/rAgrbvBnsX4VmskDnNk+YeyqT4YmjY8RDqh0QlMV4Z72Cgtj0/RyKT99biq2m+kmI/2b7ADXSrViERxIOYvFeq1IwDBmekc+ThZ/vgxLRFUGmMnuIFVAFllte2urrhBa2vMTpg7MwMDSw73gh8aPeg1JTwn1hm+lMWXHfBcpBegC5EZFol2KFY2ReejEAytUqXvB0bJ0ghwQwQmgrSAK57YUXyxzqje2tod3otdiXlZY6MRbvAiW0LAwBytxrkq+V+ssmLFG8LMMGXBXEZ80bfIVLcgQ2PISPN6XVHOHeZXz2hkIIBeP5+p+g5jHz+sj1PbaIVKWtZX6xCPbLepQ75gZ9/JEYl1wXZe7vpDne46GJm03uNjmqAj5HUJqwXTl9lUTWufE5kR01hMi+hpJJ+Q4Y90MAZ32PsVmVVbcm6T8m3RIIZZ2Eev+whEFzTDogM5po8Z2DWf0EpLRONvLN/fPnaVx7VxkkEkhBPhAr52HTVxcKkXQDiB8pVAedsgxrFNuuyM8xCxzSGo4WeVYkcWCtK9+fwaXsOGcxlaWCub4z5t/Omg1CpygThEDdeFrONaqBtxf4VEQlXA0+ytuAUknEl6J2pv/9oqovgZUkSg4vgxYaCvTyNkPG6AQyMs7hjA+RA6+puKEtCCktWxf+TZKjVCnSvsqmyvI8tyZTRTigft0Ad0wRP5K4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(366004)(39850400004)(396003)(66946007)(66556008)(5660300002)(26005)(66476007)(4326008)(966005)(316002)(478600001)(16526019)(186003)(8676002)(6916009)(6706004)(53546011)(786003)(16576012)(8936002)(36756003)(44832011)(956004)(33656002)(86362001)(2616005)(83380400001)(38100700002)(6486002)(2906002)(78286007)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?3v03VMpTyYyc5qcX3bABjHxeVdttA9viYQpSyhDADLNnIdPyWGFuRjrAQPep?= =?us-ascii?Q?Z6lSueFjYm7InaPXUHIWQUvTE0TUH8g+Q+aFAsVTd+rzTyS1D79VA6KXEvP/?= =?us-ascii?Q?b/CXCumSLbiZ066nsU9W+qcmoo+znnYyYkuFQkGvHCN7l6G84jlQuCmOT6/X?= =?us-ascii?Q?sgSUQlWVrpaU7iz9F37Zs0mw2xUUx5cYQN7ZqjXsidzxZqOIdGG00A8GaZCY?= =?us-ascii?Q?VTqpFyvLkLprcrJB3h1bWehOg2zTSUhaKYuhz+LAjkliw08RMDy0zkZ0WH92?= =?us-ascii?Q?LDyxXICSmmNBjxribjkmaeYPpyFCkC3S/faf8Zymf7PoSUzOuu4oOGNEwHZn?= =?us-ascii?Q?1YT8wKe0pcUJSQEGEizfnji19ERS91O+uYvTlDOrp9ne95bHoj9M6MvXOV8L?= =?us-ascii?Q?zABVPtQtFMSQNqkRTiJDnto2uybDhbglKgIFyfnWdjKH8/E3Y8wytPALyJSz?= =?us-ascii?Q?drHYo5Y9Nndb/zsgKTGW6p+nb/IykVqyAN7PFl/ZF1Y0bi+8ULaVlbHEyjvb?= =?us-ascii?Q?7p1I8awaISLNz2r2Y/T29w+bf7ROSX917BrU7rjOUaGhK2gTtES1rgM79UwP?= =?us-ascii?Q?nFYUcWIfdPUqsReZueTzFi1W81Hx0e5SUG5H7Uk1pVs+Q3KTQzBGvBPm7Lj6?= =?us-ascii?Q?37Ii1iE/VenqWHCNUW2hAnWc4eGOW/Eg79yEPtRGRdbbKwQHFhoxi642z6Z+?= =?us-ascii?Q?4++0e7n/qSQKtXobOclkl9K2ce2xyh52NBGW6EdhvAgKdH2MnRMY2EJIQquJ?= =?us-ascii?Q?IDYj5wcqTv1QPv8bCpGTU28HoSQi5NcHuEHq3bV/W27DlAHwGz34fzth92qG?= =?us-ascii?Q?JzDyMEMk9cK79F/2q09JhOgTojF6YyKQ0y/lk6kAK2WioXWHz+4wada5GGSK?= =?us-ascii?Q?vwHkXasHT6sRbwFiqMFkxA/Apx1hKcG1cub4CIyhB0cuLQkACZ/TRurXOdCl?= =?us-ascii?Q?XEx532aeLJhvLNCgjm+dRWiH9p3DSr6upXbJPCIzIHnQ665hv28OvnuqZqNL?= =?us-ascii?Q?9m9KhAOIfUqFlHszoi7valuMchCHHZO8+3K9ewT7VQL0dEISmF65B1APbehe?= =?us-ascii?Q?070CCjGTSlzFptBA2aHMQYVODOYpJcAcgQ5oWf8MDLMuDCMKwwbH76vm82zQ?= =?us-ascii?Q?8dW3QpQUcmgP0zDuG53JvhDUYyqLjEKg5Qs01nceTk1ZDwFCJ+zGuyLvYxG3?= =?us-ascii?Q?DuOZCj3JLldMXkEP/0YayGHujjsosJqseKc/BKfdIfODvWcnxMZiZizb01F3?= =?us-ascii?Q?jlSq7T3uuVzH4WyJueob74XjuszIFNdIHXcKvcX2SSmKGN0kjq2+J6cT61mI?= =?us-ascii?Q?pSrCKlGCI1Vn7UViK8XqfpFQ?= X-MS-Exchange-CrossTenant-Network-Message-Id: ab9689d3-7228-4a5b-a39f-08d93125c809 X-MS-Exchange-CrossTenant-AuthSource: CWLP265MB3361.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2021 00:20:59.0824 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6e725c29-763a-4f50-81f2-2e254f0133c8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JfRg6bKz7szkjMpz4dadyWqSAXyPhwZSrrkuJ0gpLdCrwfogR6mDbtrWL117xj6vQ1pOGFQkdBoUhUHIhYPCtz2JQx6m9czIwBXpouKkrOM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP265MB3266 X-OriginatorOrg: glasgow.ac.uk X-Rspamd-Queue-Id: 4G52lf5dytz4c6k X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gla.onmicrosoft.com header.s=selector2-gla-onmicrosoft-com header.b=OK29U0/J; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=none; spf=pass (mx1.freebsd.org: domain of Norman.Gray@glasgow.ac.uk designates 130.209.16.102 as permitted sender) smtp.mailfrom=Norman.Gray@glasgow.ac.uk X-Spamd-Result: default: False [-2.20 / 15.00]; RCVD_TLS_LAST(0.00)[]; R_DKIM_ALLOW(-0.20)[gla.onmicrosoft.com:s=selector2-gla-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[130.209.16.102:from]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:130.209.0.0/16]; DMARC_NA(0.00)[glasgow.ac.uk]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[130.209.16.102:from]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gla.onmicrosoft.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:786, ipnet:130.209.0.0/16, country:GB]; RCVD_COUNT_SEVEN(0.00)[7]; MAILMAN_DEST(0.00)[freebsd-questions]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 00:21:04 -0000 Greetings. On 16 Jun 2021, at 23:06, Ronald F. Guilmette wrote: >> You're thinking of WSL (Windows System for Linux). > > Yes, apparently. (I'm reading the Wikipedia page on that now. Thanks > for giving me the name of the thing, so that I could google it.) > > I'm sure that this "WSL 2" thing is swell for some projects, but > for me personally it just looks like more lipstick on the pig. Apropos of not very much, I'll chip in at this point to say that WSL2 is interestingly and unexpectedly good, in an 'it just works' sense. Example 1: I recently taught an 'Introduction to unix tools' course, with a mixed-OS class. Unlike WSL1 or (OMG) cygnus in previous years, once the WSL2 students had been shown how to enable WSL2 on their Windows machines (admittedly not trivial in every case), they were officially No Problem, being less of a drain on lab demonstrator time than the students with random Linux distributions. Example 2: In a recent project, I was collaborating with a firmly Windows-based colleague on an Arduino project, where the build toolchain used slightly fragile Makefiles invoking (on their machine, via WSL2) the Windows install of the Arduino cross-compilers. This turned out to be massively less of a problem than I expected it to be. It's not bulletproof, and there's non-zero scope for filesystem-confusion -- at one point, if I recall correctly, the Makefile and the compiler turned out to have different ideas about what 'the home directory' was, and where ../ went from there (oooh, the hilarity) -- but these were at the level of unix-to-unix porting problems, rather than anything more hair-pullingly entertaining. I think it's possible to get X running on WSL2, but that's only for masochists. MS are not going to help you with that at all. It all ends up feeling agreeably old-skool. Best wishes, Norman -- Norman Gray : http://www.astro.gla.ac.uk/users/norman/it/ Research IT Coordinator SUPA School of Physics and Astronomy, University of Glasgow, UK Charity number SC004401 From owner-freebsd-questions@freebsd.org Thu Jun 17 02:23:14 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D1BC464A35A for ; Thu, 17 Jun 2021 02:23:14 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G55Sf4BfYz4n4r; Thu, 17 Jun 2021 02:23:14 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=C9bPJ5j8gci7/K6vF8OgRDkKlUT0+G1FihrYR2xoTDk=; b=lsH4Cmn1JlQc7iiLp3vOtMzdLY M2kUH0bYzpl6RrOXQrgHChKlzZVKX5iJu1QUpKjHe1wAZKw7L3Pl/ks4TA359ekd5e/U8akyll7Jv 7eyaOEAGTtLOaIPzCjBZXKYO08uy6gA2LYWobZB1JV9pRApb9MCkuMyIEAin0dV490Zc=; Received: from vas by admin.sibptus.ru with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1lthgQ-0004Ia-3n; Thu, 17 Jun 2021 09:23:06 +0700 Date: Thu, 17 Jun 2021 09:23:06 +0700 From: Victor Sudakov To: Jan Beich Cc: freebsd-pkg@freebsd.org, freebsd-questions@freebsd.org Subject: Re: pourdiere broken for i386 jails ? (or maybe not poudriere per se) Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dqMFx0l8sNXQJn6S" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 X-Rspamd-Queue-Id: 4G55Sf4BfYz4n4r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 02:23:14 -0000 --dqMFx0l8sNXQJn6S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jan Beich wrote: >=20 > >> root@svn:~ # file /poudriere/jails/114i386/libexec/ld-elf.so.1 > >> /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared > >> object, x86-64, version 1 (FreeBSD), dynamically linked, stripped > > > > I wanted to suggest to re-create the jails with "-a i386" but... > > > > $ file /poudriere/jails/*i386/libexec/ld-elf.so.1 > > /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared o= bject, x86-64, version 1 (FreeBSD), dynamically linked, stripped >=20 > To clarify, my 114i386 jail only became mixed 64-bit after the recent > freebsd-update, performed while replying to Victor's mail. It ran fine > for months before that, including past freebsd-update runs. >=20 I've created a PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256659 I suspect the problem is somewhere in the code where binary updates are applied to the jails. --=20 Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet --dqMFx0l8sNXQJn6S Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJgyrIKAAoJEA2k8lmbXsY0m+EH/3fZC5pww8VbWYdOXHAI536e WxdfP90TZtKRQV5hLPunFfWt+uyt+ER1Gz1v0NZ4vlNDlMCcSjMa2NpicTL8M0WY 9irsUk7ZB1viHEEj8xoHiCxb3akRffOgvCTyiIoN+KGw/4RdGPBNCsLgDrslTHgh OmB8nq0mSrE4e/pUPx65cmDByc8ib1+UudMebhmqVkHGoR+kjnuuf0smJtyUMLrD J/49Dd/jIfY668RWmEjpP4dj3c4xxsoXr4iMPWwyLV/S0uzVGtQbDjH0WAKyFzAY K4/R5G+rFxt+3l79O5v8yE8+vLm+AxB7IggH356C4/bNPk2nzZmz8pyT3Csr1Uo= =g7jV -----END PGP SIGNATURE----- --dqMFx0l8sNXQJn6S-- From owner-freebsd-questions@freebsd.org Thu Jun 17 02:31:51 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E28A764A60D for ; Thu, 17 Jun 2021 02:31:51 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G55fb673Wz4nmx; Thu, 17 Jun 2021 02:31:51 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=XFR5dLQzCB6OP0+5/rlPzfjkq8DMBMoxs6orqTBWw90=; b=hYrkQ38u2Bv+40jpdpgd07m4di 8IbDGFnwlOSSxNTBm6f7Sm/dcqRrLmjSQViLmVEpPwJT2K9uk5cZ+3+UvvYKZ+maKeOeQNKs3CpMY hw/eGWQljTiNTqS6wgT9t3ksNw+N3nmtKpj2FX78yYFbWF4G8ntZMXb/YjqEJgamDnig=; Received: from vas by admin.sibptus.ru with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1lthos-0004M5-M2; Thu, 17 Jun 2021 09:31:50 +0700 Date: Thu, 17 Jun 2021 09:31:50 +0700 From: Victor Sudakov To: Jan Beich Cc: freebsd-pkg@freebsd.org, freebsd-questions@freebsd.org Subject: Re: pourdiere broken for i386 jails ? (or maybe not poudriere per se) Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JhgaazR0LhTJZddq" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 X-Rspamd-Queue-Id: 4G55fb673Wz4nmx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 02:31:51 -0000 --JhgaazR0LhTJZddq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jan Beich wrote: > Jan Beich writes: >=20 > >> root@svn:~ # file /poudriere/jails/114i386/libexec/ld-elf.so.1 > >> /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared > >> object, x86-64, version 1 (FreeBSD), dynamically linked, stripped > > > > I wanted to suggest to re-create the jails with "-a i386" but... > > > > $ file /poudriere/jails/*i386/libexec/ld-elf.so.1 > > /poudriere/jails/114i386/libexec/ld-elf.so.1: ELF 64-bit LSB shared o= bject, x86-64, version 1 (FreeBSD), dynamically linked, stripped >=20 > To clarify, my 114i386 jail only became mixed 64-bit after the recent > freebsd-update, performed while replying to Victor's mail. It ran fine > for months before that, including past freebsd-update runs. >=20 Jan, do you know how to work this problem around for the present? Disable updating in "poudriere jail -c" ? --=20 Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet --JhgaazR0LhTJZddq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJgyrQWAAoJEA2k8lmbXsY0pi4H/iODAXQzu4MG7MRl2VeHl72b zC8NRCakEJacEwaXGqLFtG4boX7RluQecBo3FhjdJc/WqmtLNMfDT0dBzHo8nD7/ gj1sppcWT0ZP6iCU/2K2cRgjMifp77ftI8bb1Wf5COxwwexyPWYk+6kPkQa4kySd Gxx1Rw0Ff8sVPjQ78BsJB7+ATpP79DybIYZlqbxN9vgDhm+X7Fe6gGmmzcaTuzty QXX3IoiFftSBEdth2c1+YpY/h+t6tc3FkpfwtU/8dAe33qRVsPGf3Roq5ptwaWQq KeAdpFYnrBc+ZvBkWO4/HAZxPDyxHobLNblYDxbmo+xRalg286C2Y6eRApqScHw= =FjOw -----END PGP SIGNATURE----- --JhgaazR0LhTJZddq-- From owner-freebsd-questions@freebsd.org Thu Jun 17 09:19:07 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 83E0664FFF1 for ; Thu, 17 Jun 2021 09:19:07 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G5GhV3cxjz3w1L for ; Thu, 17 Jun 2021 09:19:06 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id n7so5926224wri.3 for ; Thu, 17 Jun 2021 02:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=qGN/tDd2ZxThZJOJmgRG4KEW0xlYKOxCoxel+YsHA0M=; b=Z0+DR1nXarrKfFIame/Ui522g7NlNU/enCUgKY1YjzzDHkaKeNBrkUAdHVGMYjpWBM v4f0t6xBgyxpWVZ8Vot+LwnuoDqxp2QXynKY3F0xaIkw65oy/yhpTRaMYZ2aM5+99cg1 VgkBx1YB5zyVBfjQSBKUgv8EZgylLYMnIN72vQVW/1KRRsj0yoT49mCdMYkXxcufqMMP PPyTTU58emNbFvwzxo3e1cRZS3xlUH+BPhTSAghAD4QUDmnck2IsrUIY89kTU0GY7iSf KdxUnu3ONEnxdaZoImkpKDwQgT8weloIhCTaaQJv5siag71xDOftS+0k7ECNwIqUz4lG kQtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qGN/tDd2ZxThZJOJmgRG4KEW0xlYKOxCoxel+YsHA0M=; b=rKsrLDqjH/XxD0DJebIXlUC7U3FVS13zhZmkG43CRc4K77+Bn+bPAgcByY6yoR8VjQ dBaGZMF4RKFNQkiEtF2xJwsyrPsFRX7UjeZGcdK7wHwL/NGTGvRyJAuVFLM9VueD6fMv wHb0uT1BJHi244cOChROWAjF3AXyiQ+IJg4QZThFTo0uWTABHT//rZe2IOZyUADxeS9z 9wYzxfAOfNtorhwICcEut8dxZ5qu8DYsLvOOQGRb3GnTpGERbtIIPxW1z0nZLqBlbZAd Bh2o2cjahrOxyqDaC2zWN/lp9I+SXK/SLWOGgtklmKzAi5ov1pE5LTmDqfwKTCKbw1Ai H92A== X-Gm-Message-State: AOAM532iW9N2QUoPnDJwDO+W5DuKhgOGmd6ICKXSptximI4YEMPYTHRI w1h2qNpGn/i3uHXbqK/Qo1UjbRNqsrnc2FO1 X-Google-Smtp-Source: ABdhPJyutGWgn5sE3ASHKGtGXtP8tLa98xaIh9FvWoghD2aHXaGhgdSoSssZxq/81XKTa5zvIdvXYw== X-Received: by 2002:a05:6000:1110:: with SMTP id z16mr4376091wrw.277.1623921544148; Thu, 17 Jun 2021 02:19:04 -0700 (PDT) Received: from ?IPv6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id n7sm6909688wmq.37.2021.06.17.02.19.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 02:19:03 -0700 (PDT) Subject: Safety harnesses (was: Is a successful call to write(2) atomic?) To: freebsd-questions@freebsd.org References: <26258.1623802141@segfault.tristatelogic.com> <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> From: Graham Perrin Message-ID: Date: Thu, 17 Jun 2021 10:19:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4G5GhV3cxjz3w1L X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Z0+DR1nX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.986]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::432:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::432:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 09:19:07 -0000 On 16/06/2021 14:17, Arthur Chance wrote: > … More like "we think the builders may have installed the floors in this > darkened building, but we suggest a flashlight and safety harness" … Vaguely related, from the perspective of someone who's not a developer, I was recently surprised by the potential downsides of defaults when FreeBSD is installed to UFS. For a moment, back to the opening post from Ronald F. Guilmette: >> … Is a block of data that is successfully written … The surprise, to me, was losing fifty-something seconds' worth of data in a kernel panic situation. Subsequently found, in the FreeBSD Handbook under '12.10.2. Soft Updates' : >>> … Soft Updates guarantee file system consistency in the case of a >>> crash, but could easily be several seconds or even a minute behind >>> updating the physical disk. If the system crashes, unwritten data >>> may be lost. … (I expected _some_ data loss, but sixty seconds surprised me.) It was suggested that disabling UFS soft updates might improve the situation. Through subsequent tests, with a disposable installation – soft updates disabled, carefully timed interruptions whilst using pkg-install(8) – I soon produced what seemed to be a wrecked base system. Photographs after the crash: – and after booting from a usable operating system, to check then repair the file system: With the file system repaired: still, the base system was broken. Metaphorically, dropped without a safety harness from a height of more than one floor :-) From this end result, I assume that: 1. for guaranteed file system consistency with UFS, soft updates may be _highly_ desirable, in some situations 2. some other approach should be taken to reducing the potential scope (sixty seconds) of data loss. --- Some surprise at the default delays for syncing files, directories and metadata. Respectively: 30, 29 and 28 seconds. syncer(4) ---- For the computer where I wrecked the file system, I imagine that (for a future test installation) this combination will be reasonable: - soft updates disabled - mount(8) option 'sync' set in /etc/fstab (does this reduce the risk of   wreckage with soft updates disabled?) - reduced delays for syncer(4). That's my imagination, although honestly, the whole thing messed with my mind. I'm much happier to simply use OpenZFS (or ZFS). From owner-freebsd-questions@freebsd.org Thu Jun 17 13:46:02 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AE10765362E for ; Thu, 17 Jun 2021 13:46:02 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01olkn20825.outbound.protection.outlook.com [IPv6:2a01:111:f403:7004::825]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G5NcT5JwXz4qDS for ; Thu, 17 Jun 2021 13:46:01 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UKevvn6gWzpnQZ8IJ6PR66qZAr57H1JQ/abSeE8YCIWLX4ur5BoTokrDHEgGMX5NuoGRoC6vjFPbkbMt+92qupH5duAT8w1PRsw4Pxgi8RXPDpotxi1DkTydGIX3mBsMyANyxgAuULE8TMJpw/4SKBRFja2pJ7xQBTH14J7prw5YD6i0z/Bto66TYLEC8oL4b4wEWi92JtxT5sAl5Kb46YizudoSQsSuHE8J7GA4HjLDIm597oWxf1l4udKSC6ne/+DbT7s5r3Ab+tR1xBbWhvmGa01TkviIb4XQ0rNBGnUL+/G5bz/n7esELnTXDo8tE9CsZSWkxeVyg2k7KlHLhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i9k9hZpTOq0mFqW6mT3k+34FJERCtQN6Pu5+1cIT3M0=; b=QQOW8Ilio+ZRO59j44FBDb8xXAbsYb6/eZm62y6k8Fvi/7BDzwDDuK4PSzmkIdBnJ9wsBOACdZcb3v4iu8Dy34+NWL7P7B0nB1k1f7b41bXReXaZX0KTCDKCKz6vT+b0iy1mHlGA9bScpq/2RgFwcIfkcwT5neXL+Tgbknw2BZCHaNtoPcYGai24h2C/1mfV19Nop7tp23pRxC0B0nisL0o0rkCdLFrjVPijq8MT12FMXjNKEDsThq7u4/6bupTKUcdw0+NAjPKLkervm8d/w5brj69xJyd3NpW1rPG5mNvbqjDD6C4y47aYvakdwroZA9o5PVhsxuq+nolFCeOk5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i9k9hZpTOq0mFqW6mT3k+34FJERCtQN6Pu5+1cIT3M0=; b=UtvhewcPlmTPJt+j6DwuCDW6/cIls81KSvC+47czbqMP2AAWCrqMLcoW+9/0XcyLvy8UBwalpq1Q732KYuCBh73LERwRQrUSdalUgwErV0mjwjd4SDjhW6N484Ouc/iqzdCb2+ejkJGLSKPdMb2ZXFs7i7dygdfBf5Fqbfo7JYNjzAAjAooD5K/2l6be7R+B+j/hQWe4zoSH+O0OsMWFCZo/FiSUh8BBWcey3YdZiNOSPA7CK5RUuOA3gxu1zfF9uNauxWyN7BWR9MmPfNDBnvQut76GqFLQx0BCIWFVpaqmUCvDDnaw/jf7tpHX1TU06gtiqDmVkyPLP0X0JO0tSA== Received: from SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:11d::11) by SYYP282MB2143.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:7d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16; Thu, 17 Jun 2021 13:45:51 +0000 Received: from SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM ([fe80::99cc:9d92:1803:e134]) by SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM ([fe80::99cc:9d92:1803:e134%5]) with mapi id 15.20.4242.019; Thu, 17 Jun 2021 13:45:51 +0000 From: Daniel Cervus To: "freebsd-questions@freebsd.org" Subject: =?utf-8?B?Y2Rjb250cm9sIHdvbuKAmXQgcGxheQ==?= Thread-Topic: =?utf-8?B?Y2Rjb250cm9sIHdvbuKAmXQgcGxheQ==?= Thread-Index: AQHXY38VwKWhVvPQl02Hm2VFqm95tA== Date: Thu, 17 Jun 2021 13:45:51 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [H500u9h3w4m8oWWukyAfUx0DVXNe/IDT9xTTpY1ak7ia1h698/aRAapFuJOopWYo] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ece0b896-09b0-448a-23ee-08d9319638ac x-ms-traffictypediagnostic: SYYP282MB2143: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nFdUcyS75LO9mNp4CVyJSIL+ujYEcy37FzGVyuh6Ddz6W2JT6NAILZvayw0G+Amc4HcA3XmGyHfsI8KQVWHH1G+CRXy6YV7BE2ysS8O0UQ4rFfg+B7dz7gmjKu05HPq+aHMQrBHa4AGlVZJJ5avzmM+gKyC7Ag5cZc5L6tShL+lXBnqy0vEVlsRWpgBwcuPmovAO68V+MxpIPibugECbkLa/ssoLcMdeN6nnBuvVvTiVGRDdLOzrX8ZcpoN7O6SS8QPqHfyUq964fhWmdNJ+5+tXSukAZnwpYGhuq9ouCfks80r+nkrAiMk0e07UZDNiGDDRjck1/Ta7/9MPkA7oLsHi0cJ1YMJuS/VkBIK/H7Ey3qYqL2FlK/u/y95+Exu2d7V1XVP9W9unViIgBkX+dg== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 5J1P1qDMRq996VxszIJygwxf+Cv3HuHAw4l/N5gjCC1pl7JQQ5N42gg20O4jIQoq6UEytHWQTlDEzsmTK61co7mezAAbh3Z5896oAhvemrqoTlMWycs2eZMTmR53xDwcJdKsbBMrLX2+A6KhX3Q6eru8+ZX0hMJ9wQsoOnoXcyfGA7N+tOeQqVwesWV97fgu2nLg0ctTngx3msYNQ7M9fg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: ece0b896-09b0-448a-23ee-08d9319638ac X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 13:45:51.2240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYYP282MB2143 X-Rspamd-Queue-Id: 4G5NcT5JwXz4qDS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outlook.com header.s=selector1 header.b=UtvhewcP; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=outlook.com; spf=pass (mx1.freebsd.org: domain of DanieltheDeer@outlook.com designates 2a01:111:f403:7004::825 as permitted sender) smtp.mailfrom=DanieltheDeer@outlook.com X-Spamd-Result: default: False [-4.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:111:f403:7004::825:from]; R_DKIM_ALLOW(-0.20)[outlook.com:s=selector1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[outlook.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f403::/48]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a01:111:f403:7004::825:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outlook.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[outlook.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[outlook.com]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions]; DWL_DNSWL_NONE(0.00)[outlook.com:dkim] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 13:46:02 -0000 SGVsbG8gZXZlcnlvbmUsDQpJIHB1dCBhIENEIGluIHRoZSBkcml2ZXIsIHRoZW4gSSB0eXBlZCDi gJxjZGNvbnRyb2wgcGxheeKAnS4gQnV0IGl0IGdhdmUgDQrigJwoY2QwOmFoY2ljaDE6MDowOjAp OiBNT0RFX1NFTlNFKDYpIGZhaWxlZCwgaW5jcmVhc2luZyBtaW5pbXVtIENEQiBzaXplIHRvIDEw IGJ5dGVz4oCdDQpBbmQgbm90aGluZyBwbGF5ZWQuIFRyeWluZyBhZ2FpbiByZXN1bHRlZCBub3Ro aW5nLiBUaGUgdm9sdW1lcyBhcmUgYm90aCAyNTUuIEF1ZGlvIHN0YXR1cyBpcyAyMTx2b2lkPi4N CldoYXTigJlzIHdyb25nPw== From owner-freebsd-questions@freebsd.org Thu Jun 17 15:16:59 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CCE80654D71 for ; Thu, 17 Jun 2021 15:16:59 +0000 (UTC) (envelope-from 4250.82.1d4d20005034e3a.80bdad8bf80d80783a4f9f9252aaf3bd@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G5QdQ58nSz3DjJ for ; Thu, 17 Jun 2021 15:16:58 +0000 (UTC) (envelope-from 4250.82.1d4d20005034e3a.80bdad8bf80d80783a4f9f9252aaf3bd@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1623943019; x=1626535019; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:cc:to:from:date:x-thread-info; bh=ygyYgyPjpKXVdGJeF9Uq6aFntihZ7fy+JKX0f71e9vA=; b=dg+OEARd6YJzGu6UgQrHiV3sWTLPEooCLTSIwuWozAxbsL2Eg86EERAvAFiIT/9EWmbnwV+SS59SZrjG5gik8c7jPHOg+iwdgyP9V4VnaeRsnOsrbILn1XhczQbGW7O+vkSFoDHHG7GgjG6mn50Qn0LCSoGxm0g95D2jwsXrM5Y= X-Thread-Info: NDI1MC4xMi4xZDRkMjAwMDUwMzRlM2EuZnJlZWJzZC1xdWVzdGlvbnM9ZnJlZWJzZC5vcmc= Received: from r2.us-east-1.aws.in.socketlabs.com (r2.us-east-1.aws.in.socketlabs.com [142.0.191.2]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Thu, 17 Jun 2021 11:16:46 -0400 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r2.us-east-1.aws.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Thu, 17 Jun 2021 11:16:45 -0400 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1lttl5-000Gsi-UK; Thu, 17 Jun 2021 16:16:44 +0100 Date: Thu, 17 Jun 2021 16:16:43 +0100 From: Steve O'Hara-Smith To: Daniel Cervus Cc: "freebsd-questions@freebsd.org" Subject: Re: cdcontrol =?UTF-8?B?d29u4oCZdA==?= play Message-Id: <20210617161643.06b4249ab2b63478ef972908@sohara.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4G5QdQ58nSz3DjJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=dg+OEARd; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d4d20005034e3a.80bdad8bf80d80783a4f9f9252aaf3bd@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d4d20005034e3a.80bdad8bf80d80783a4f9f9252aaf3bd@email-od.com X-Spamd-Result: default: False [-2.70 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[email-od.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[outlook.com]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d4d20005034e3a.80bdad8bf80d80783a4f9f9252aaf3bd@email-od.com]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[142.0.176.198:from]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d4d20005034e3a.80bdad8bf80d80783a4f9f9252aaf3bd@email-od.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sohara.org]; SPAMHAUS_ZRD(0.00)[142.0.176.198:from:127.0.2.255]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 15:16:59 -0000 On Thu, 17 Jun 2021 13:45:51 +0000 Daniel Cervus wrote: > Hello everyone, > I put a CD in the driver, then I typed “cdcontrol play”. But it gave Hmm I wonder if that works at all these days. What it used to do last time I used it (some decades ago) was start the CD playing with the audio going out via a connector on the drive itself. Common practice was to connect this to an input on the sound card which usually showed up as 'CD' in mixer so to hear anything you had turn up the CD input with mixer. > “(cd0:ahcich1:0:0:0): MODE_SENSE(6) failed, increasing minimum CDB size > to 10 bytes” And nothing played. Trying again resulted nothing. The > volumes are both 255. Audio status is 21. What’s wrong? It is very possible that the drive is not wired to play audio CDs. -- Steve O'Hara-Smith From owner-freebsd-questions@freebsd.org Thu Jun 17 19:12:04 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EE55E659CEF for ; Thu, 17 Jun 2021 19:12:04 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G5Wrg6JBPz3jLP for ; Thu, 17 Jun 2021 19:12:03 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id D1C924E680; Thu, 17 Jun 2021 12:12:01 -0700 (PDT) From: "Ronald F. Guilmette" To: freeBSD Mailing List Subject: Re: Is a successful call to write(2) atomic? In-Reply-To: <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36326.1623957121.1@segfault.tristatelogic.com> Date: Thu, 17 Jun 2021 12:12:01 -0700 Message-ID: <36327.1623957121@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G5Wrg6JBPz3jLP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-0.51 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.78)[0.777]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 19:12:05 -0000 Update: I need to say "Thank you all!" to all of the folks who chimed in and who have graciously tried to help me to get this problem sorted out. Although I didn't try the idea of passing buffers/lines back up from the "worker bee" child processes to the parent (which would then write those lines to FD 1 in a nice sequentialized fashion) I did try all of the other suggesions that have been made here, specifically (a) setting O_APPEND on the FD, and also (b) wrapping my calls to write() in calls to flock() -and- also (c) embedding in that flock section an additional call to lseek() to position next following write, reliably, at the current actual EOF of the output file. Every step along the way, the "garbled output lines" problem seemed to get smaller, but at the end, it was still present. So I added some more code to do more & better checking of the integrity of the data lines before I even tried to write them to FD #1. And sure enough, once I had that additional "input sanitizing" code in place, the problem went away entirely. Now I'm re-running the whole process again, but with all of the extra stuff that people suggested to me, i.e. the code that sets O_APPEND on the FD, the calls to flock() and the call to lseek() all #ifdef'd out. The results aren't final yet, but for the first 18,000+ lines of output, the "garbled output lines" problem does indeed seem to be gone entirely. So, bottom line, it now appears that I owe everyone an apology for taking up your time. My bad! It now appears that the -actual- problem was most probably related to "logic errors" in my own code, and more specifically my failure to adequately sanitize input data (which is being acquired from remote network hosts that I do not control) before even calling write(). I'm suitably embarassed to admit this, but I feel morally compelled to confess my sins and to take responsibility for my own screw ups. In any case, this has all been quite educational, and for that I thank you all. Regards, rfg From owner-freebsd-questions@freebsd.org Thu Jun 17 19:57:21 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 261CC65D60F for ; Thu, 17 Jun 2021 19:57:21 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G5Xrw3lf7z3nR9 for ; Thu, 17 Jun 2021 19:57:20 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id A3FE84E680; Thu, 17 Jun 2021 12:57:19 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Safety harnesses (was: Is a successful call to write(2) atomic?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36521.1623959839.1@segfault.tristatelogic.com> Date: Thu, 17 Jun 2021 12:57:19 -0700 Message-ID: <36522.1623959839@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G5Xrw3lf7z3nR9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [0.47 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_SPAM_MEDIUM(0.81)[0.808]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.96)[0.965]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; MAILMAN_DEST(0.00)[freebsd-questions]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 19:57:21 -0000 In message , Graham Perrin wrote: >The surprise, to me, was losing fifty-something seconds' worth of data >in a kernel panic situation... In an ideal universe, the kernel never panics. Mine however still does from time to time. I have been informed that this is attributable to me continuing to use an otherwise perfectly servicable AMD graphics card that the X maintainer has elected to no longer support. I have suggested that there might possibly be some more graceful failure mode than a kernel panic in response to some unhandled condition, but to no avail. (Hardware upgrade has been pednding on my end for more than a year. I have all of the necessary parts... new motherboard, new CPU/APU and new memory... however I just never seem to find the time.) Regards, rfg From owner-freebsd-questions@freebsd.org Fri Jun 18 00:58:13 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C07E6638A00 for ; Fri, 18 Jun 2021 00:58:13 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01olkn2186.outbound.protection.outlook.com [40.92.62.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G5gX435vmz4YNC for ; Fri, 18 Jun 2021 00:58:11 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=By3UFvn5eSizxMVw4vosEmr/JmyBNkR5jJJT7fosiyH+n7Pf44yxf3+0FeuAcO3amQgjuD7jtKtD967YcEVEisG6PhHwWd6QI9XVrxb/C/Gfud/NBTsF5+qgwt4+vGdonvgwahoYVWq+kaQxOSpe6NFahF8lvsPWEfTaKv8sp11PKtJFtMSkdDKt2fQEtrKbdLPi1FSRc0Du6sC3FyMHtQaEy58SNHV99wdL6nDVld0VuGL0mvy0VwGBEsST+9347fJlXjW/nqF+PuR3RfSakMK5ROZhjfEQRDkTJUxDBhBpU3WAuLw0VHswz0sVOnRMgVFmmUvzwiAQvgNn6631Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2GHu6rptIiD7ToqaTqT4Svlyfo6+8ECW/OdOwFshkkk=; b=FNbVCA5wqdMTStyowIyA1H/HZUQUzqJfZMroqXoLris9O2VYUQ/WPGgsdq/+vhDyNa0vKANuLCL7ABdbvmmJnrEPZkh8wOrWok2me26s50d3EGMh4C8OGrXoXmrjgeKEOr4h7nYUrd+1Ek5C/YfGTlkieZeSbqAtawCR6cQUQOjGmQs7vDfr6ijSbHH2LsAPmlKIYykQZ5mQxT6M+XLqOpnR0TMAFG6GLR3fU/KxbMZ/HYyTUOaUbCxwNbAJ9shG4tOJmrkQ1WrdLx78Iab6SQv0XVm4X/zRirjykR/ORMWkdiszWivx33K1ZOIPFLcLT2NUKYBa3oOb+s3UDVTqgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2GHu6rptIiD7ToqaTqT4Svlyfo6+8ECW/OdOwFshkkk=; b=qA/VPBPXaV/18z4C8MmBS2s/ZfrqwVsXstjpvPqn/dpyeSw4YYGTcA9ic/avT+up0x1AnOd9SPF8F0RhKigpZVCOKJ7lB4JRMGTG1JwWtZVwdNKlkJMNkJRjib5LGaZrfCIlNp0IS2eKMe4xjLj6to11eunWN6zmc+cmyPXMbImsbQqDxtSI1+8op6V09M5WYxZRXGr4rIyLc1CaNIi/VpADkrAdwnL/y4k15LPcZGgSZr3wdDUjBjSBDZ8PO5te1DArPAszfh4pLELWygZqNnTym3dPSw9AFcKMnctMHiOgIovr9bMQKU89/kxwc2I5yRbemWI253hyP5YZakaweg== Received: from SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:11d::11) by SYYP282MB2143.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:7d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16; Fri, 18 Jun 2021 00:58:07 +0000 Received: from SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM ([fe80::99cc:9d92:1803:e134]) by SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM ([fe80::99cc:9d92:1803:e134%5]) with mapi id 15.20.4242.021; Fri, 18 Jun 2021 00:58:07 +0000 From: Daniel Cervus To: Steve O'Hara-Smith CC: FreeBSD Questions Mailing List Subject: =?utf-8?B?UmU6IGNkY29udHJvbCB3b27igJl0IHBsYXk=?= Thread-Topic: =?utf-8?B?Y2Rjb250cm9sIHdvbuKAmXQgcGxheQ==?= Thread-Index: AQHXY38VwKWhVvPQl02Hm2VFqm95tKsYUJCAgACicvY= Date: Fri, 18 Jun 2021 00:58:07 +0000 Message-ID: References: , <20210617161643.06b4249ab2b63478ef972908@sohara.org> In-Reply-To: <20210617161643.06b4249ab2b63478ef972908@sohara.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [8GZfDWCug5MUxPIP40VMsoLsK3NFMULqYRoFn9yv0RoCBYbXRyV4OLP5jhG1I2IK] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3d6bb7c-1921-4f1d-b388-08d931f422cf x-ms-traffictypediagnostic: SYYP282MB2143: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eCGVDV2SlMsn6Gs9bQ9WI2ZMPjdqHXdQ/8sGtYs8Z+VPjsfmgxLM5lfqrFQQUqarHFC4O99De4wrvcyAphrE0U+h7jRrXQioZ+1E2VxEWDQyeC3pHA9hezxWSqCIQb+7iEF26Mm29UbbJk0ubgThpbTLa7rdCCOrLvEsB95yCQLGfxx2D9BLKhKVDBdnZmY2Htjve/YWZVMzyjuS56YuLPFXatp/XNyngxhWD3S2KbdCftA2EiNNEh9UHbAo4X1PgspPYVcRC11y7QN1/kY1DPpW2gQUH7WD7iXVJ6nhdl/xIMtFt2qm45yueOEAWeLAq8Gj91niw/7hfOilJxv991ar4uoAcwNeKmQIfvtlaa0Aahn7laICv+qvuewUzEHSK9t8V2L8gp18NHGmceYUqw== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: fBv7yddJYBjxMjBKUJiOpP/tB1cNkywG9iQQjSllvqeHY0f811nfa23aDQIVOz++5s1cLbdgtVMejJO4fORHsRCvBU609ptnc6paJSSc/Co1nzLpKZyMutZad96/lOWddpMA+WO4Q0n76w2xBgHj2yTQGXvOsS9imXI/CcZQuu9TeDf7RSgVJEqHUAOf30oQVC5iMz4mSlHdm7tokApXww== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SYBP282MB2383.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: d3d6bb7c-1921-4f1d-b388-08d931f422cf X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2021 00:58:07.4558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYYP282MB2143 X-Rspamd-Queue-Id: 4G5gX435vmz4YNC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outlook.com header.s=selector1 header.b=qA/VPBPX; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=outlook.com; spf=pass (mx1.freebsd.org: domain of DanieltheDeer@outlook.com designates 40.92.62.186 as permitted sender) smtp.mailfrom=DanieltheDeer@outlook.com X-Spamd-Result: default: False [-4.90 / 15.00]; FREEMAIL_FROM(0.00)[outlook.com]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[outlook.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[outlook.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.92.62.186:from]; FREEMAIL_ENVFROM(0.00)[outlook.com]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[outlook.com:s=selector1]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[outlook.com:dkim]; SPAMHAUS_ZRD(0.00)[40.92.62.186:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.62.186:from]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 00:58:13 -0000 DQoNCj4g5ZyoIDIwMjHlubQ25pyIMTfml6XvvIzkuIvljYgxMToxNu+8jFN0ZXZlIE8nSGFyYS1T bWl0aCA8c3RldmVAc29oYXJhLm9yZz4g5YaZ6YGT77yaDQo+IA0KPiDvu79PbiBUaHUsIDE3IEp1 biAyMDIxIDEzOjQ1OjUxICswMDAwDQo+IERhbmllbCBDZXJ2dXMgPERhbmllbHRoZURlZXJAb3V0 bG9vay5jb20+IHdyb3RlOg0KPiANCj4+IEhlbGxvIGV2ZXJ5b25lLA0KPj4gSSBwdXQgYSBDRCBp biB0aGUgZHJpdmVyLCB0aGVuIEkgdHlwZWQg4oCcY2Rjb250cm9sIHBsYXnigJ0uIEJ1dCBpdCBn YXZlIA0KPiANCj4gICAgSG1tIEkgd29uZGVyIGlmIHRoYXQgd29ya3MgYXQgYWxsIHRoZXNlIGRh eXMuIFdoYXQgaXQgdXNlZCB0byBkbw0KPiBsYXN0IHRpbWUgSSB1c2VkIGl0IChzb21lIGRlY2Fk ZXMgYWdvKSB3YXMgc3RhcnQgdGhlIENEIHBsYXlpbmcgd2l0aCB0aGUNCj4gYXVkaW8gZ29pbmcg b3V0IHZpYSBhIGNvbm5lY3RvciBvbiB0aGUgZHJpdmUgaXRzZWxmLiBDb21tb24gcHJhY3RpY2Ug d2FzIHRvDQo+IGNvbm5lY3QgdGhpcyB0byBhbiBpbnB1dCBvbiB0aGUgc291bmQgY2FyZCB3aGlj aCB1c3VhbGx5IHNob3dlZCB1cCBhcyAnQ0QnDQo+IGluIG1peGVyIHNvIHRvIGhlYXIgYW55dGhp bmcgeW91IGhhZCB0dXJuIHVwIHRoZSBDRCBpbnB1dCB3aXRoIG1peGVyLg0KPiANCj4+IOKAnChj ZDA6YWhjaWNoMTowOjA6MCk6IE1PREVfU0VOU0UoNikgZmFpbGVkLCBpbmNyZWFzaW5nIG1pbmlt dW0gQ0RCIHNpemUNCj4+IHRvIDEwIGJ5dGVz4oCdIEFuZCBub3RoaW5nIHBsYXllZC4gVHJ5aW5n IGFnYWluIHJlc3VsdGVkIG5vdGhpbmcuIFRoZQ0KPj4gdm9sdW1lcyBhcmUgYm90aCAyNTUuIEF1 ZGlvIHN0YXR1cyBpcyAyMTx2b2lkPi4gV2hhdOKAmXMgd3Jvbmc/DQo+IA0KPiAgICBJdCBpcyB2 ZXJ5IHBvc3NpYmxlIHRoYXQgdGhlIGRyaXZlIGlzIG5vdCB3aXJlZCB0byBwbGF5IGF1ZGlvIENE cy4NCj4gDQo+IC0tIA0KPiBTdGV2ZSBPJ0hhcmEtU21pdGggPHN0ZXZlQHNvaGFyYS5vcmc+DQoN Ckkgc2VlLCBpcyB0aGVyZSBhbnkgd29ya2Fyb3VuZD8gSWYgbm90LCBkb2VzIGl0IG5lZWQgdG8g YmUgcmVtb3ZlZCBmcm9tIHRoZSBiYXNlIHN5c3RlbT8= From owner-freebsd-questions@freebsd.org Fri Jun 18 01:47:57 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B13A1638CF3 for ; Fri, 18 Jun 2021 01:47:57 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G5hdS4CqVz4bCY for ; Fri, 18 Jun 2021 01:47:56 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id h21-20020a1ccc150000b02901d4d33c5ca0so2732350wmb.3 for ; Thu, 17 Jun 2021 18:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=8J2gzR0QiZIYKvzJ4QBv4HeEhqJAboLG8QEfYgyqRFE=; b=pC0zJdsGOOpJR1yr9s/KT1tgskVC8t7NV24x2ObG5BZP9JROVt7N4EYebgbuFsWYNq O9qcFwjLAEFzjMKFGQ7eVY2F5WRITlHWHglliYU3B4QNgAms2CMtVuX+KvM848Ha011f yImEaVHyYKdhlsdVC94oS+T12Nl6OeaMIwCFUgyejgSkkjO6zc7r5YgEtkvw5ibjMFKM dkEgFAl8KkQ6omuExop+ppBAZuExahT4XSmOwFDvo2/8ZDHCXodLfC8NCSX9rkbE47YH 1GUCpFWg2b1HrSx0d4ZLJs/lnDcoUMqmNAHIMzd6CFZMNn4HR/vBExrnnc4CqpOOZsds loGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=8J2gzR0QiZIYKvzJ4QBv4HeEhqJAboLG8QEfYgyqRFE=; b=maTkm/T20Ex/baTAWY0eDVMgffX+ns0r2F9kko4Z4iSlK06LffFMoZTBOTrpF58EgV uuQXN1TYBUq6kG2gsSIzXTRAEogPdMMV2JgxpRYShYOwlj6zyvHJZERhWcLoC+teVWHe DqhaEMfjkdGP1/MillrI4wpCYwlsqJJZMUr4F5Q5Pm9Ri0omVz90OxygI7MDVYG/R2Ab lW5D4VAbSeydwzNc0LC+7DeTFWKBEzqN6r94t/mpboulhhAIKuyUVVcFU2iHLSv3qTOg uZeBpivpKZrG0NOUlznrMosIWPLCcsngRiJReVMi1Pehc0yYt7OT/NrS5QLr5j5Y+NRS pzRQ== X-Gm-Message-State: AOAM5305FhLA+6QWjIgxK2kxxHB/tHNfPNj6ATmiVp0d3ZTPGZvcDp/c 4+/cskhvPLUHBQfxxB9NocUk0VTlUfKG2N8n X-Google-Smtp-Source: ABdhPJxEtQOTPdVEEDsznLLgNPgY+WbqdtSLFYLxjz/m+sulQS/ecFYXH3934KXIZG2Rh6/ATzm31g== X-Received: by 2002:a05:600c:2141:: with SMTP id v1mr8731718wml.68.1623980873786; Thu, 17 Jun 2021 18:47:53 -0700 (PDT) Received: from ?IPv6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id 6sm6220554wmg.17.2021.06.17.18.47.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 18:47:53 -0700 (PDT) Subject: Re: Safety harnesses To: freebsd-questions@freebsd.org References: <36522.1623959839@segfault.tristatelogic.com> From: Graham Perrin Message-ID: <6852ccf3-d316-4c54-ad81-c89697377062@gmail.com> Date: Fri, 18 Jun 2021 02:47:52 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <36522.1623959839@segfault.tristatelogic.com> Content-Language: en-GB X-Rspamd-Queue-Id: 4G5hdS4CqVz4bCY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=pC0zJdsG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::331:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::331:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::331:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 01:47:57 -0000 On 17/06/2021 20:57, Ronald F. Guilmette wrote: > Graham Perrin wrote: > >> The surprise, to me, was losing fifty-something seconds' worth of data >> in a kernel panic situation... > In an ideal universe, the kernel never panics. … +1 tl;dr I was (originally) aiming to get backtraces for panics, intended panics. The surprises with UFS were (originally) having no crash dumps after editing /etc/rc.conf to enable crash dumps; /usr/local/etc/sudoers empty after use of visudo; gdb not found after installing gdb; and so on. Eventually I discovered that all such losses were expected.