From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2250 Path: news.gmane.org!.POSTED!not-for-mail From: Adrian Chadd Newsgroups: gmane.os.freebsd.devel.hackers,gmane.comp.sysutils.supervision.general Subject: Re: Linuxisms in s6 Date: Sat, 27 Aug 2016 18:58:05 -0700 Message-ID: References: <37d5159b-4957-42f8-2252-fa53d7446bb6@NTLWorld.com> <20160825194820.GI92256@e-new.0x20.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1472349501 29507 195.159.176.226 (28 Aug 2016 01:58:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 01:58:21 +0000 (UTC) Cc: Supervision , FreeBSD Hackers To: Jonathan de Boyne Pollard Original-X-From: owner-freebsd-hackers@freebsd.org Sun Aug 28 03:58:16 2016 Return-path: Envelope-to: freebsd-hackers@m.gmane.org Original-Received: from mx2.freebsd.org ([8.8.178.116]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bdpMT-00070b-LU for freebsd-hackers@m.gmane.org; Sun, 28 Aug 2016 03:58:13 +0200 Original-Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.freebsd.org (Postfix) with ESMTPS id 64A5272CC9; Sun, 28 Aug 2016 01:58:12 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Original-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 293DCBCB; Sun, 28 Aug 2016 01:58:12 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Original-Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4108CB773CE for ; Sun, 28 Aug 2016 01:58:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Original-Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08AE1B95 for ; Sun, 28 Aug 2016 01:58:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Original-Received: by mail-it0-x235.google.com with SMTP id e63so53596351ith.1 for ; Sat, 27 Aug 2016 18:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vhKtcDWl1edwUttyE/BGHn12i1UrRelzXqovS/R6FPE=; b=FA4Xqnt5JRnRRnIWcgibiekkZSeJqRXqt5s+5MuacPq+EtGntVFAh1b/7+iQV/TvLV 3CWvCicn8PJDCfUqmmHsRhrSZMQXPsPRj7J/LykhecjXHF9hT1npQpFxLSZKUBPjMebo DsAWjQmg9uFkMpqIiN9CKHOW4JueXuo80zsCGE9DWSmfPXc7ER4RNdqiaBXlpPHtmWCn OpuuuEmpmfSPhhjMbjrzXOtCFcZyxFz1Tj8icUawlQGdMUVnSZYDDyBSNp2fYnjS9fxo QhXoT3yCBRIUpevx1FS7ljQy3gO3xeY6ikbuSjoggLYoLPjUuQmFOSADqJHzCayk9HUA Ompw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vhKtcDWl1edwUttyE/BGHn12i1UrRelzXqovS/R6FPE=; b=ZDFDxitFNsKnUz7Y9j+HsruxzHQUWWSHuFuN/eri7OMZH1limQrdqr42a+RVmmZOd5 j9iRfyiDwdQFW+2CazcgXuhYCitE0HJ8mYfamkWeNCSNcrZ43oRttHdLGAqk8Pq2SmC+ YUmK2/tK/RRx7mRvAPgZOI3KJkIKuOhi4VxmmE71yHILPkIPj2JHg23umoPLB4AFhilD 0Cq4jWotOq6C/uUhe4+rVd3FWY0ZO0iMNwlWY4YVwhDFM8ktMHFxk0yL5zTCqR39ieO3 DoVVKSS1f1sgv+pxbc989JhGYLiiIpX5okPsQqa5XCUZdkpU3pQ1ODQEFRmXPy8C+1Ew kOsQ== X-Gm-Message-State: AE9vXwMXiUIvKPq7atrR9pg5iaEOqVBPABMVQLcoS8gKaU6lsh72TXepbVWiUVcGrO6X+yTXQaehRut6Viwl5A== X-Received: by 10.36.73.195 with SMTP id e64mr6379068itd.80.1472349486247; Sat, 27 Aug 2016 18:58:06 -0700 (PDT) Original-Received: by 10.36.141.129 with HTTP; Sat, 27 Aug 2016 18:58:05 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: m-LQggtcAgOBbG-2f-dT-UoJ7v8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: owner-freebsd-hackers@freebsd.org Original-Sender: owner-freebsd-hackers@freebsd.org Xref: news.gmane.org gmane.os.freebsd.devel.hackers:57962 gmane.comp.sysutils.supervision.general:2250 Archived-At: On 27 August 2016 at 09:37, Jonathan de Boyne Pollard wrote: > Adrian Chadd: > >> Sure, but I'm looking for something more generic than just devd. Like, >> notifications about events like "default route is up" can be done by >> sniffing the rtsock, but notifications like "ntpdate has updated the date, >> we can now do crypto services" doesn't happen there right now. >> > You're reinventing upstart. The lesson of upstart is that whilst the > event-driven paradigm looks like the bright shiny future, once one gets down > to the details it is a lot harder than it at first appears. I strongly > recommended learning about upstart, and especially learning the problems > that people hit with it, to anyone going down the same route. The Debian > systemd Hoo-Hah had some lengthy discussion of upstart. Oh yeah, I'm aware of the differences between systemd and upstart. > (I regret not having bookmarked the discussion that I once came across, > where someone opined that xe preferred systemd to upstart because at a Linux > conference the systemd presentation had been exciting and had been put > forward as the wave of the future, where upstart had been presented as > old-school, traditional, and boring. Ironically, this person wasn't aware > that the designs are exactly the opposite of that. upstart has the novel > event-driven design where the system is configured with the information that > event A triggers programs P, Q, and R, and the system starts by raising a > "first event", that runs programs, that raise further events, that run > further programs. Whereas it is systemd that has the conventional design, > shared by Mewburn rc and others, of starting from a goal, working through a > dependency tree, and doing topological sorts.) For some environments (servers, desktop environments, etc) where most of the dynamicness comes from "which user is logged in" and "maybe I don't have my network hardware plugged in until later", sure, I can see that the dependency tree model works great. Your aim is some grander set of checkpoints, like "What do I need to run basic network services", "What do i need up to run a desktop login environment", etc. But for things like "I'm a vpn server, and I need to speak to a vpn server to provide access to my vpn clients, oh and I have firewall rules that need applying based on which dynamic interfaces come/go" it still maps to an event driven mechanism. Sure you can map that event driven mechanism to a set of targets, but those targets may be per-interface. Like, when a vpn client interface comes up, I have a set of things that need to happen that depend upon which client. Same with wireless clients associating. I may hit some situations (eg above a certain threshold of associated clients) where I trigger events such as "clean up old clients", "look at migrating clients to other access points", etc. If I can do this with s6, then cool - please let me know how and I'll re-consider it. But regardless of that, I also do need some generalised dbus style mechanism so all the pieces of the system can talk to the other pieces of the system without having to .. well, wrap it all in 'service' style shell scripts and calling ifconfig wlanX list sta periodically from everywhere. > The Debian people chose to improve a non-event-driven architecture instead. > It's a lesson to be learned from SMF, in fact. One can have a lot more > additional abstract targets, such as "/milestone/name-services" and > "/milestone/system-clock", and dependencies to and from them. The world is > not 2 to 4 run levels plus "DAEMON", "NETWORKING", and "$local-fs". > > That said, something like this hypothetical "/milestone/system-clock" is a > milestone that would need to be reached *very* early on in the bootstrap > process. Fixing up the clock is something that both the nosh system manager > and systemd handle themselves directly, outwith of service management. More > on this in a moment. So, this is where it gets exciting in some of these appliances. Sometimes there's no 'date/time' RTC hardware. Sometimes, you have to present some UI to the user so they can enter a date/time, and some services need to run before that, but some services (notably ntpdate) won't work. So we can't, say, hold all network services back until we have valid date/time or a bunch of the UI infrastructure won't be there. I can't expect the whole system to stop waiting for a system-clock time to be valid. In fact, i ended up adding some stuff to our appliance images that store the current clock value in a file every 15 minutes - the rootfs is read-only, so i can't just boot up from /its/ concept of "last mounted", as that filesystem is not modifiable. Trouble is, that gets read from the system during boot, after FSes have been mounted, etc. It's all terrible. Thanks, -adrian _______________________________________________ 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"