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