From owner-freebsd-hackers@freebsd.org Sun Feb 10 00:53:38 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB8F214D4ADE for ; Sun, 10 Feb 2019 00:53:38 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com [209.85.166.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7CD48C4A4 for ; Sun, 10 Feb 2019 00:53:36 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f172.google.com with SMTP id b5so18200273iti.2 for ; Sat, 09 Feb 2019 16:53:36 -0800 (PST) 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=/HrgT0wiwnrP3iSrJ6DY9E64ovHnTbP+laFsW0tdC0I=; b=lJ6uXfj/MHiI7gzikp3BoS4N5UpmgWW4nVo4MXC83+S4b0tJgsSycq+uRA+lK8dbQh N162FMIn+Ng1sVPK5vwvG9SrqwCy+JpY7KY1muTrBTBBgPo6w4OzQisCzmzmwDxJORgd ZJinNmidrL31em9tz2GB2aZlDS0Lnwp6oF/8bRQFxBrVXFJ9SN5h0nDOAVMf23OcxHbf Cl3sge/IACU1rUSiu6RIratryGuViRe5VmjfcqSKTs5E/pdOoNRk4K+ZKQMX8X0liZcF FaVhHWdy0Xc6THfgKLYigHHSVkc0lYBldRwX+Hf6viETDIk1ZtsPVIbwhc/rmCxTgT7z 8Jyw== X-Gm-Message-State: AHQUAuaVgPr8ag7Sdjz2mZeBaIiUqeLCiMLhOdTMahz+tEr2Q75E/oYi pS2CDNU9rO1whlp6Lu0719vZ79qF X-Google-Smtp-Source: AHgI3IaVi3/tOc0Px7FHFM/ngfEc69MaM6eLhBbIoupz67U7VSJpdqjS3D6YG6OG3hFgm6GO0i0Kuw== X-Received: by 2002:a6b:dd16:: with SMTP id f22mr15184152ioc.148.1549760009949; Sat, 09 Feb 2019 16:53:29 -0800 (PST) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id j14sm2692161ioa.5.2019.02.09.16.53.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 16:53:29 -0800 (PST) Received: by mail-it1-f182.google.com with SMTP id q78so12358615itc.0 for ; Sat, 09 Feb 2019 16:53:28 -0800 (PST) X-Received: by 2002:a6b:ee16:: with SMTP id i22mr15137349ioh.124.1549760008760; Sat, 09 Feb 2019 16:53:28 -0800 (PST) MIME-Version: 1.0 References: <201902092334.x19NYtZe036559@slippy.cwsent.com> In-Reply-To: <201902092334.x19NYtZe036559@slippy.cwsent.com> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sat, 9 Feb 2019 16:53:17 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: nosh init system To: Cy Schubert Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C7CD48C4A4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.172 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-5.98 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; IP_SCORE(-2.98)[ip: (-9.12), ipnet: 209.85.128.0/17(-3.77), asn: 15169(-1.95), country: US(-0.07)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[172.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 00:53:39 -0000 Hi Cy, On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert wrot= e: > I don't see what's so "incredibly fragile" about rc(8). That's not to > say there aren't better solutions, like SMF. Maybe "incredibly" as a choice of adjective is inappropriate. I think we (you, me, and ngie@) can all agree it is somewhat fragile, and there are things SMF/systemd/nosh get right that rc(8) does not (today). Anyway, your next paragraph goes on to be a good start at describing some of rc's fragility. :-) > Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc > script could fail hosing the boot or worse hosing the system*. Where a > solution like SMF solves the problem is that should a service which > other services depend on fail, only that branch of the startup tree > would fail. Right; that's a great example. > In that scenario, if a service fails but sshd start, a > sysadmin would still be able to login remotely to resolve the problem. > So in this regard rc(8) is at a disadvantage. > > We could address the above paragraph by starting sshd earlier during > boot thereby allowing the opportunity to fix remotely. I don't think that is really sufficient without substantially modifying init+rc to be closer to something like systemd or SMF, anyway. And then we'd rather just have something like SMF :-). As soon as *any* rc service fails to start (signal, non-zero exit, stop_boot), rc(8) exits non-zero, causing init(8) to go to single user. All service state is thrown away with rc(8) exit, but any rc.d "services" that managed to start before boot failed are not terminated. Even if an admin manages to log in and fix the configuration, re-starting rc(8) restarts the runcom process from scratch, as if nothing had already been done, without first stopping anything that was already running. The only safe, reproducible way to re-start rc(8) is to fully reboot the system. E.g., the major pain point we run into repeatedly with restarted boot is that cleanvar / cleartmp run again. This breaks ld-elf.so.hints cache (anything linking /usr/local libraries =E2=80=94 hope your admin is running base sshd and not openssh-portable!) as well as wiping out /var/run pid files (breaking "already running?" rc pid checks). As a result, services get double-started. Cleanvar could maybe be improved to avoid this problem =E2=80=94 e.g., we could coordinate with the kernel to set a per-boot, persisted flag that cleanvar has completed, even if rc(8) exits =E2=80=94 but the broad cl= ass of problems would remain (rc.d autostart is stateful, but any partial failure destroys all state). Best regards, Conrad From owner-freebsd-hackers@freebsd.org Sun Feb 10 01:36:46 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B1E314D6BFE for ; Sun, 10 Feb 2019 01:36:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (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 67B7B8E0AB; Sun, 10 Feb 2019 01:36:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id se2sge6VP8uQmse2ugfuyJ; Sat, 09 Feb 2019 18:36:37 -0700 X-Authority-Analysis: v=2.3 cv=XKpOtjpE c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=8nJEP1OIZ-IA:10 a=CFTnQlWoA9kA:10 a=xfDLHkLGAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=ujvZ9ZrPEkay_tLzsz8A:9 a=IyvLYzZTXZlyrRf2:21 a=C0126hHkFyNuy9DN:21 a=wPNLvfGTeEIA:10 a=IfaqVvZgccqrtc8gcwf2:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id D3A37A53; Sat, 9 Feb 2019 17:36:33 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x1A1aXpu039739; Sat, 9 Feb 2019 17:36:33 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x1A1aXXv039736; Sat, 9 Feb 2019 17:36:33 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201902100136.x1A1aXXv039736@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: cem@freebsd.org cc: Cy Schubert , "freebsd-hackers@freebsd.org" Subject: Re: nosh init system In-Reply-To: Message from Conrad Meyer of "Sat, 09 Feb 2019 16:53:17 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 09 Feb 2019 17:36:33 -0800 X-CMAE-Envelope: MS4wfJ9drcRLtV2t8/Z8+MkjYKcZ2l//BY/DYLyPge9zzP6XOL5pcJRG1zRKzFLXkNDuW4qwncvUXDaWHwaRq2xvtJCMnlTZB/qpT1v9U7fWniiJuu4vMo7f VmdpvdcGD2TH+3vabYKfNODBVBv1Mgasu2AB05lriXNdy17CX3IclSDWK1LwMEwjw3YYz3M1gY+bvauPUpefIxQEjAui/43f54I= X-Rspamd-Queue-Id: 67B7B8E0AB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.76 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; IP_SCORE(-2.08)[ip: (-5.79), ipnet: 64.59.128.0/20(-2.53), asn: 6327(-1.97), country: CA(-0.09)]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 01:36:46 -0000 In message , Conrad Meyer writes: > Hi Cy, > > On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert wrote: > > I don't see what's so "incredibly fragile" about rc(8). That's not to > > say there aren't better solutions, like SMF. > > Maybe "incredibly" as a choice of adjective is inappropriate. I think > we (you, me, and ngie@) can all agree it is somewhat fragile, and > there are things SMF/systemd/nosh get right that rc(8) does not > (today). Anyway, your next paragraph goes on to be a good start at > describing some of rc's fragility. :-) > > > Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc > > script could fail hosing the boot or worse hosing the system*. Where a > > solution like SMF solves the problem is that should a service which > > other services depend on fail, only that branch of the startup tree > > would fail. > > Right; that's a great example. > > > In that scenario, if a service fails but sshd start, a > > sysadmin would still be able to login remotely to resolve the problem. > > So in this regard rc(8) is at a disadvantage. > > > > We could address the above paragraph by starting sshd earlier during > > boot thereby allowing the opportunity to fix remotely. > > I don't think that is really sufficient without substantially > modifying init+rc to be closer to something like systemd or SMF, > anyway. And then we'd rather just have something like SMF :-). I'd rather see SMF but a number felt a CDDL licensed init was unacceptable -- except for the fact that SMF doesn't replace init. > > As soon as *any* rc service fails to start (signal, non-zero exit, > stop_boot), rc(8) exits non-zero, causing init(8) to go to single > user. All service state is thrown away with rc(8) exit, but any rc.d > "services" that managed to start before boot failed are not > terminated. Even if an admin manages to log in and fix the > configuration, re-starting rc(8) restarts the runcom process from > scratch, as if nothing had already been done, without first stopping > anything that was already running. The only safe, reproducible way to > re-start rc(8) is to fully reboot the system. It wasn't that way 10-15 years ago. It's evolved to become this. Even if we stay with rc(8), quickly cobbling together a patch isn't going to fix it long term. Whether we use another init, an add-on like SMF, or make rc(8) more robust, it will not be fixed by a simple tweak here or there. > > E.g., the major pain point we run into repeatedly with restarted boot > is that cleanvar / cleartmp run again. This breaks ld-elf.so.hints > cache (anything linking /usr/local libraries — hope your admin is > running base sshd and not openssh-portable!) as well as wiping out > /var/run pid files (breaking "already running?" rc pid checks). As a > result, services get double-started. > > Cleanvar could maybe be improved to avoid this problem — e.g., we > could coordinate with the kernel to set a per-boot, persisted flag > that cleanvar has completed, even if rc(8) exits — but the broad class > of problems would remain (rc.d autostart is stateful, but any partial > failure destroys all state). This needs more than improving cleanvar or some other script. It's like whack-a-mole. (The rest of this not specifically talking to you Conrad.) This is why every one to two months this topic comes up again and again and again. It's a pain point. (And also the shiny new object syndrome.) Various people suggest their favourite init(8) replacement and the bikeshed starts up again. To avoid bikeshedding this to death again, we enumerated two issues so far. Let's continue to list issues. I also think that this should be a BSDCan devsummit whiteboard topic where we list issues in one column and next to it we list possible solutions, after listing all the issues first. And finally if this is too large for one person to work on, assign the various issues to willing developers. One final thought. init(8) and rc(8) requirements for desktop/laptop, server, embedded, and mobile are probably different enough that their requirements may compete with each other. Some embedded applications may desire a simple rc(8) whereas server or desktop a heavier weight solution. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Sun Feb 10 03:29:22 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FA6C14DB82C for ; Sun, 10 Feb 2019 03:29:22 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2ACF9920C4; Sun, 10 Feb 2019 03:29:21 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pl1-x62d.google.com with SMTP id s1so3599463plp.9; Sat, 09 Feb 2019 19:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+1mEE74fUhAeo2EOVEJKYH7Fw8vQDSle1QBXjwwpFYc=; b=MKPoOR02ke6LO4NeOFI94eAWw3Y0eF085pi3Ma5ZmXU8UOskln+FiaEzhrJ11pCYuC EwEYdc6s/H7Fq12KzBOFO5UA8/pJpE0bdeK9U4qwTwH6FRWV9a3PninbLSfKpGSluIqI DB0QrtgSRWTuWnXUt/7r8rrrBePgefdK3nJggsP+5zTSoEUl8n6NlP6vXoHyKd/jaqf5 j/kUxtHV974lzVXhF5Pix/jT5LBaC4PfZfSmYNw3ye2ofM8ruiNpTKm7KEvNI5DAMt13 7t2Fvtnm34kFSGM8Cd5oX6M3CcQKk73L4KpDQarubIj572zl5yJ5hMMlXaojUIB+S6l7 HfkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+1mEE74fUhAeo2EOVEJKYH7Fw8vQDSle1QBXjwwpFYc=; b=DEXPY7ZGX/5syOzO+kvqO51tbQaxxSwOKVDgND6OndMvRe4LcnCOjOzCv5bhz5E7pC nc6TgPXtfnN7j1lI6xznbEisjTE6FOZCcfyPthu1tna2rl/K8/d58ijNQzVgYkXI3huk OlF+EySI57JyodnaIsmIumW0jhCntfkpFFYzyq/XWPQU51n4Qv16fZkeeeeNnboRJC+O tn+gBLXDalMnQZSNo7QCfErnryA+nHv5CgYjY0f9dfKdgqFyEvqAQyR1juqE4L+b1Fjj tc4JcgQ9CEBTz7nmVyZ057ZY4K9/KcL2ddSXDcKpfw+DTgYrVCjRX1dAE90AlugZXOjV 2bRw== X-Gm-Message-State: AHQUAuaS6Cu+vYktT0jKyZck1HAc685sHednGmVyrwx8cGKFDPMeJvZI fG1TaPv8epvy4h4bYwVJfn2P7usR X-Google-Smtp-Source: AHgI3IbH9iUAJscvcFF4ZevHyShhkN4WDXTMON32771AQ5B0Op2WrTtlAXoDe5vKuBttzjqZkSh3kg== X-Received: by 2002:a17:902:4827:: with SMTP id s36mr30447231pld.168.1549769359755; Sat, 09 Feb 2019 19:29:19 -0800 (PST) Received: from ?IPv6:2607:fb90:fcc:1206:5533:c7b5:d523:cec9? ([2607:fb90:fcc:1206:5533:c7b5:d523:cec9]) by smtp.gmail.com with ESMTPSA id w185sm8901734pfb.135.2019.02.09.19.29.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 19:29:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: nosh init system From: Enji Cooper X-Mailer: iPhone Mail (16C104) In-Reply-To: <201902092334.x19NYtZe036559@slippy.cwsent.com> Date: Sat, 9 Feb 2019 19:29:17 -0800 Cc: Wojciech Puchar , Sidju , "freebsd-hackers@freebsd.org" , Conrad Meyer Content-Transfer-Encoding: quoted-printable Message-Id: References: <201902092334.x19NYtZe036559@slippy.cwsent.com> To: Cy Schubert X-Rspamd-Queue-Id: 2ACF9920C4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=MKPoOR02; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-6.08 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.89)[-0.892,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.68)[ip: (-8.92), ipnet: 2607:f8b0::/32(-2.46), asn: 15169(-1.95), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 03:29:22 -0000 > On Feb 9, 2019, at 15:34, Cy Schubert wrote: ... > I've been using NIS on FreeBSD for a couple of decades and still using=20 > it on my network. Except for one bad patch a few years ago it's been=20 > 100% solid. There are no startup or shutdown issues. My example of yp was probably a bad example for others to glom on to. Some real examples are netif vs routing, samba=E2=80=99s myriad of scripts, o= r restarting rpcbind (which doesn=E2=80=99t trigger a restart of mountd, nfs= d, etc). In the latter case, one can argue that the services can be made mor= e fault tolerant to their dependencies not being available (that=E2=80=99s o= ne part of a solution), however, the example of netif vs routing is much, mu= ch harder to solve without having an external service manager/monitor. > I don't see what's so "incredibly fragile" about rc(8). That's not to=20 > say there aren't better solutions, like SMF. >=20 > Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc=20= > script could fail hosing the boot or worse hosing the system*. Where a=20 > solution like SMF solves the problem is that should a service which=20 > other services depend on fail, only that branch of the startup tree=20 > would fail. In that scenario, if a service fails but sshd start, a=20 > sysadmin would still be able to login remotely to resolve the problem.=20 > So in this regard rc(8) is at a disadvantage. This is another item that yes, rc doesn=E2=80=99t solve properly. Good call (= I didn=E2=80=99t notice this shortcoming). > We could address the above paragraph by starting sshd earlier during=20 > boot thereby allowing the opportunity to fix remotely. Ehhhhhhh... this is probably not that easy. > Regarding SMF, it could be implemented by rc(8) invoking smf in similar=20= > fashion as Solaris does -- Solaris invokes it through inittab(5) -- or=20 > it could through a special yet to be determined entry in ttys(5). The=20 > Solaris approach is init(8)'s sole job, through the inittab(5) entry,=20 > is to restart smf, while smf does the rest. I prefer not to discuss=20 > implementation details right now, it's premature. >=20 > * Incredibly stupid people can hose SMF too. It is more complex. OTOH=20 > that complexity might scare the uninitiated from attempting something=20 > dumb. Quite frankly, service managers/monitors should manage services in a best ef= fort manner. Unless, there=E2=80=99s danger of something like filesystem cor= ruption occurring, I don=E2=80=99t think that a ton of effort should be put i= nto making complicated cases work. Cheers, -Enji= From owner-freebsd-hackers@freebsd.org Sun Feb 10 03:17:49 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED30114DB376 for ; Sun, 10 Feb 2019 03:17:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE9291B55; Sun, 10 Feb 2019 03:17:47 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf1-x436.google.com with SMTP id y126so3580876pfb.4; Sat, 09 Feb 2019 19:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kZarwB5i1jZVhbIx2zs9Xydnj3WPD4XefGv6Y4voG0g=; b=cZRAcFlrrx1N/XzNQ0qq44vXsCTEReUSFj3T7VIh0Gp1BPp5eDhexImOMMGiBvWmOo MxzX93kQZ6wL8s+4Id4nVzI3L5aa4rzPX+4m/P90zqZfrbrhudPonUYb8PqqDP6AOBsv /glxRyjdOK8u4ZpUwJwcqhhRVvj/Lqh/CthxMbOmcWAjgA9VZrHX3JssMKnoMCmBDEjr xdtj3CvzKbjkh0Ywl8dNZrVu/1nfrmYC64rG94d+68RpbJvvQA9MvI7dhIcQqyBnyM01 zOgjl4Bat6DLp45X3EGXWopO6tkRZg3FsjJp8kLKFUJ0UdahR0OuPT7VfJYN+UABnJGl liTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kZarwB5i1jZVhbIx2zs9Xydnj3WPD4XefGv6Y4voG0g=; b=jjpxx5lS1hgs3zWoKbzFJghv71ntO/NqUauaKpAmAI33yoHdUU+nNKC0wmDs8HGewm DQ5pYZgPLUk6RgiVQdcwKNuoS7/OWiRQnwqQafxXf6ULzpzg2/578gdV4LZCvKgQHd2E aj+y0UCPUUFbKHsb5eREdQP9vsZ1e0oN8DhcIYU7L2tpeSyT4Jjnaf7Xea44g6MtBMoT 6/vJChEVUN/EOH+2p7Or0kvb+B0PhRdpBicftFERLVbtZ2eMC2HsshsWK5YAJPC0MR8Y eh9VvivvbomUVQj20Ghe5E3+OEjIJblKwFJ1IQmHg51wmeZM0tFAxbs7F0sv+mDg2Jle mLWw== X-Gm-Message-State: AHQUAubJvfy++v+3sgZrlXsxr+Z97q2PHEG4VBvY23iG3k/0BG1bKtpu HUk2NCWuATemkK0P6v8VpXHwB+PC X-Google-Smtp-Source: AHgI3IZ9NkSMsHTBJGLa+q1udCvPofwbBhJUZQPtlaRSMq2+J98PnnU/1DqXLJLadBUmu5l3R1n8Vw== X-Received: by 2002:a63:2905:: with SMTP id p5mr28057377pgp.178.1549768665861; Sat, 09 Feb 2019 19:17:45 -0800 (PST) Received: from ?IPv6:2607:fb90:fcc:1206:5533:c7b5:d523:cec9? ([2607:fb90:fcc:1206:5533:c7b5:d523:cec9]) by smtp.gmail.com with ESMTPSA id m13sm6554177pfi.32.2019.02.09.19.17.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 19:17:45 -0800 (PST) Mime-Version: 1.0 (1.0) Subject: Re: nosh init system From: Enji Cooper X-Mailer: iPhone Mail (16C104) In-Reply-To: Date: Sat, 9 Feb 2019 19:17:43 -0800 Cc: Wojciech Puchar , Sidju , "freebsd-hackers@freebsd.org" , Conrad Meyer Message-Id: <01CB4D6D-0958-42E3-9BD6-149B0A26DB95@gmail.com> References: To: Adam X-Rspamd-Queue-Id: 9FE9291B55 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=cZRAcFlr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::436 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-6.23 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.89)[-0.892,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-2.83)[ip: (-9.66), ipnet: 2607:f8b0::/32(-2.46), asn: 15169(-1.95), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[6.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 03:17:49 -0000 > On Feb 9, 2019, at 10:32, Adam wrote: >=20 >> On Sat, Feb 9, 2019 at 11:57 AM Enji Cooper wrote= : >=20 >> On Feb 9, 2019, at 09:32, Wojciech Puchar wrote: >>=20 >> >> pid 2 and reap zombies. We're missing a half-decent service >> >> management system. On Linux, systemd performs both roles. On >> >> FreeBSD, init(8) serves one role, and rc(8) is a tiny subset of a real= >> >> service management system like systemd. >> >=20 >> > systemd is overcomplex crap. And a reason many people migrated to FreeB= SD from linux. >> >=20 >> >>=20 >> >> (I think the piece we would consider replacing or supplementing would >> >> be rc(8). Part of that might be migrating some responsibilities from >> >> pid 1 to pid 2, such as spawning gettys. I don't hold strong opinions= >> >> about that.) >> >=20 >> > this make sense but with spawning gettys left to init. >> >=20 >> >=20 >> > what do you want to improve in rc? starting services in parallel doesn'= t seem to be major problem to make i think. >>=20 >> Starting and stopping services based on logical events and =E2=80=9Crun l= evels=E2=80=9D, apart from what devd handles with hardware events is what co= mes to mind for me. >>=20 >> rc(8) is also incredibly fragile when it comes to starting or stopping se= rvices beyond first boot, or when dealing with =E2=80=9Coptional=E2=80=9D se= rvices, like nis/yp. I tried to clean this up a few years ago, but it=E2=80=99= s not close to my ideal design (it feels like a bubblegum and duct tape sol= ution). >=20 > "incredibly fragile" indicates there is some common, easily triggered issu= e with it. Can you elaborate please? I stop and restart base services and o= thers on a regular basis and don't see an issue there although I also haven'= t use NIS for some time. Try restarting netif if you have a static route set; it will break routing (= until you restart the routing pseudo service), causing your machine to becom= e unreachable if you=E2=80=99re not on the same network segment. Linux doesn=E2=80=99t have this problem; neither does OS X. Thanks, -Enji= From owner-freebsd-hackers@freebsd.org Sun Feb 10 04:37:46 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82D0114DD633 for ; Sun, 10 Feb 2019 04:37:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (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 CB51793E59; Sun, 10 Feb 2019 04:37:44 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id sgs8gfPCh8uQmsgs9ggF1f; Sat, 09 Feb 2019 21:37:42 -0700 X-Authority-Analysis: v=2.3 cv=XKpOtjpE c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=CFTnQlWoA9kA:10 a=iKhvJSA4AAAA:8 a=xfDLHkLGAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=Y-crQ47C8yu-7etmwW0A:9 a=QiqY-oLw1HtdTI3u:21 a=alVihR9IOLASVxuU:21 a=CjuIK1q_8ugA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=IfaqVvZgccqrtc8gcwf2:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 3BB62127F; Sat, 9 Feb 2019 20:37:39 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x1A4bcbo042489; Sat, 9 Feb 2019 20:37:38 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x1A4bcGK042486; Sat, 9 Feb 2019 20:37:38 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201902100437.x1A4bcGK042486@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Rodney W. Grimes" cc: Cy Schubert , cem@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: nosh init system In-Reply-To: Message from "Rodney W. Grimes" of "Sat, 09 Feb 2019 20:20:28 -0800." <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Feb 2019 20:37:38 -0800 X-CMAE-Envelope: MS4wfNo9OaCHk0Nt+gWKEcxepfEFaC2oE82WFNF6SFl7y2yEkXdyUhcnxdCu5mb7q6vpPrc5VGRKGjEXtI3H16B9+GK2x3trysny104OrcEJp6cBNiR17qSo nDvNkSpa6Kx9iBWPE7nIDQgfsfK3FHYSF6W/5mzTwAcldbd8P8o9GTeho7CAod7hHnJNeWd23+dnX4zec+vvnXllQtnFXLpAeuaqUGQ85TJFPkaNkkRszpvs ZaY/JLnkmY9ENmd3qMbNi8DbnSLm5NjrMcmjMHgQIXg= X-Rspamd-Queue-Id: CB51793E59 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.67 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.91)[-0.905,0]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(-2.05)[ip: (-5.68), ipnet: 64.59.128.0/20(-2.53), asn: 6327(-1.97), country: CA(-0.09)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 04:37:46 -0000 In message <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net>, "Rodney W. Gri mes" writes: > > In message > il.com> > > , Conrad Meyer writes: > > > Hi Cy, > > > > > > On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert wr > ote: > > > > I don't see what's so "incredibly fragile" about rc(8). That's not to > > > > say there aren't better solutions, like SMF. > > > > > > Maybe "incredibly" as a choice of adjective is inappropriate. I think > > > we (you, me, and ngie@) can all agree it is somewhat fragile, and > > > there are things SMF/systemd/nosh get right that rc(8) does not > > > (today). Anyway, your next paragraph goes on to be a good start at > > > describing some of rc's fragility. :-) > > > > > > > Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc > > > > script could fail hosing the boot or worse hosing the system*. Where a > > > > solution like SMF solves the problem is that should a service which > > > > other services depend on fail, only that branch of the startup tree > > > > would fail. > > > > > > Right; that's a great example. > > > > > > > In that scenario, if a service fails but sshd start, a > > > > sysadmin would still be able to login remotely to resolve the problem. > > > > So in this regard rc(8) is at a disadvantage. > > > > > > > > We could address the above paragraph by starting sshd earlier during > > > > boot thereby allowing the opportunity to fix remotely. > > > > > > I don't think that is really sufficient without substantially > > > modifying init+rc to be closer to something like systemd or SMF, > > > anyway. And then we'd rather just have something like SMF :-). > > > > I'd rather see SMF but a number felt a CDDL licensed init was > > unacceptable -- except for the fact that SMF doesn't replace init. > > > > > > > > As soon as *any* rc service fails to start (signal, non-zero exit, > > > stop_boot), rc(8) exits non-zero, causing init(8) to go to single > > > user. All service state is thrown away with rc(8) exit, but any rc.d > > > "services" that managed to start before boot failed are not > > > terminated. Even if an admin manages to log in and fix the > > > configuration, re-starting rc(8) restarts the runcom process from > > > scratch, as if nothing had already been done, without first stopping > > > anything that was already running. The only safe, reproducible way to > > > re-start rc(8) is to fully reboot the system. > > It -should- be safe to restart rc, as rc scripts should check to > see if the item they are being requested to start is already running, > rc scripts that fail to have this check are defective and should be > fixed. You should be able to invate /etc/rc.d/foo start as many > times as you want in a row and only get 1 instance of foo, with the > other starts returning "foo already running" Same with stop. > > > > > It wasn't that way 10-15 years ago. It's evolved to become this. Even > > if we stay with rc(8), quickly cobbling together a patch isn't going to > > fix it long term. Whether we use another init, an add-on like SMF, or > > make rc(8) more robust, it will not be fixed by a simple tweak here or > > there. > > Much gets broken in the name of new features sadly. That was my point. Tunnel vision. > > > > > > > > > E.g., the major pain point we run into repeatedly with restarted boot > > > is that cleanvar / cleartmp run again. This breaks ld-elf.so.hints > > > cache (anything linking /usr/local libraries ??? hope your admin is > > > running base sshd and not openssh-portable!) as well as wiping out > > > /var/run pid files (breaking "already running?" rc pid checks). As a > > > result, services get double-started. > > > > > > Cleanvar could maybe be improved to avoid this problem ??? e.g., we > > > could coordinate with the kernel to set a per-boot, persisted flag > > > that cleanvar has completed, even if rc(8) exits ??? but the broad class > > > of problems would remain (rc.d autostart is stateful, but any partial > > > failure destroys all state). > > > > This needs more than improving cleanvar or some other script. It's like > > whack-a-mole. (The rest of this not specifically talking to you > > Conrad.) This is why every one to two months this topic comes up again > > and again and again. It's a pain point. (And also the shiny new object > > syndrome.) Various people suggest their favourite init(8) replacement > > and the bikeshed starts up again. > > Shiny new things also come with shiny new problems, I would actually > often rather repair a broken old something than get a new shiny > something as I know the defects of the raty old something. Agreed. Like building on a foundation of sand. > > > To avoid bikeshedding this to death again, we enumerated two issues so > > far. Let's continue to list issues. I also think that this should be a > > BSDCan devsummit whiteboard topic where we list issues in one column > > and next to it we list possible solutions, after listing all the issues > > first. And finally if this is too large for one person to work on, > > assign the various issues to willing developers. > > We do not need to wait for BSDCan, there are more of us here on this > list than at any dev summit. True but whiteboards help. My point is let's itemize a list of issues first. Write down (figuratively speaking) all ideas to address the listed issues. Select the best ideas. Implement them. > > > > > One final thought. init(8) and rc(8) requirements for desktop/laptop, > > server, embedded, and mobile are probably different enough that their > > requirements may compete with each other. Some embedded applications > > may desire a simple rc(8) whereas server or desktop a heavier weight > > solution. > > It is rather simple to just drop the whole rc.d and rewrite > /etc/rc for the embeded situtaion, going back to the 4.3 era. > > Though we might want to go over to the rc mailling list? Excellent idea! -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Sun Feb 10 04:20:45 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A41EF14DCF9A for ; Sun, 10 Feb 2019 04:20:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 DED13937BE; Sun, 10 Feb 2019 04:20:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1A4KSXR064574; Sat, 9 Feb 2019 20:20:28 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1A4KSxA064573; Sat, 9 Feb 2019 20:20:28 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> Subject: Re: nosh init system In-Reply-To: <201902100136.x1A1aXXv039736@slippy.cwsent.com> To: Cy Schubert Date: Sat, 9 Feb 2019 20:20:28 -0800 (PST) CC: cem@freebsd.org, "freebsd-hackers@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: DED13937BE X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.63 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.64)[-0.640,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.43)[0.435,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.957,0]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.02), ipnet: 69.59.192.0/19(0.01), asn: 13868(-0.02), country: US(-0.07)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 04:20:46 -0000 > In message il.com> > , Conrad Meyer writes: > > Hi Cy, > > > > On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert wrote: > > > I don't see what's so "incredibly fragile" about rc(8). That's not to > > > say there aren't better solutions, like SMF. > > > > Maybe "incredibly" as a choice of adjective is inappropriate. I think > > we (you, me, and ngie@) can all agree it is somewhat fragile, and > > there are things SMF/systemd/nosh get right that rc(8) does not > > (today). Anyway, your next paragraph goes on to be a good start at > > describing some of rc's fragility. :-) > > > > > Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc > > > script could fail hosing the boot or worse hosing the system*. Where a > > > solution like SMF solves the problem is that should a service which > > > other services depend on fail, only that branch of the startup tree > > > would fail. > > > > Right; that's a great example. > > > > > In that scenario, if a service fails but sshd start, a > > > sysadmin would still be able to login remotely to resolve the problem. > > > So in this regard rc(8) is at a disadvantage. > > > > > > We could address the above paragraph by starting sshd earlier during > > > boot thereby allowing the opportunity to fix remotely. > > > > I don't think that is really sufficient without substantially > > modifying init+rc to be closer to something like systemd or SMF, > > anyway. And then we'd rather just have something like SMF :-). > > I'd rather see SMF but a number felt a CDDL licensed init was > unacceptable -- except for the fact that SMF doesn't replace init. > > > > > As soon as *any* rc service fails to start (signal, non-zero exit, > > stop_boot), rc(8) exits non-zero, causing init(8) to go to single > > user. All service state is thrown away with rc(8) exit, but any rc.d > > "services" that managed to start before boot failed are not > > terminated. Even if an admin manages to log in and fix the > > configuration, re-starting rc(8) restarts the runcom process from > > scratch, as if nothing had already been done, without first stopping > > anything that was already running. The only safe, reproducible way to > > re-start rc(8) is to fully reboot the system. It -should- be safe to restart rc, as rc scripts should check to see if the item they are being requested to start is already running, rc scripts that fail to have this check are defective and should be fixed. You should be able to invate /etc/rc.d/foo start as many times as you want in a row and only get 1 instance of foo, with the other starts returning "foo already running" Same with stop. > > It wasn't that way 10-15 years ago. It's evolved to become this. Even > if we stay with rc(8), quickly cobbling together a patch isn't going to > fix it long term. Whether we use another init, an add-on like SMF, or > make rc(8) more robust, it will not be fixed by a simple tweak here or > there. Much gets broken in the name of new features sadly. > > > > > E.g., the major pain point we run into repeatedly with restarted boot > > is that cleanvar / cleartmp run again. This breaks ld-elf.so.hints > > cache (anything linking /usr/local libraries ??? hope your admin is > > running base sshd and not openssh-portable!) as well as wiping out > > /var/run pid files (breaking "already running?" rc pid checks). As a > > result, services get double-started. > > > > Cleanvar could maybe be improved to avoid this problem ??? e.g., we > > could coordinate with the kernel to set a per-boot, persisted flag > > that cleanvar has completed, even if rc(8) exits ??? but the broad class > > of problems would remain (rc.d autostart is stateful, but any partial > > failure destroys all state). > > This needs more than improving cleanvar or some other script. It's like > whack-a-mole. (The rest of this not specifically talking to you > Conrad.) This is why every one to two months this topic comes up again > and again and again. It's a pain point. (And also the shiny new object > syndrome.) Various people suggest their favourite init(8) replacement > and the bikeshed starts up again. Shiny new things also come with shiny new problems, I would actually often rather repair a broken old something than get a new shiny something as I know the defects of the raty old something. > To avoid bikeshedding this to death again, we enumerated two issues so > far. Let's continue to list issues. I also think that this should be a > BSDCan devsummit whiteboard topic where we list issues in one column > and next to it we list possible solutions, after listing all the issues > first. And finally if this is too large for one person to work on, > assign the various issues to willing developers. We do not need to wait for BSDCan, there are more of us here on this list than at any dev summit. > > One final thought. init(8) and rc(8) requirements for desktop/laptop, > server, embedded, and mobile are probably different enough that their > requirements may compete with each other. Some embedded applications > may desire a simple rc(8) whereas server or desktop a heavier weight > solution. It is rather simple to just drop the whole rc.d and rewrite /etc/rc for the embeded situtaion, going back to the 4.3 era. Though we might want to go over to the rc mailling list? > Cy Schubert -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sun Feb 10 15:43:38 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC03414D0478 for ; Sun, 10 Feb 2019 15:43:37 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C83EE84D4E; Sun, 10 Feb 2019 15:43:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg1-x52d.google.com with SMTP id m1so3795958pgq.8; Sun, 10 Feb 2019 07:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=waQX1cNxSYtj1eyGEcYkhbH3qLbvm/2Sy1bNMYfoK8Y=; b=IPLQKc0ZQPNrxoHX4/ma3/edMmEEJqNNpbq/7LdlADf8ZVHoaCKU+HkgYifaNwmuaD ClvEPb24JSSpMdFgCkWI+b8sWux9JbJGrED/w3j12w7JL331KsoVBHwm72OrMbORtVDw pkbFPKCPMYM4CGxkYTZBOQ9olrMyKH1B9ivXCwGy0GJxJn1jiajU1DQXj5uCD4t0RYCi sNcNytaXrcp/m5DI+KnYwV+2WysLvq+EPBDS7IeG2pS+aT5Y7COPMgS7A6vhgb+yApi0 pe724IO2hnrMaocoSgRwQMIq5RfJJckMOtecaEPfQsmUwIvzL7emiCVxWOzlADWKQVGN OVTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=waQX1cNxSYtj1eyGEcYkhbH3qLbvm/2Sy1bNMYfoK8Y=; b=fvMKPxVKxg0EnvcD2TaadB4LNbcTf2l8jqC3KN5N4wCjDry8FQuC8f3UEpK9rnU+wH nesxz12QYff2yU0bhPoI+IrWdpSUaDEMp9ayJBfuaT1G7/bRVsfpuC3VK9EiGuIuzY9N 1zhXyqRQbmXhq7oPgQiCPGJ3OMsIaPllrUyPitRDlQFPPr+XDEDDCr+T/F4n8yzzGtfW SwTtgNVEBg755E5mSkxOY2CYdkgDyXwIOToW4rc3suaXSyVlfniuv6sACOiG1ovzHcgy spaXiIz6+QlzZ8Q7ujhGBcwsmWMGqCRhzDhGWX+BdDjWbV8Zc3urL/739hoVdYQ0h5+g wJXw== X-Gm-Message-State: AHQUAubWu6p6CsxQhyqmijrOvQdNEbbj4mxAfgoOs0jdSnpwUyb3WU7T eY3rqGZR/Sep+n3ZFW27mMs+JGqa X-Google-Smtp-Source: AHgI3IZphPKUSokKv6l2AZ1nWj2LtVUFgq1oLTE6NllMmDg1Yz/UHh9QciEJPjVLs1tM2YHc/mPUAA== X-Received: by 2002:a63:134f:: with SMTP id 15mr29601693pgt.19.1549813415217; Sun, 10 Feb 2019 07:43:35 -0800 (PST) Received: from ?IPv6:2607:fb90:822b:cb2a:585b:33aa:30e0:3e12? ([2607:fb90:822b:cb2a:585b:33aa:30e0:3e12]) by smtp.gmail.com with ESMTPSA id n10sm11971679pfj.14.2019.02.10.07.43.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Feb 2019 07:43:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: nosh init system From: Enji Cooper X-Mailer: iPhone Mail (16C104) In-Reply-To: <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> Date: Sun, 10 Feb 2019 07:43:32 -0800 Cc: Cy Schubert , "freebsd-hackers@freebsd.org" , cem@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com> References: <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Rspamd-Queue-Id: C83EE84D4E X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=IPLQKc0Z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::52d as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-5.88 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.69)[-0.691,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.68)[ip: (-8.89), ipnet: 2607:f8b0::/32(-2.46), asn: 15169(-1.95), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 15:43:38 -0000 On Feb 9, 2019, at 20:20, Rodney W. Grimes wrote: >> In message > il.com> >> , Conrad Meyer writes: >>> Hi Cy, >>>=20 >>>> On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert w= rote: >>>> I don't see what's so "incredibly fragile" about rc(8). That's not to >>>> say there aren't better solutions, like SMF. >>>=20 >>> Maybe "incredibly" as a choice of adjective is inappropriate. I think >>> we (you, me, and ngie@) can all agree it is somewhat fragile, and >>> there are things SMF/systemd/nosh get right that rc(8) does not >>> (today). Anyway, your next paragraph goes on to be a good start at >>> describing some of rc's fragility. :-) >>>=20 >>>> Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc= >>>> script could fail hosing the boot or worse hosing the system*. Where a >>>> solution like SMF solves the problem is that should a service which >>>> other services depend on fail, only that branch of the startup tree >>>> would fail. >>>=20 >>> Right; that's a great example. >>>=20 >>>> In that scenario, if a service fails but sshd start, a >>>> sysadmin would still be able to login remotely to resolve the problem. >>>> So in this regard rc(8) is at a disadvantage. >>>>=20 >>>> We could address the above paragraph by starting sshd earlier during >>>> boot thereby allowing the opportunity to fix remotely. >>>=20 >>> I don't think that is really sufficient without substantially >>> modifying init+rc to be closer to something like systemd or SMF, >>> anyway. And then we'd rather just have something like SMF :-). >>=20 >> I'd rather see SMF but a number felt a CDDL licensed init was=20 >> unacceptable -- except for the fact that SMF doesn't replace init. >>=20 >>>=20 >>> As soon as *any* rc service fails to start (signal, non-zero exit, >>> stop_boot), rc(8) exits non-zero, causing init(8) to go to single >>> user. All service state is thrown away with rc(8) exit, but any rc.d >>> "services" that managed to start before boot failed are not >>> terminated. Even if an admin manages to log in and fix the >>> configuration, re-starting rc(8) restarts the runcom process from >>> scratch, as if nothing had already been done, without first stopping >>> anything that was already running. The only safe, reproducible way to >>> re-start rc(8) is to fully reboot the system. >=20 > It -should- be safe to restart rc, as rc scripts should check to > see if the item they are being requested to start is already running, > rc scripts that fail to have this check are defective and should be > fixed. You should be able to invate /etc/rc.d/foo start as many > times as you want in a row and only get 1 instance of foo, with the > other starts returning "foo already running" Same with stop. I=E2=80=99m not sure if Conrad is referring to the isilon way of restarting s= ervices. If so, the isilon parallel start process would effectively wipe the= slate clean and restart everything if interrupted, which (because of the na= ture of cleanvar, etc), would wipe out any and all pidfiles, resulting in in= weird set of services which fail to start on next run through. In short, I think the fact that isilon didn=E2=80=99t mount tmpfs to /var/ru= n was begging for pain, as it=E2=80=99s a directory one should only setup on= ce at boot. That being said, there are other pseudo services that aren=E2=80=99t necessa= rily idempotent. If they run twice, the second run could result in breakage t= o other dependent services run after them. Thanks, -Enji= From owner-freebsd-hackers@freebsd.org Sun Feb 10 16:31:08 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A52CC14D1C9C for ; Sun, 10 Feb 2019 16:31:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (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 7F86886508; Sun, 10 Feb 2019 16:31:07 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ss0UgR7pw82Ycss0WgStL1; Sun, 10 Feb 2019 09:31:05 -0700 X-Authority-Analysis: v=2.3 cv=NNSrBHyg c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=8nJEP1OIZ-IA:10 a=CFTnQlWoA9kA:10 a=pGLkceISAAAA:8 a=xfDLHkLGAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=q9H5b1F-8LV8305NIkUA:9 a=2pzhRtvYTjCweJ-p:21 a=w2PbD0VDp0Zr4D6x:21 a=wPNLvfGTeEIA:10 a=aXNZzJdwVpAA:10 a=IfaqVvZgccqrtc8gcwf2:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 1D5CC3224; Sun, 10 Feb 2019 08:31:02 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x1AGV1bw026793; Sun, 10 Feb 2019 08:31:01 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x1AGV1sa026790; Sun, 10 Feb 2019 08:31:01 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201902101631.x1AGV1sa026790@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Enji Cooper cc: "Rodney W. Grimes" , Cy Schubert , "freebsd-hackers@freebsd.org" , cem@freebsd.org Subject: Re: nosh init system In-Reply-To: Message from Enji Cooper of "Sun, 10 Feb 2019 07:43:32 -0800." <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sun, 10 Feb 2019 08:31:01 -0800 X-CMAE-Envelope: MS4wfKX69PxprP8gjR69JtsZFXSb7gP9zx30VA3fj25tIJev62I4EiEnLFtRlsR+wcltAuILRSGizB2HH4cL9NWkkwPNg2FCRBY1kNi2dd6tm1IFn4uO2KPC SntDXTaLrj/3fHUJx8uDwh6ov8e+XNWY0qIFu1GInuGE2Irb4X562xNeeIajEMUV4AvwrpI/UZS/oIPRj+ZspH1GnL4Colb9ePZYmwvuUyjCU2/RCWSqbYNT zZPcx5uEfn82PvJG7TdgORSDn9QqWyjwuJ2Y0eksTE03H4fdXiO7o0ana/1axzWJ X-Rspamd-Queue-Id: 7F86886508 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.54 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.94)[-0.942,0]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(-1.89)[ip: (-4.87), ipnet: 64.59.128.0/20(-2.52), asn: 6327(-1.96), country: CA(-0.09)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 16:31:08 -0000 In message <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com>, Enji Cooper writes : > On Feb 9, 2019, at 20:20, Rodney W. Grimes t> wrote: > > >> In message >> il.com> > >> , Conrad Meyer writes: > >>> Hi Cy, > >>> > >>>> On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert w > rote: > >>>> I don't see what's so "incredibly fragile" about rc(8). That's not to > >>>> say there aren't better solutions, like SMF. > >>> > >>> Maybe "incredibly" as a choice of adjective is inappropriate. I think > >>> we (you, me, and ngie@) can all agree it is somewhat fragile, and > >>> there are things SMF/systemd/nosh get right that rc(8) does not > >>> (today). Anyway, your next paragraph goes on to be a good start at > >>> describing some of rc's fragility. :-) > >>> > >>>> Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc > >>>> script could fail hosing the boot or worse hosing the system*. Where a > >>>> solution like SMF solves the problem is that should a service which > >>>> other services depend on fail, only that branch of the startup tree > >>>> would fail. > >>> > >>> Right; that's a great example. > >>> > >>>> In that scenario, if a service fails but sshd start, a > >>>> sysadmin would still be able to login remotely to resolve the problem. > >>>> So in this regard rc(8) is at a disadvantage. > >>>> > >>>> We could address the above paragraph by starting sshd earlier during > >>>> boot thereby allowing the opportunity to fix remotely. > >>> > >>> I don't think that is really sufficient without substantially > >>> modifying init+rc to be closer to something like systemd or SMF, > >>> anyway. And then we'd rather just have something like SMF :-). > >> > >> I'd rather see SMF but a number felt a CDDL licensed init was > >> unacceptable -- except for the fact that SMF doesn't replace init. > >> > >>> > >>> As soon as *any* rc service fails to start (signal, non-zero exit, > >>> stop_boot), rc(8) exits non-zero, causing init(8) to go to single > >>> user. All service state is thrown away with rc(8) exit, but any rc.d > >>> "services" that managed to start before boot failed are not > >>> terminated. Even if an admin manages to log in and fix the > >>> configuration, re-starting rc(8) restarts the runcom process from > >>> scratch, as if nothing had already been done, without first stopping > >>> anything that was already running. The only safe, reproducible way to > >>> re-start rc(8) is to fully reboot the system. > > > > It -should- be safe to restart rc, as rc scripts should check to > > see if the item they are being requested to start is already running, > > rc scripts that fail to have this check are defective and should be > > fixed. You should be able to invate /etc/rc.d/foo start as many > > times as you want in a row and only get 1 instance of foo, with the > > other starts returning "foo already running" Same with stop. > > I’m not sure if Conrad is referring to the isilon way of restarting service > s. If so, the isilon parallel start process would effectively wipe the slate > clean and restart everything if interrupted, which (because of the nature of > cleanvar, etc), would wipe out any and all pidfiles, resulting in in weird se > t of services which fail to start on next run through. > > In short, I think the fact that isilon didn’t mount tmpfs to /var/run was b > egging for pain, as it’s a directory one should only setup once at boot. Regardless of whether they use tmpfs or not, services should be constructed in a manner such that it should still work if the customer chooses not to use tmpfs. This also goes for those who mount /usr separately like I do (which has saved my bacon as recently as a couple of weeks ago). A change made to one of the RC scripts assumed /usr was on rootfs. (When I raised the issue the reply was "you should /usr on / anyway.") My point is that we assume our way of setting up a server is the only way and we bulldoze. In reality FreeBSD and prior to that commercial UNIX were set up variously. It's only since Linux became so popular that it has been assumed that one size fits all. These are two examples of why this approach doesn't work. POLA is painful. > > That being said, there are other pseudo services that aren’t necessarily id > empotent. If they run twice, the second run could result in breakage to other > dependent services run after them. Cleanvar being the focus of much of our discussion should be able to determine it has run before. I'm purposely not discussing implementation details. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Sun Feb 10 16:51:03 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B91A14D243B for ; Sun, 10 Feb 2019 16:51:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 2A79C86DA7; Sun, 10 Feb 2019 16:51:01 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id x1AGpDQF087068 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Feb 2019 17:51:13 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id x1AGp8Gk087065; Sun, 10 Feb 2019 17:51:08 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Sun, 10 Feb 2019 17:51:08 +0100 (CET) From: Wojciech Puchar To: Eugene Grosbein cc: Enji Cooper , Wojciech Puchar , Sidju , "freebsd-hackers@freebsd.org" , Conrad Meyer Subject: Re: nosh init system In-Reply-To: <4f873d5a-57fb-57ec-3bab-7b6c2bc65689@grosbein.net> Message-ID: References: <4f873d5a-57fb-57ec-3bab-7b6c2bc65689@grosbein.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 2A79C86DA7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-6.75 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[puchar.net]; NEURAL_HAM_SHORT(-0.85)[-0.854,0]; RCVD_IN_DNSWL_NONE(0.00)[90.144.1.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(-3.59)[ip: (-9.45), ipnet: 194.1.144.0/24(-4.73), asn: 43476(-3.78), country: PL(0.03)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 16:51:03 -0000 > Starting/stopping services beyound first boot has really only slight connection to first boot init system, > it can and should be dealt with distinct facility. > > Yes, our init system can be improved but please do not overcomplicate it with tasks > it should not solve. > > first someone wanted FreeBSD rewritten in rust, then other want to change simple and working init system with something overcomplex. From owner-freebsd-hackers@freebsd.org Sun Feb 10 20:51:05 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C82A614DB3F8 for ; Sun, 10 Feb 2019 20:51:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED44A6A11F for ; Sun, 10 Feb 2019 20:51:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id y4so10010792qtc.10 for ; Sun, 10 Feb 2019 12:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q4pFiPh74T8ODK+U8YYN6/2uaKfJbSvXMSa5S8d7SpM=; b=cz3SKcwNCWotp2lLtK/VCPEL51GzytYWyqw4y72zVGiaODkq15m3ExPgs8Yaz0+Iqs o8PkY40uTnzum+15tELJD+hGnMiM1coI7jL0cWAV7Y7IW3XE1A/ywip34uh8Jmk/AozU T7ydJuHIRkZUOA7AKBtI60B3JIjg3nvrnIxta033/FuVKio3nMmRGH45PlSr+OLqmbQS /GJGvjIPmAAAJ4tEo/f0htq1D4QO9CkeoYVXYxRMttVnZlkcTMhT733EA8+uLiJVhoKN WEewpALROwfwCvp5oaPy7PTCamWz+EwO+3t/yuk/795pKXjQn+JgFVz/RnVVVKCRly/6 xiQA== 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=Q4pFiPh74T8ODK+U8YYN6/2uaKfJbSvXMSa5S8d7SpM=; b=U0ZpMgNq8sC82QTFbhu7R5MI8Xc+iLkbLNUH+lU0PuZZvCx095SLpbdBzdzdmyI8Hv S/e05Sy0DYCMmukAodeqZKkbLZLszdQ3CZzho9w8HhcaIBufWcAFB+1QlCVZSD4/+6L7 qBA9jhSKDtrIVGijgOOxWcRcWdwd86Rd7kiz8+E3HA18NjNOYxZizxgSe6aM+FD3/1Oo RE1XWLWSR6Qhj9Y19jpQUmzWDHbk25cPmPKF9e3NZ1mYqAXPUqh9x73uaEsM0mexm9hn /h+6eSZBumjXRd+noXvfXEp0uIEneUNASh32qxUk6eWbr17VQ87XnK7OFnic7yOGaL46 /kmA== X-Gm-Message-State: AHQUAuYg13tAnFTqVxTrJLgjGL6HUneUj6Ce4JjlWa8yP+K2s3AQcEqw kqPdy3fFxsYUu2qM3oHWpMkVyzovmx9qY78Is+Dzyg== X-Google-Smtp-Source: AHgI3IbIoykylx1Eb5OdzvU5BzFxKEkkNBAEy/uC23EDiUGaNLJk6jD5sUo7NxRiGlNqlkDXf1DeKXsB/pkv2Z11puk= X-Received: by 2002:ac8:35f8:: with SMTP id l53mr18789518qtb.15.1549831862303; Sun, 10 Feb 2019 12:51:02 -0800 (PST) MIME-Version: 1.0 References: <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com> <201902101631.x1AGV1sa026790@slippy.cwsent.com> In-Reply-To: <201902101631.x1AGV1sa026790@slippy.cwsent.com> From: Warner Losh Date: Sun, 10 Feb 2019 15:50:50 -0500 Message-ID: Subject: Re: nosh init system To: Cy Schubert Cc: Garrett Cooper , "Conrad E. Meyer" , "Rodney W. Grimes" , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: ED44A6A11F X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=cz3SKcwN X-Spamd-Result: default: False [-5.39 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[a.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.86)[-0.861,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.52)[ip: (-8.09), ipnet: 2607:f8b0::/32(-2.47), asn: 15169(-1.95), country: US(-0.07)]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 20:51:05 -0000 On Sun, Feb 10, 2019, 11:34 AM Cy Schubert In message <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com>, Enji > Cooper writes > : > > On Feb 9, 2019, at 20:20, Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.ne > > t> wrote: > > > > >> In message > > >> il.com> > > >> , Conrad Meyer writes: > > >>> Hi Cy, > > >>> > > >>>> On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert < > Cy.Schubert@cschubert.com> w > > rote: > > >>>> I don't see what's so "incredibly fragile" about rc(8). That's not > to > > >>>> say there aren't better solutions, like SMF. > > >>> > > >>> Maybe "incredibly" as a choice of adjective is inappropriate. I > think > > >>> we (you, me, and ngie@) can all agree it is somewhat fragile, and > > >>> there are things SMF/systemd/nosh get right that rc(8) does not > > >>> (today). Anyway, your next paragraph goes on to be a good start at > > >>> describing some of rc's fragility. :-) > > >>> > > >>>> Where rc(8) falls down is any port or a customer's (user of > FreeBSD) rc > > >>>> script could fail hosing the boot or worse hosing the system*. > Where a > > >>>> solution like SMF solves the problem is that should a service whic= h > > >>>> other services depend on fail, only that branch of the startup tre= e > > >>>> would fail. > > >>> > > >>> Right; that's a great example. > > >>> > > >>>> In that scenario, if a service fails but sshd start, a > > >>>> sysadmin would still be able to login remotely to resolve the > problem. > > >>>> So in this regard rc(8) is at a disadvantage. > > >>>> > > >>>> We could address the above paragraph by starting sshd earlier duri= ng > > >>>> boot thereby allowing the opportunity to fix remotely. > > >>> > > >>> I don't think that is really sufficient without substantially > > >>> modifying init+rc to be closer to something like systemd or SMF, > > >>> anyway. And then we'd rather just have something like SMF :-). > > >> > > >> I'd rather see SMF but a number felt a CDDL licensed init was > > >> unacceptable -- except for the fact that SMF doesn't replace init. > > >> > > >>> > > >>> As soon as *any* rc service fails to start (signal, non-zero exit, > > >>> stop_boot), rc(8) exits non-zero, causing init(8) to go to single > > >>> user. All service state is thrown away with rc(8) exit, but any rc= .d > > >>> "services" that managed to start before boot failed are not > > >>> terminated. Even if an admin manages to log in and fix the > > >>> configuration, re-starting rc(8) restarts the runcom process from > > >>> scratch, as if nothing had already been done, without first stoppin= g > > >>> anything that was already running. The only safe, reproducible way > to > > >>> re-start rc(8) is to fully reboot the system. > > > > > > It -should- be safe to restart rc, as rc scripts should check to > > > see if the item they are being requested to start is already running, > > > rc scripts that fail to have this check are defective and should be > > > fixed. You should be able to invate /etc/rc.d/foo start as many > > > times as you want in a row and only get 1 instance of foo, with the > > > other starts returning "foo already running" Same with stop. > > > > I=C3=A2=E2=82=AC=E2=84=A2m not sure if Conrad is referring to the isilo= n way of restarting > service > > s. If so, the isilon parallel start process would effectively wipe the > slate > > clean and restart everything if interrupted, which (because of the > nature of > > cleanvar, etc), would wipe out any and all pidfiles, resulting in in > weird se > > t of services which fail to start on next run through. > > > > In short, I think the fact that isilon didn=C3=A2=E2=82=AC=E2=84=A2t mo= unt tmpfs to /var/run > was b > > egging for pain, as it=C3=A2=E2=82=AC=E2=84=A2s a directory one should = only setup once at > boot. > > Regardless of whether they use tmpfs or not, services should be > constructed in a manner such that it should still work if the customer > chooses not to use tmpfs. > Correct. If we require this. That's a bug. This also goes for those who mount /usr separately like I do (which has > saved my bacon as recently as a couple of weeks ago). A change made to > one of the RC scripts assumed /usr was on rootfs. (When I raised the > issue the reply was "you should /usr on / anyway.") My point is that we > assume our way of setting up a server is the only way and we bulldoze. > In reality FreeBSD and prior to that commercial UNIX were set up > variously. It's only since Linux became so popular that it has been > assumed that one size fits all. > > These are two examples of why this approach doesn't work. POLA is > painful. > This would also be a bug. I'd just fix the bug. I know people don't want to think of these things, but we still support separate filesystems. Saying not to run that way is lame and unhelpful. > > > That being said, there are other pseudo services that aren=C3=A2=E2=82= =AC=E2=84=A2t > necessarily id > > empotent. If they run twice, the second run could result in breakage to > other > > dependent services run after them. > > Cleanvar being the focus of much of our discussion should be able to > determine it has run before. > > I'm purposely not discussing implementation details. > Yea. That's also a sloppy bug. In this case, there is no concept of restarting... we want to run it only once... maybe that is the real bug here: we don't adequately have a way to Express that notion. Of course the bigger issue is that this is the sort of thing you want to be 100% sure is done before anything that depends on it runs. When you have a complicated topology like our start graph, that makes doing stuff in parallel hard. Warner --=20 > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sun Feb 10 22:41:09 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E24D14DFB00 for ; Sun, 10 Feb 2019 22:41:09 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 C136B6FE0E; Sun, 10 Feb 2019 22:41:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1AMexD2068211; Sun, 10 Feb 2019 14:40:59 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1AMexjU068210; Sun, 10 Feb 2019 14:40:59 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201902102240.x1AMexjU068210@pdx.rh.CN85.dnsmgr.net> Subject: Re: nosh init system In-Reply-To: To: Warner Losh Date: Sun, 10 Feb 2019 14:40:59 -0800 (PST) CC: Cy Schubert , Garrett Cooper , "Conrad E. Meyer" , "freebsd-hackers@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: C136B6FE0E X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.52 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.983,0]; NEURAL_HAM_LONG(-0.69)[-0.692,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; NEURAL_SPAM_MEDIUM(0.35)[0.351,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.02), ipnet: 69.59.192.0/19(0.01), asn: 13868(-0.02), country: US(-0.07)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 22:41:09 -0000 > On Sun, Feb 10, 2019, 11:34 AM Cy Schubert > > In message <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com>, Enji > > Cooper writes > > : > > > On Feb 9, 2019, at 20:20, Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.ne > > > t> wrote: > > > > > > >> In message > > > > >> il.com> > > > >> , Conrad Meyer writes: > > > >>> Hi Cy, > > > >>> > > > >>>> On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert < > > Cy.Schubert@cschubert.com> w > > > rote: > > > >>>> I don't see what's so "incredibly fragile" about rc(8). That's not > > to > > > >>>> say there aren't better solutions, like SMF. > > > >>> > > > >>> Maybe "incredibly" as a choice of adjective is inappropriate. I > > think > > > >>> we (you, me, and ngie@) can all agree it is somewhat fragile, and > > > >>> there are things SMF/systemd/nosh get right that rc(8) does not > > > >>> (today). Anyway, your next paragraph goes on to be a good start at > > > >>> describing some of rc's fragility. :-) > > > >>> > > > >>>> Where rc(8) falls down is any port or a customer's (user of > > FreeBSD) rc > > > >>>> script could fail hosing the boot or worse hosing the system*. > > Where a > > > >>>> solution like SMF solves the problem is that should a service which > > > >>>> other services depend on fail, only that branch of the startup tree > > > >>>> would fail. > > > >>> > > > >>> Right; that's a great example. > > > >>> > > > >>>> In that scenario, if a service fails but sshd start, a > > > >>>> sysadmin would still be able to login remotely to resolve the > > problem. > > > >>>> So in this regard rc(8) is at a disadvantage. > > > >>>> > > > >>>> We could address the above paragraph by starting sshd earlier during > > > >>>> boot thereby allowing the opportunity to fix remotely. > > > >>> > > > >>> I don't think that is really sufficient without substantially > > > >>> modifying init+rc to be closer to something like systemd or SMF, > > > >>> anyway. And then we'd rather just have something like SMF :-). > > > >> > > > >> I'd rather see SMF but a number felt a CDDL licensed init was > > > >> unacceptable -- except for the fact that SMF doesn't replace init. > > > >> > > > >>> > > > >>> As soon as *any* rc service fails to start (signal, non-zero exit, > > > >>> stop_boot), rc(8) exits non-zero, causing init(8) to go to single > > > >>> user. All service state is thrown away with rc(8) exit, but any rc.d > > > >>> "services" that managed to start before boot failed are not > > > >>> terminated. Even if an admin manages to log in and fix the > > > >>> configuration, re-starting rc(8) restarts the runcom process from > > > >>> scratch, as if nothing had already been done, without first stopping > > > >>> anything that was already running. The only safe, reproducible way > > to > > > >>> re-start rc(8) is to fully reboot the system. > > > > > > > > It -should- be safe to restart rc, as rc scripts should check to > > > > see if the item they are being requested to start is already running, > > > > rc scripts that fail to have this check are defective and should be > > > > fixed. You should be able to invate /etc/rc.d/foo start as many > > > > times as you want in a row and only get 1 instance of foo, with the > > > > other starts returning "foo already running" Same with stop. > > > > > > I???m not sure if Conrad is referring to the isilon way of restarting > > service > > > s. If so, the isilon parallel start process would effectively wipe the > > slate > > > clean and restart everything if interrupted, which (because of the > > nature of > > > cleanvar, etc), would wipe out any and all pidfiles, resulting in in > > weird se > > > t of services which fail to start on next run through. > > > > > > In short, I think the fact that isilon didn???t mount tmpfs to /var/run > > was b > > > egging for pain, as it???s a directory one should only setup once at > > boot. > > > > Regardless of whether they use tmpfs or not, services should be > > constructed in a manner such that it should still work if the customer > > chooses not to use tmpfs. > > > > Correct. If we require this. That's a bug. > > This also goes for those who mount /usr separately like I do (which has > > saved my bacon as recently as a couple of weeks ago). A change made to > > one of the RC scripts assumed /usr was on rootfs. (When I raised the > > issue the reply was "you should /usr on / anyway.") My point is that we > > assume our way of setting up a server is the only way and we bulldoze. > > In reality FreeBSD and prior to that commercial UNIX were set up > > variously. It's only since Linux became so popular that it has been > > assumed that one size fits all. > > > > These are two examples of why this approach doesn't work. POLA is > > painful. > > > > This would also be a bug. I'd just fix the bug. I know people don't want to > think of these things, but we still support separate filesystems. Saying > not to run that way is lame and unhelpful. Then I'll done my nomex and jump in with seperate /usr is rather seriously broken and neglected, to the point diskless booting with seperate /usr is marginal and I actually gave up fighting it and merged my / to /usr on the diskless server. I really would like to see this fixed and remove that merging. > > > That being said, there are other pseudo services that aren???t > > necessarily id > > > empotent. If they run twice, the second run could result in breakage to > > other > > > dependent services run after them. > > > > Cleanvar being the focus of much of our discussion should be able to > > determine it has run before. > > > > I'm purposely not discussing implementation details. > > > > Yea. That's also a sloppy bug. In this case, there is no concept of > restarting... we want to run it only once... maybe that is the real bug > here: we don't adequately have a way to Express that notion. > > Of course the bigger issue is that this is the sort of thing you want to be > 100% sure is done before anything that depends on it runs. When you have a > complicated topology like our start graph, that makes doing stuff in > parallel hard. We do not have to wait for fsck any more, that was a huge upside, even parallel fsck was at the mercy of your largest partition. Doesnt the openrc thing have this parrallel startup stuff in it, and what happened to that FPC to move forward on that, did it end up in the "lacks enough round tuits" basket? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sun Feb 10 23:20:37 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AD8814E0D19 for ; Sun, 10 Feb 2019 23:20:37 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B39B47129B for ; Sun, 10 Feb 2019 23:20:36 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f177.google.com with SMTP id h193so21910643ita.5 for ; Sun, 10 Feb 2019 15:20:36 -0800 (PST) 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:reply-to :from:date:message-id:subject:to:cc; bh=lq9aPUmJMhL/9logtrGxZH4a+3t0WDmv34ZSnPR2/HI=; b=exmv803o7oSyvsmEiR/RqfpmNfbsA9nDLHa/toxnOOIgf/hyvK9xrQrcRxLgmtYvgm h1JcodXz3cyhYU74O+xQ14jFBpdgcWSre/N72SvMFUQHGrE/yi7YTLtfGOHRc7Mbzi3+ 7KZ/Rn7Hf6zXrrVeLYl9aBumERxbK+1jzZ0/1hjce1uvFn/+gQeb9VFCGdVhjtpMaw0/ f6w4BFQK+Q3CuMq2gczps2BxJS7mihXbNN1liNWmeYZZRo75H4kRs8TrHDpsOa4a7GsF HE0A8KgyoNGJRpFrRrg+8fVR0ne7gT1Zs/UZkjChh+W/1kNINnarf3QoYzN7SVzmVpIz Ff0w== X-Gm-Message-State: AHQUAuY9jDUL5MdNc2KhpJx+YPbiMnpLJ7LBJd1pxNwLeEa4nWlBRNiY 4v8qkpznNb/c/vrd+DSXcFTcbsAL X-Google-Smtp-Source: AHgI3IaN2KPKo0oj5U/G5cy4+uJEAo5zdUXAaG1mcA2rAo8IjAmjD53AIJwHu/y4LUQt34SoR8XvVg== X-Received: by 2002:a02:1c41:: with SMTP id c62mr16013996jac.109.1549840829666; Sun, 10 Feb 2019 15:20:29 -0800 (PST) Received: from mail-it1-f175.google.com (mail-it1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id y10sm3963710iom.9.2019.02.10.15.20.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Feb 2019 15:20:29 -0800 (PST) Received: by mail-it1-f175.google.com with SMTP id a6so21919899itl.4 for ; Sun, 10 Feb 2019 15:20:29 -0800 (PST) X-Received: by 2002:a24:b64a:: with SMTP id d10mr4416415itj.149.1549840829158; Sun, 10 Feb 2019 15:20:29 -0800 (PST) MIME-Version: 1.0 References: <201902100136.x1A1aXXv039736@slippy.cwsent.com> <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sun, 10 Feb 2019 15:20:18 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: nosh init system To: "Rodney W. Grimes" Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B39B47129B X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.177 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-5.80 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.83)[-0.826,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; IP_SCORE(-2.96)[ip: (-9.01), ipnet: 209.85.128.0/17(-3.77), asn: 15169(-1.95), country: US(-0.07)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[177.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 23:20:37 -0000 On Sat, Feb 9, 2019 at 8:20 PM Rodney W. Grimes wrote: > It -should- be safe to restart rc, as rc scripts should check to > see if the item they are being requested to start is already running, It isn't, as described in detail in the email Cy replied to. There is some difficulty in making scripts idempotent even in relatively happy cases; not everything has a pid file (and pid files are not a particularly robust system anyway). Even harder are weird corner cases like interrupted and resumed boot, that are rarely or never tested. Shell is just a poor language for any sophisticated behavior or robust error handling. Conrad From owner-freebsd-hackers@freebsd.org Mon Feb 11 03:26:44 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E954414E6C9B for ; Mon, 11 Feb 2019 03:26:43 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A877880EF5 for ; Mon, 11 Feb 2019 03:26:42 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x32a.google.com with SMTP id t200so14125404wmt.0 for ; Sun, 10 Feb 2019 19:26:42 -0800 (PST) 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=yV1SflUCh1SqrLoW9IIzGSUCPDRTy8CofL4f0TURcbA=; b=nqhK1TxhsgUfXhokhgvBi+3tjqUrudVQU9b6oVtOoEmB4HHXetMnHq1o6rlyLd+Fn5 uW6ksA5ELIngmsliKj7yQA0XNI34gzKvduwJZTFQPRJD4UOc23pULUawm9qS82FEQ++h Q+sxyoikIWDA8qoo2KohdJfNMQYnDaSk9FSsI2RKKJfAe5wiP43YFSmF602CZ8XlvE7b GE12c7FCrWVNLCdDKEKZiZF8VozRl+NPMsJFZL5nH9i2htVrBuVHKj8QtxsYx/Ygx0fY yjHpEGGZG1Hk3t7G2hM8XjXua3aO0cRIPjJDfp39bhpLGUhZgS8o5VaK3uOThJksS0Bk FcAw== 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=yV1SflUCh1SqrLoW9IIzGSUCPDRTy8CofL4f0TURcbA=; b=fd7TV9M9/E0HDSHWdDfDbb/AQd09dDuNuu4zxhuR5NkhsBkOwtshFRVioxeZc2vsr0 msuqswCLAhjcDUMvwo0jJnsk21e7v1tN9cOz2uOLbJTXTb+P7o4w8JSYTlRYo9KdnJqv a0ShU4H/Z+xtQ4q6TDFaSxbsNhqYwaml88XPbjXl2X2RzC5dRkMRE3n+zAhSa+GNJKhM ryihEoyhmfdNhDr4LL861KDl6vqTtmYlwDYMR9vOUsxsmbbumGTAgWX8KIZanzTrKEk1 e+lf+I7ghoTyOIDrNp/ubyiSkW2Uvjs1xQNeMHhyQoNcEqO7ODFUfLVo/Vb6XdhcAk3t ZgPQ== X-Gm-Message-State: AHQUAuYRjDKUaRRB7l4BNx/RGy04Gekna3a7uYAR58uCSOVBRZuN+W8q 14Pvam3DofE+zKkhX2GgGBoE/Jn00m0= X-Google-Smtp-Source: AHgI3IbTzEOdVv/+x8k/e3Jw5I2ihKAEDBlKuBEtNLTZhnWo+tsYLFWwkmOaM6kNcpXbOhkbow3wGQ== X-Received: by 2002:a1c:6342:: with SMTP id x63mr7268662wmb.92.1549855600153; Sun, 10 Feb 2019 19:26:40 -0800 (PST) Received: from [192.168.1.7] (79-66-139-63.dynamic.dsl.as9105.com. [79.66.139.63]) by smtp.gmail.com with ESMTPSA id 62sm20940691wra.46.2019.02.10.19.26.39 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 10 Feb 2019 19:26:39 -0800 (PST) Subject: Restarting netif, static addressing/routing (was: nosh init system) To: freebsd-hackers@freebsd.org References: <01CB4D6D-0958-42E3-9BD6-149B0A26DB95@gmail.com> From: Graham Perrin Message-ID: Date: Mon, 11 Feb 2019 03:26:38 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <01CB4D6D-0958-42E3-9BD6-149B0A26DB95@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: A877880EF5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=nqhK1Txh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-6.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; 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]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.81)[ip: (-9.72), ipnet: 2a00:1450::/32(-2.29), asn: 15169(-1.95), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[a.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 03:26:44 -0000 On 10/02/2019 03:17, Enji Cooper wrote: > … Try restarting netif if you have a static route set; it will break routing (until you restart the routing pseudo service), … Ha, I imagined that it was _me_ breaking things :-) Somewhere (on the disk of a notebook that was thrown from a window (don't ask)) I have a long, probably very messy script that used to help me regain Internet access after e.g. switching from eduroam to a wired 'staff' network with static addressing. From owner-freebsd-hackers@freebsd.org Mon Feb 11 14:35:58 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAA5114D8AE9 for ; Mon, 11 Feb 2019 14:35:58 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6BE6FAFA for ; Mon, 11 Feb 2019 14:35:58 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 08CD714D8AE8; Mon, 11 Feb 2019 14:35:58 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D587F14D8AE7 for ; Mon, 11 Feb 2019 14:35:57 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FC8B6FAF5 for ; Mon, 11 Feb 2019 14:35:56 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C0CB.dip0.t-ipconnect.de [46.82.192.203]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id x1BDdwgM077497 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Feb 2019 13:40:12 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id x1BDdtdD034446; Mon, 11 Feb 2019 14:39:55 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id x1BDdbBB039254; Mon, 11 Feb 2019 14:39:49 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201902111339.x1BDdbBB039254@fire.js.berklix.net> To: Matthias Apitz cc: hackers@freebsd.org Subject: Re: bsd android tethering using USB cable - intermittent failure From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Aachen Kent User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Wed, 06 Feb 2019 09:05:11 +0100." <20190206080511.GA22504@sh4-5.1blu.de> Date: Mon, 11 Feb 2019 14:39:37 +0100 X-Rspamd-Queue-Id: 7FC8B6FAF5 X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [6.37 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_MISSING_CHARSET(2.50)[]; MISSING_MIME_VERSION(2.00)[]; BROKEN_CONTENT_TYPE(1.50)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: land.berklix.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.86)[-0.859,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[203.192.82.46.zen.spamhaus.org : 127.0.0.10]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.851,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.97)[0.971,0]; R_SPF_NA(0.00)[]; GREYLIST(0.00)[pass,body]; IP_SCORE(0.21)[ip: (0.68), ipnet: 144.76.0.0/16(2.67), asn: 24940(-2.26), country: DE(-0.01)] X-Spam: Yes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 14:35:59 -0000 Matthias Apitz wrote: Wed, 6 Feb 2019 09:05:11 +0100 > El día Tuesday, February 05, 2019 a las 05:34:42PM +0100, Julian H. Stacey escribió: > > > Thanks , Yes I've got developer mode on (7 taps on build version) > > & dont know how to lock display so always on, & yes I do always > > touch screen to tether. > > > > Ive tried rebooting BSD today didnt help. Dont think ive tried > > rebooting the Androids today. I wondered if I had some hidden > > faulty initialiser file so just removed a bunch of ~/.[a-zA-Z]* > > that I didnt recognise or didnt want. > > > > Weirdly, adb shell has now just connected on the phone I want to > > move data on. > > > > & also weirdly ifconfig -a > > does Not display a ue0: eg from past: > > ue0: flags=8802 metric 0 mtu 1500 > > ether xx:xx:xx:xx:xx:xx > > though I thought I needed ue to tether with, > > ifconfig -a just shows ether & local bge0: & lo0: > > > > Unfortunately my background devd set up the connection before I > > killed it & switched to foreground /sbin/devd -d so xterm scroll > > back does not show what device, but I grabbed a tar copy of /dev > > to look at later > > > > My Android popped up with a less often seen screen: USB PC Connection > > Connect as > > Media device (MTP) which shows pre-ticked Green > > Camera (PTP) which shows blank, un-checked. > > > > Well I wont disturb that pair of devs that are ready to talk, > > I'll start long transfer of data I need, > > > > but I will contine to experiment on another pair of devs, Hi Matthias & all, > I think you must not have this interface 'ue0', Yes, you'r right, thanks, Tethering the smart phone kills the adb direct over usb connection, not surprising in retrospect ;-) > i.e. you must not enable > 'rndis' in the gadget. Or use TCP and SSH or ADB, not both. See this > life example: > > I have not set in the BQ: I presume BQ is your name for your phone type. > android-gadget-service enable rndis I don't know what file on bsd or android you refer to. (Fortunately android 6 has find & grep (earlier does not)), but I find nothing with these: On android: cd /etc;find . -type f -exec grep android-gadget-service {} /dev/null \; On current freebsd : man urndis cd /usr/src ; find . -type f -exec grep android-gadget-service {} \; > # ifconfig ue0 > ifconfig: interface ue0 does not exist > > attach E4.5 Too cryptic, not sure what you mean. attach is not a command on android 6 or freebsd current uname -a Linux localhost 3.4.0-12884729 #1 SMP PREEMPT Mon Jan 15 16:53:44 KST 2018 armv7l shell@klte:/ $ Though attach is a label for bsd /etc/devd/*.conf & I recall attach a dev to an interface of old, eg slattach etc. & on freebsd current : apropos attach : man devmatch & devinfo | grep rndis # only shows urndis0 when I click tether on android > # tail /var/log/messages > ... > Feb 6 08:50:16 c720-r342378 kernel: ugen0.4: at usbus0 > > # adb start-server > * daemon not running; starting now at tcp:5037 > * daemon started successfully > > # adb devices -l > List of devices attached > JU000435 device usb:0:4 product:krillin model:Aquaris_E4_5_Ubuntu_Edition device:krillin transport_id:1 Yes, ths was my problem after tethering I was not seeing any devices, now I dont teher & can connect again & move files. > > # adb shell > phablet@ubuntu-phablet:~$ > phablet@ubuntu-phablet:~$ uname -a > Linux ubuntu-phablet 3.4.67 #1 SMP PREEMPT Mon Jun 6 12:04:40 UTC 2016 b75400e armv7l armv7l armv7l GNU/Linux PS Later I'll tether again. My end aim is find an app for android that supports NFS & AMD, so the phone can seamlessly become part of my file system on BSD. but a search on http://play.google.com & http://www.fdroid.org shows nothing obvious. I'll probably have to root the phone too before that, & I didnt root, till after I could backup, & backup wasnt easy with no knowledge of FS tree, & no commands find & grep on my older android, & locked read permissions in non root, it was chicken & egg. Tips welcome, I add them to my http://www.berklix.com/android/ Thanks Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent UK Stole 700,000 votes from British in EU + 3 million globally; 1.9 M in UK were too young + 1.3 M died. Fraud, fines & lies. Brexit is minority. 2nd Ref. Blind Chaos & slump? Or revoke #50, plan better first, maybe re-file later. http://www.berklix.uk/brexit/#email_an_mp From owner-freebsd-hackers@freebsd.org Tue Feb 12 02:46:39 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B544414D045E for ; Tue, 12 Feb 2019 02:46:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 55D9E6AA40 for ; Tue, 12 Feb 2019 02:46:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-163.hsd1.wa.comcast.net [73.225.95.163]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id x1C2KpZP065592 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Feb 2019 18:20:53 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: nosh init system To: Sidju , freebsd-hackers@freebsd.org References: From: Julian Elischer Message-ID: Date: Mon, 11 Feb 2019 18:20:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 55D9E6AA40 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.90 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.90)[-0.904,0]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 02:46:39 -0000 On 2/8/19 12:50 PM, Sidju via freebsd-hackers wrote: > Hi everyone. > > I might be missing something since I have only been in the group for a few months, but is anyone looking at the "nosh" init system ( https://jdebp.eu/Softwares/nosh/ )? > >From what I have read there is some talk of writing a new init system; is nosh known to be bad in some way or just obscure (it did take me a decent while to find)? > > >From what I can find it is aiming to fill an systemd-shaped hole in a better way and while maintaining compatibility with BSD. I am not exceptionally read in and may be missing some pitfalls. > > I am curious what you think of it. > > /Sidju > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > so I see that no one answered the question.. Why are we as a group completely ignoring the work the author of nosh is doing if no one has a clue as to why he's doing t or what the supposed advantages and problems would be. For that matter what about the apple stuff? it would be at least worth taking a good look at it and discussing it here.. From owner-freebsd-hackers@freebsd.org Tue Feb 12 04:43:52 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0709014D51F5 for ; Tue, 12 Feb 2019 04:43:52 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B93056F7C6 for ; Tue, 12 Feb 2019 04:43:50 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x32b.google.com with SMTP id f16so1475017wmh.4 for ; Mon, 11 Feb 2019 20:43:50 -0800 (PST) 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=50DTv0ayzEXS+vPa848O4GKyjgQaSZoIgrLLpUc+Buw=; b=AN9+Zdnxjan/nQzfE3Vd4jACwdURw7jBBCq2ig3Xsbd0TDI+WglOUh/F/TYyuqnEkT aTqVsKrTCWfQwuA5ZzxJedGAPdw1jkFfDK/KVNK0eUSkJQ1mdMCVSvOI9oOzTIaMEUj2 DeNl8kgeXvm10/fVNW5t+sUMt+ijgVZw6NCfJgHviaDzmLImfi1oRh7/uIooqyNEI2Nr GyspCHlAU/1ZaKiiksXBnv92ZsgJwZ2Wo0kSmx4TyINM01Y+T/MSR8eaERrrh8bQh1Qp nZPUxT52Is+ikYdFSa47GrOYYH2pNcXPEPDiJgs6rQkAFEoogxsI0rg4HKVQV06PnVz6 vFyA== 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=50DTv0ayzEXS+vPa848O4GKyjgQaSZoIgrLLpUc+Buw=; b=iosxwKSfmujdW/5H0HQf98GmoPThOlY1I60DkqqituJyJMgMGSyCALbDIPCzEEF9bH qryDDc7utAKMmeCGSziRy5ECdo8vdHIlNT+5VHCM8PKFwj00XBl0AWymGDGot2Q9tbQX bLNPfw+f9+8KrfPHvyYCbn/kfdbjVn7fjcAutvZ49mo+6veYrUARiYlEcxmQ5dooIGmu Gs5oqScOUxu7QIRHn9aXY406IEQjey050p0akBO/BxFFPv69OWfWsoqgSWhAwRB6o3eZ Xf/NIMW48v6Dj/+DCPtm1brhRPIwQk/cm/t4ZPmgx4R0i2cgaRNndhSW62TGT8KuAHjW uZSg== X-Gm-Message-State: AHQUAubzL4VW3V6jFNJ4jeJTreVtJkdH8I8xGcltUOgPU9zRlvYzb6nR 3TP291fzs013mA91NfaoTxS6oUvDTsc= X-Google-Smtp-Source: AHgI3IbvHVj3eLzQCMUP37BbFT3iqVjYUuIsBI7swWP2/m2ZDzNKWyVLEx3uP2+ap1BlLs0k3T0Big== X-Received: by 2002:a1c:7c07:: with SMTP id x7mr1166628wmc.82.1549946628974; Mon, 11 Feb 2019 20:43:48 -0800 (PST) Received: from [192.168.1.7] (79-66-139-63.dynamic.dsl.as9105.com. [79.66.139.63]) by smtp.gmail.com with ESMTPSA id q21sm2367133wmc.14.2019.02.11.20.43.47 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 20:43:47 -0800 (PST) Subject: Re: nosh init system To: freebsd-hackers@freebsd.org References: From: Graham Perrin Message-ID: Date: Tue, 12 Feb 2019 04:43:46 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: B93056F7C6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=AN9+Zdnx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32b as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-6.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.86)[-0.862,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.61)[ip: (-8.74), ipnet: 2a00:1450::/32(-2.28), asn: 15169(-1.96), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[b.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 04:43:52 -0000 On 12/02/2019 02:20, Julian Elischer wrote: > … Why are we as a group completely ignoring the work the author of nosh is > doing if no one has a clue as to why he's doing t or what the supposed > advantages and problems would be. … Some clues may be found at/around . I bookmarked in relation to nosh but sadly re: the forum was taken down, and (sorry) the required post seems to be not amongst the things that I captured before the take-down. From owner-freebsd-hackers@freebsd.org Tue Feb 12 04:55:46 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B8D414D56B5 for ; Tue, 12 Feb 2019 04:55:46 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D44396FD34 for ; Tue, 12 Feb 2019 04:55:44 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id r2so1132653wrv.10 for ; Mon, 11 Feb 2019 20:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=kadIA5kK73zMC/Wy64yQtS9fECGyV1jSEQnbrNfXqKg=; b=EmdWg8kIYAFwtbeXpAoom31G3l/h7sqeakFwRvKptQubRYimVryVTFysHo2qHTSBd1 JNNyjyu+7FcDVEd9O1jDr1TEYPRs5QMzMK3fACL+GWi9R2HreMlqvl/SN9rG0bkv0z8J TzG3wg7GvV/lgzfx/a4RBFfxDXf4s7zlH908hqltBn0boSj33hK6d8JNSJs5v0q7Z0lp Qo1g62fUqH5YiRHzrVtKoHuy94EQGZR1AdRiMXPHi5XjAtrQ6bIKI9xSRnqXMAPJc67P sH8Sjb5r7pjRc1mqYkQikWVO8gjyVAYGn7BE/Rix74uveNwGRin8UGTzgmLkgU61Sv3B 9h0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kadIA5kK73zMC/Wy64yQtS9fECGyV1jSEQnbrNfXqKg=; b=sonFPotxzGKDTVO6kKGxEY7PGUSTe2yvIw7SbKB5mpcHtwSr3j7s2FihLExlEZUJQJ b7xVHRwW2/Z1nSsdKAQDRf8azA5/WnRjiw/WJH172rWtJYEHce+VUbH7bTmBMw/01cFz Ns5IOL7tB6abXZdGqf3Rh+5Jr5lI3g+rgi8yQONxzTmaCkitJv17pKcyHTXnaRYpheBL QVq12eISs0SkpHk6DrmCiPa8dl+qeeSW+HeGYhVPs8SeUg3Biaz2+AE8/cvN8dZmFV72 w/cOD268NeG5Ny3TtS/U4CLTilrqKkRgbEWMxIaxJMNAjO9xbrsjhdCxD/0nfqjeUTKL kLjw== X-Gm-Message-State: AHQUAuaSIvM3XKi41/5BaNDNrk0Sy7f4pNYZW9brpn5Wuckz1L50J97j wTLO0UsMqRWSeNrmxlyvqgRb8Bpen4g= X-Google-Smtp-Source: AHgI3IbduoZL0R9VHU6DB2yUFIpw8Fm3kZBy1Bo+GVymt5Ki/29+YsRu5KC45BtuVARCS7g7D+kNZA== X-Received: by 2002:adf:fb0d:: with SMTP id c13mr1293533wrr.285.1549947343084; Mon, 11 Feb 2019 20:55:43 -0800 (PST) Received: from [192.168.1.7] (79-66-139-63.dynamic.dsl.as9105.com. [79.66.139.63]) by smtp.gmail.com with ESMTPSA id 62sm30095864wra.46.2019.02.11.20.55.41 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 20:55:42 -0800 (PST) Subject: Re: nosh init system From: Graham Perrin To: freebsd-hackers@freebsd.org References: Message-ID: <9c435d7d-500e-12e9-9819-7ae68515e144@gmail.com> Date: Tue, 12 Feb 2019 04:55:41 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: D44396FD34 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=EmdWg8kI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::433 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-6.65 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.87)[-0.871,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.77)[ip: (-9.53), ipnet: 2a00:1450::/32(-2.29), asn: 15169(-1.96), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[3.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 04:55:46 -0000 Also amongst my bookmarks (not recent, but maybe of interest): – ignore the ntlworld links Welcome openrc . The good question is what happened to launchd , runit and , and... | Hacker News From owner-freebsd-hackers@freebsd.org Tue Feb 12 09:16:08 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48F1A14DEA12 for ; Tue, 12 Feb 2019 09:16:08 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B97B982707 for ; Tue, 12 Feb 2019 09:16:07 +0000 (UTC) (envelope-from guru@unixarea.de) Received: by mailman.ysv.freebsd.org (Postfix) id 72DFC14DEA08; Tue, 12 Feb 2019 09:16:07 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 617E014DEA06 for ; Tue, 12 Feb 2019 09:16:07 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from smh-06.1blu.de (smh-06.1blu.de [178.254.0.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0239682701 for ; Tue, 12 Feb 2019 09:16:06 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [172.16.29.5] (helo=sh4-5.1blu.de) by smh-06.1blu.de with esmtp (Exim 4.86_2) (envelope-from ) id 1gtUAU-0003ps-Gu; Tue, 12 Feb 2019 10:15:54 +0100 Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.86_2) (envelope-from ) id 1gtUAU-0002zJ-B5; Tue, 12 Feb 2019 10:15:54 +0100 Date: Tue, 12 Feb 2019 10:15:54 +0100 From: Matthias Apitz To: "Julian H. Stacey" Cc: hackers@freebsd.org Subject: Re: bsd android tethering using USB cable - intermittent failure Message-ID: <20190212091554.GA8813@sh4-5.1blu.de> Reply-To: Matthias Apitz References: <20190206080511.GA22504@sh4-5.1blu.de> <201902111339.x1BDdbBB039254@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201902111339.x1BDdbBB039254@fire.js.berklix.net> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 0239682701 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 09:16:08 -0000 El día Monday, February 11, 2019 a las 02:39:37PM +0100, Julian H. Stacey escribió: > Hi Matthias & all, > > > I think you must not have this interface 'ue0', > > Yes, you'r right, thanks, Tethering the smart phone kills > the adb direct over usb connection, not surprising in retrospect ;-) > > > > i.e. you must not enable > > 'rndis' in the gadget. Or use TCP and SSH or ADB, not both. See this > > life example: > > > > I have not set in the BQ: > > I presume BQ is your name for your phone type. Yes. It is an E4.5 produced by the Spanish company BQ.com. It runs an Ubuntu Touch on top of an Android kernel. > > android-gadget-service enable rndis > > I don't know what file on bsd or android you refer to. (Fortunately > android 6 has find & grep (earlier does not)), but I find nothing > with these: > On android: > cd /etc;find . -type f -exec grep android-gadget-service {} /dev/null \; > On current freebsd : > man urndis > cd /usr/src ; find . -type f -exec grep android-gadget-service {} \; No. This is a shell command in the Ubuntu Touch. I was hoping that Android has something similar in your device. It enables tethering, which we don't want to have here in our case of ADB. > > > > # ifconfig ue0 > > ifconfig: interface ue0 does not exist > > > > attach E4.5 > > Too cryptic, not sure what you mean. I meant: I just pluged-in the USB cable from the E4.5 to my laptop. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. From owner-freebsd-hackers@freebsd.org Tue Feb 12 21:21:55 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9835414D1792 for ; Tue, 12 Feb 2019 21:21:55 +0000 (UTC) (envelope-from contact@emersion.fr) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 400E8836F1 for ; Tue, 12 Feb 2019 21:21:54 +0000 (UTC) (envelope-from contact@emersion.fr) Date: Tue, 12 Feb 2019 21:21:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail; t=1550006505; bh=d3t+yRClfI0pDnYxS0CBvcplPF2jUJ6wyI2Ju0MO2/0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=frNuP21/EmDqr0qW3PtrcvYjpkD3iTGaJHs2/YSMNotxMSAQ0R4Y04bDrpptJvrOm hxfe4N3SH/9AM9qmJrJri73Z6yWr5xIy8BPcta5vt1LxgDR+Krl/sa4rZzbW8D1Ipf i0CsgC/XRCIzFBMMwGYCuw15CyJPwStpExoCYrPs= To: Eugene Grosbein From: Simon Ser Cc: "freebsd-hackers@freebsd.org" , Drew DeVault Reply-To: Simon Ser Subject: Re: Unattended FreeBSD installation Message-ID: In-Reply-To: References: Feedback-ID: FsVprHBOgyvh0T8bxcZ0CmvJCosWkwVUg658e_lOUQMnA9qynD8O1lGeniuBDfPSkDAUuhiKfOIXUZBfarMyvA==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: 400E8836F1 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=emersion.fr header.s=protonmail header.b=frNuP21/; dmarc=pass (policy=none) header.from=emersion.fr; spf=pass (mx1.freebsd.org: domain of contact@emersion.fr designates 185.70.40.18 as permitted sender) smtp.mailfrom=contact@emersion.fr X-Spamd-Result: default: False [-7.72 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[emersion.fr:s=protonmail]; HAS_REPLYTO(0.00)[contact@emersion.fr]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[emersion.fr:+]; DMARC_POLICY_ALLOW(-0.50)[emersion.fr,none]; MX_GOOD(-0.01)[mail.protonmail.ch]; IP_SCORE(-3.64)[ip: (-9.27), ipnet: 185.70.40.0/24(-4.91), asn: 19905(-3.93), country: US(-0.07)]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; RCVD_COUNT_ZERO(0.00)[0]; RCVD_IN_DNSWL_LOW(-0.10)[18.40.70.185.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19905, ipnet:185.70.40.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:21:55 -0000 On Wednesday, February 6, 2019 12:34 AM, Eugene Grosbein wrote: > In fact, there is absolutely nothing sacral in generating bootable FreeBS= D image. Thanks for your suggestion! (Actually, thanks everybody for their replies -- it's very helpful) I finally managed to write a script to generate images, with a lot of help from Dave Cottlehuber [1]. The full image generation script is available at [2]. [1]: https://hackmd.io/s/SJRD7QRNE [2]: https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/freebsd/ge= nimg From owner-freebsd-hackers@freebsd.org Wed Feb 13 20:33:57 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE7CB14D70D1 for ; Wed, 13 Feb 2019 20:33:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC0D073011 for ; Wed, 13 Feb 2019 20:33:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: _e5UpQUVM1mGUYOgQoQtoxcBiA2fciWs4Aju6Hip1je0x63Bd5hxd_Y2hk20Jwa VruBR8VsUpr0NdWRmTo.yM.fK0NoCJLkoEs4vzNiqVnqRyFbRINmU2TAJDSQUDAfFpbzOS4Vq8Is VNNzd9lDZAkoYUaATzDA.kCK6yEoZ8mGsKdBqMsBYbhj1P2qwV0d0qZl2mYP0kVaS8H6jg1F7CPO 9n1WzJRWzv9eki4IuK6NiF4IIzpKcT64bBJ9b.J9K6SxPPVgWaN65tRMgE_b.5e4EBEun4dF0wEL gqhrwGaEc2NV3b6F.7Th2pw8Bz_ZNxn17LGA8qQnHw_c54Ljd6hoMjlgs.VzAm5lFa5zKOAK7jQs gYLVVd0o6Ci5WLS9bEOiUAFhHQBTA7o7xoQVpDG7kIJ8S5ewvgvlJnNDj0.EmCPT5VdUBqDweWH9 Ecczn2l949Hswuk9neOFn5EN4ersK47HWEhdcB4ECBzhjTpmRyiPaZlZ.LIjfPpAzQ1.As1bIl_I G2RbEo7OxMJ8O_RNb0qn4ZFWKMRBOtLYkYkVCfhABuxrXPw8xzXxAykhMwaCx6E5Elva_fRnvLj_ Cf8NyRPoWFMUcHtd8E9SzSHMFHwkQUS59zOHD.Bw4xghHB6fmn5H3DCXtWIj7vldNzZyjbXnP2MX 4.paaKPRu72FO4IMdlEvbkrYL9tdcfanWOm1LXP9PV5.rfbbTDdON7WIBc26UChbKxjYFiWDgnnv pEAq1EOJu4UdyWvj8hqUvW8Bw2edV6BsHcZABg2pmNGNmEZgm24De.uWWOPfk.pjOCwPgwJbQ9RT J9w6k5JxJ563_kpSJyhAOX1UKvqxGnoZ1feCNdd3Szaav5hikqMl4tXwU5oGYMCp8tFAo2q26Bq4 u1hrpPTgh7cPr3Gevzwo9KtuN.pRicXa6YsBdENodM2vp4Yk695lssXEU63xgi6mjB5Izmd6zRxb MZTAAzyPR1AOF98eUj7B3fSX7bbxJjWXEO6qPZ8h_nkmDCG02W4hiny4qG7wCBQdAPqukvdncEnD _Ktrz6uEKjmEW0rdRfgCQrjyZzstzPTQXyheXyN615r.5pJrs1f3zigE8es78qSrX05Y- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 Feb 2019 20:33:47 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID faac3d4b65fba3935193366089efa6a3; Wed, 13 Feb 2019 20:23:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Questions with a powerpc64/powerpc context: relaxed use of smp_cpus in umtx_busy vs. relaxed updates to smp_cpus in machine dependent code? Message-Id: <096EABF3-1876-4E0C-9C16-ECF5C068B189@yahoo.com> Date: Wed, 13 Feb 2019 12:23:38 -0800 To: FreeBSD PowerPC ML , freebsd-hackers Hackers X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: AC0D073011 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; URIBL_BLOCKED(0.00)[dsl-only.net.multi.uribl.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.64.137.98.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.45)[ip: (-8.45), ipnet: 98.137.64.0/21(0.72), asn: 36647(0.57), country: US(-0.07)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 20:33:58 -0000 Why I ask the questions below (after providing context): There are boot issues on old multi-processor PowerMac G5s that frequently hang up during cpu_mp_unleash --but not always. /usr/src/sys/kern/kern_umtx.c has the following code (note the smp_cpus use in the machine-independent code): static inline void umtxq_busy(struct umtx_key *key) { struct umtxq_chain *uc; =20 uc =3D umtxq_getchain(key); mtx_assert(&uc->uc_lock, MA_OWNED); if (uc->uc_busy) { #ifdef SMP if (smp_cpus > 1) { int count =3D BUSY_SPINS; if (count > 0) { umtxq_unlock(key); while (uc->uc_busy && --count > 0) cpu_spinwait(); umtxq_lock(key); } } #endif while (uc->uc_busy) { uc->uc_waiters++; msleep(uc, &uc->uc_lock, 0, "umtxqb", 0); uc->uc_waiters--; } } uc->uc_busy =3D 1; } The use of smp_cpus here on powerpc would be what is called a std::memory_order_relaxed load in c++ terms. smp_cpus does change during the machine dependent-code cpu_mp_unleash in /usr/src/sys/powerpc/powerpc/mp_machdep.c : static void cpu_mp_unleash(void *dummy) { . . . smp_cpus =3D 0; . . . STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) { . . . if (pc->pc_awake) { if (bootverbose) printf("Adding CPU %d, hwref=3D%jx, = awake=3D%x\n", pc->pc_cpuid, = (uintmax_t)pc->pc_hwref, pc->pc_awake); smp_cpus++; } else . . .=20 } which are relaxed stores. [This dos not appear to be a std::memory_order_consume like context (no dependency ordered before usage).] /usr/src/sys/kern/subr_smp.c does initialize smp_cpus to 1 in its definition. (But it temporarily reverts to zero in the above code.) So far I've not managed to track down examples of specific code (in an objdump of the kernel, say) that matches up using some form(s) of the following to control access order in the various places umtxq_busy is used: lwsync (acquire/release/AcqRel fence or store-release [with load-acquire = code as well]) or: sync (a.k.a. hwsync and sync 0) (sequentially consistent = fence/store/load) Note: smp_cpus is not even volatile so, potentially, for a time a = register could be all that holds the sequence of smp_cpus values before memory is updated later. Nor have I yet found the earliest use of the umtxq_busy code. If it is late enough after cpu_mp_unleash, that might implicitly provide = something that is not a local code structure. Can anyone point me to example(s) of what controls umtxq_busy = necessarily accessing the intended smp_cpus value? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Wed Feb 13 21:45:24 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91BD914D8FC2; Wed, 13 Feb 2019 21:45:24 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB47775DB4; Wed, 13 Feb 2019 21:45:23 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from disco.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id D886C56468; Wed, 13 Feb 2019 15:45:21 -0600 (CST) Subject: Re: Questions with a powerpc64/powerpc context: relaxed use of smp_cpus in umtx_busy vs. relaxed updates to smp_cpus in machine dependent code? To: Mark Millard , FreeBSD PowerPC ML , freebsd-hackers Hackers References: <096EABF3-1876-4E0C-9C16-ECF5C068B189@yahoo.com> From: Eric van Gyzen Message-ID: <4b60c6a0-76d5-813c-11c0-9983ba45f7a5@vangyzen.net> Date: Wed, 13 Feb 2019 15:45:18 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <096EABF3-1876-4E0C-9C16-ECF5C068B189@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: AB47775DB4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of eric@vangyzen.net designates 2607:fc50:1000:7400:216:3eff:fe72:314f as permitted sender) smtp.mailfrom=eric@vangyzen.net X-Spamd-Result: default: False [-5.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[vangyzen.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[hotblack.vangyzen.net]; NEURAL_HAM_SHORT(-0.89)[-0.895,0]; IP_SCORE(-3.19)[ip: (-7.89), ipnet: 2607:fc50:1000::/36(-4.10), asn: 36236(-3.90), country: US(-0.07)]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:fc50:1000::/36, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 21:45:24 -0000 On 2/13/19 2:23 PM, Mark Millard via freebsd-hackers wrote: > Why I ask the questions below (after providing context): > There are boot issues on old multi-processor PowerMac G5s that > frequently hang up during cpu_mp_unleash --but not always. > > > /usr/src/sys/kern/kern_umtx.c has the following code > (note the smp_cpus use in the machine-independent code): > > > static inline void > umtxq_busy(struct umtx_key *key) > { > struct umtxq_chain *uc; > > uc = umtxq_getchain(key); > mtx_assert(&uc->uc_lock, MA_OWNED); > if (uc->uc_busy) { > #ifdef SMP > if (smp_cpus > 1) { > int count = BUSY_SPINS; > if (count > 0) { > umtxq_unlock(key); > while (uc->uc_busy && --count > 0) > cpu_spinwait(); > umtxq_lock(key); > } > } > #endif > while (uc->uc_busy) { > uc->uc_waiters++; > msleep(uc, &uc->uc_lock, 0, "umtxqb", 0); > uc->uc_waiters--; > } > } > uc->uc_busy = 1; > } > > The use of smp_cpus here on powerpc would be what is called > a std::memory_order_relaxed load in c++ terms. smp_cpus > does change during the machine dependent-code cpu_mp_unleash > in /usr/src/sys/powerpc/powerpc/mp_machdep.c : > > static void > cpu_mp_unleash(void *dummy) > { > . . . > smp_cpus = 0; > . . . > STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) { > . . . > if (pc->pc_awake) { > if (bootverbose) > printf("Adding CPU %d, hwref=%jx, awake=%x\n", > pc->pc_cpuid, (uintmax_t)pc->pc_hwref, > pc->pc_awake); > smp_cpus++; > } else > . . . > } > > which are relaxed stores. > > [This dos not appear to be a std::memory_order_consume like > context (no dependency ordered before usage).] > > /usr/src/sys/kern/subr_smp.c does initialize smp_cpus to 1 > in its definition. (But it temporarily reverts to zero in > the above code.) > > So far I've not managed to track down examples of specific > code (in an objdump of the kernel, say) that matches up > using some form(s) of the following to control access > order in the various places umtxq_busy is used: > > lwsync (acquire/release/AcqRel fence or store-release [with load-acquire code as well]) > or: > sync (a.k.a. hwsync and sync 0) (sequentially consistent fence/store/load) > > Note: smp_cpus is not even volatile so, potentially, for a time a register > could be all that holds the sequence of smp_cpus values before memory is > updated later. > > Nor have I yet found the earliest use of the umtxq_busy code. If it is > late enough after cpu_mp_unleash, that might implicitly provide something > that is not a local code structure. > > Can anyone point me to example(s) of what controls umtxq_busy necessarily > accessing the intended smp_cpus value? umtxq_busy() is only called by userland synchronization primitives, such as mutexes, condition variables, and semaphores. Assuming cpu_mp_unleash() is called before userland is started, umtxq_busy() should see the correct value of smp_cpus. However, even if umtxq_busy() sees a value of 0 or 1 when the correct value would be greater than 1, I don't see how this could cause a problem, since it would take the safer approach of sleeping instead of spinning. Best of luck, Eric From owner-freebsd-hackers@freebsd.org Thu Feb 14 14:32:06 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C80314D5FD8 for ; Thu, 14 Feb 2019 14:32:06 +0000 (UTC) (envelope-from iam@sdf.org) Received: from mx.sdf.org (ol.sdf.org [205.166.94.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95DD97341F for ; Thu, 14 Feb 2019 14:32:05 +0000 (UTC) (envelope-from iam@sdf.org) Received: from sdf.org (IDENT:iam@sdf.lonestar.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id x1EEVqun017051 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO) for ; Thu, 14 Feb 2019 14:31:53 GMT Received: (from iam@localhost) by sdf.org (8.15.2/8.12.8/Submit) id x1EEVqmV017421 for freebsd-hackers@freebsd.org; Thu, 14 Feb 2019 14:31:52 GMT Date: Thu, 14 Feb 2019 14:31:52 GMT From: iam@sdf.org Message-Id: <201902141431.x1EEVqmV017421@sdf.org> To: freebsd-hackers@freebsd.org Subject: linker loader magic unavailable! X-Rspamd-Queue-Id: 95DD97341F X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-0.60 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.55)[-0.553,0]; URIBL_BLOCKED(0.00)[lethargy.org.multi.uribl.com]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.84)[-0.841,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[sdf.org]; NEURAL_SPAM_SHORT(0.12)[0.119,0]; MX_GOOD(-0.01)[cached: mx.sdf.org]; FROM_NO_DN(0.00)[]; SUBJECT_ENDS_EXCLAIM(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.21)[ip: (-0.89), ipnet: 205.166.94.0/24(-0.44), asn: 14361(0.33), country: US(-0.07)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 14:32:06 -0000 is the kind of linker loader magic described at; https://lethargy.org/~jesus/writes/sunw_cap-arcana/ unavailable under freebsd? if still unavailable, what would it take to get something like that under freebsd too? From owner-freebsd-hackers@freebsd.org Thu Feb 14 14:49:30 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E37F14D6C02 for ; Thu, 14 Feb 2019 14:49:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 D2A8A746E5 for ; Thu, 14 Feb 2019 14:49:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x1EEnMJ8057846 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 16:49:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x1EEnMJ8057846 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x1EEnLem057845; Thu, 14 Feb 2019 16:49:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Feb 2019 16:49:21 +0200 From: Konstantin Belousov To: iam@sdf.org Cc: freebsd-hackers@freebsd.org Subject: Re: linker loader magic unavailable! Message-ID: <20190214144921.GI24863@kib.kiev.ua> References: <201902141431.x1EEVqmV017421@sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201902141431.x1EEVqmV017421@sdf.org> User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 14:49:30 -0000 On Thu, Feb 14, 2019 at 02:31:52PM +0000, iam@sdf.org wrote: > is the kind of linker loader magic described at; > https://lethargy.org/~jesus/writes/sunw_cap-arcana/ > unavailable under freebsd? > if still unavailable, what would it take to get > something like that under freebsd too? Something like that is provided by ifuncs. You would need to search in Google, look into the gcc documentation and some bits of our implementation to see how to use them. From owner-freebsd-hackers@freebsd.org Thu Feb 14 18:25:35 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A17414DCFA1 for ; Thu, 14 Feb 2019 18:25:35 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 57961857F1 for ; Thu, 14 Feb 2019 18:25:33 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 440lF61DqHzL2D for ; Thu, 14 Feb 2019 19:25:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1550168726; x=1552760727; bh=NhB o5eBAjnjGFNbXh1rVq32Bh9cGL0lNw8jU1ChPHNs=; b=HWfPAnR4lYT0Pa2YPcp i2cAB7++iXeDUzeFGwxhAoJOUtxQtvBmB2dqqH6lSc/S4vROHk9LyqcuGkZg/rAQ 5tOte3XTKfLJ3TWpaurBlLM+qtiz9hz2RXNfeow/8vYM6utTpoV29s5lhmZzRFc2 RPKe0jFftC6bGmOeOA+eZwNQ= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id JFcEJAJYE0Wb for ; Thu, 14 Feb 2019 19:25:26 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 440lF24tLNzL2B for ; Thu, 14 Feb 2019 19:25:26 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 440lF22RYVzky for ; Thu, 14 Feb 2019 19:25:26 +0100 (CET) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by webmail.ijs.si with HTTP (HTTP/2.0 POST); Thu, 14 Feb 2019 19:25:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 14 Feb 2019 19:25:26 +0100 From: Mark Martinec To: freebsd-hackers@freebsd.org Subject: Re: nosh init system Organization: Jozef Stefan Institute In-Reply-To: <9c435d7d-500e-12e9-9819-7ae68515e144@gmail.com> References: <9c435d7d-500e-12e9-9819-7ae68515e144@gmail.com> Message-ID: <5a39f013e4ebd7a902fac6b1d1f40bc6@ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.3.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:25:35 -0000 For a perspective: worth listening to a recent talk by a FreeBSD developer on a Linux conference: Benno Rice: The Tragedy of systemd linux.conf.au 2019 — Christchurch, New Zealand, published on Jan 24, 2019 https://youtu.be/o_AIw9bGogo Mark From owner-freebsd-hackers@freebsd.org Fri Feb 15 16:59:50 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7B1B14E0F8E for ; Fri, 15 Feb 2019 16:59:49 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (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 1BEE472007 for ; Fri, 15 Feb 2019 16:59:49 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 566A3289F0 for ; Fri, 15 Feb 2019 17:50:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAqd5MJKsJL8 for ; Fri, 15 Feb 2019 17:50:57 +0100 (CET) Subject: Fwd: Point-to-point using GRE over IPv6 -> not possible with a single /128 address on the server? DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1550249457; bh=HiLc5W2wSQXAmBVqFBDUkSRF83i2K9hbQt7jUeJp7R0=; h=Subject:References:To:Reply-To:From:Date:In-Reply-To; b=XWmimheCLh7OgKGIiHuhIwOQwz3T5ByeI8agvyn+1tphIl8fGS5BjafJ1o5nm8g+6 SbRYI2hlSy1hiwIBnJMU/Djt1+n2AAu0vcoiWKoPAppBiichYsLTe0YECxEjwNDHDi vpdVzXdj0dvggz6+e9q4BhqvAOJ4R/TKEYQMGN6XR2Mo6i1/KRYHjEKeECBbu4eiMz fM+NtRPrT8pDJwEkqMjrw64i8q6WuphjfZtEs4e25SNhSLBKAfmYkzblNTI7ZvQpcH lFjuDxCMWNsYkEncsmqHrQ+VIwzZLxE1uOwm7LgGxt0IEKIY52GwAAG8U8nQRYWnPO tSjxNDKZUJGTw== References: <95d8e3ea-af36-4d14-f280-908f92a96515@disroot.org> To: freebsd-hackers@freebsd.org Reply-To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org From: "Peter G." X-Forwarded-Message-Id: <95d8e3ea-af36-4d14-f280-908f92a96515@disroot.org> Message-ID: <10c08655-bfa5-3ed9-3688-3f78028cb033@disroot.org> Date: Fri, 15 Feb 2019 17:50:47 +0100 Mime-Version: 1.0 In-Reply-To: <95d8e3ea-af36-4d14-f280-908f92a96515@disroot.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1BEE472007 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=disroot.org header.s=mail header.b=XWmimheC; dmarc=pass (policy=none) header.from=disroot.org; spf=pass (mx1.freebsd.org: domain of freebsd@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=freebsd@disroot.org X-Spamd-Result: default: False [2.14 / 15.00]; HAS_REPLYTO(0.00)[freebsd-hackers@freebsd.org]; R_SPF_ALLOW(-0.20)[+a]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[disroot.org:+]; DMARC_POLICY_ALLOW(-0.50)[disroot.org,none]; MX_GOOD(-0.01)[cached: disroot.org]; NEURAL_HAM_SHORT(-0.86)[-0.860,0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50673, ipnet:178.21.23.0/24, country:NL]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; REPLYTO_EQ_TO_ADDR(5.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[disroot.org:s=mail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.49)[asn: 50673(-2.47), country: NL(0.02)]; RCVD_IN_DNSWL_NONE(0.00)[139.23.21.178.list.dnswl.org : 127.0.10.0]; GREYLIST(0.00)[pass,body] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 16:59:50 -0000 Hi, I've got issues establishing a point-to-point ipv6-over-ipv6 GRE link. IPv4 which works as expected: this end: 10.0.1.10 other end: 10.0.2.10 GW: 10.0.1.1 iface: em0 >ifconfig gre4 create >ifconfig gre4 inet 10.0.1.10 10.0.2.10 netmask 0xffffffff tunnel 10.0.1.10 10.0.2.10 tunnelfib 2 >route add -host 10.0.1.1 -iface em0 -fib 2 >route add -host 10.0.2.10 10.0.1.1 -fib 2 Works. The tunnel is marked with FIB 2, and a point-to-point is established. Can be used with IPSEC in transport or whatever. Now, IPv6 is problematic. The server has allocated a single IPv6 address with prefixlen 112. This could be the source of the issue. Private addresses replicate the setup. this end: fc01:e::100/112 other end fc02:e::200 GW: fc01:e::1 >ifconfig em0 #em0: # inet6 fc01:e::100 prefixlen 112 This works. Default GW is at fc01:e::1. Now the GRE tunnel >ifconfig gre6 create >ifconfig gre6 inet6 fc01:e::100 fc:02:e::200 tunnelfib 6 #ifconfig: ioctl (SIOCAIFADDR): File exists Why is this not possible? Isn't the logic behind it the same as with IPv4? If not, why not? Does this mean it is not possible to have a point-to-point using IPv6 on a machine with only a single /128 address? Found this as reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208173 but what he did was on a much broader range. Many thanks! Peter