From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WERPCtzG+16cLQAA0tVLHw (envelope-from ) for ; Tue, 30 Jun 2020 23:12:28 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id QM4nBtzG+16sDAAA1q6Kng (envelope-from ) for ; Tue, 30 Jun 2020 23:12:28 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6050F9404D9 for ; Tue, 30 Jun 2020 23:12:27 +0000 (UTC) Received: from localhost ([::1]:47402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jqPQO-0001Zn-Ug for larch@yhetil.org; Tue, 30 Jun 2020 19:12:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jqPQC-0001ZO-Lw for help-guix@gnu.org; Tue, 30 Jun 2020 19:12:12 -0400 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:36345) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jqPQA-000279-D9; Tue, 30 Jun 2020 19:12:12 -0400 Received: by mail-ed1-x52d.google.com with SMTP id dg28so17858494edb.3; Tue, 30 Jun 2020 16:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LY3GRx6BfoLPdABbTBF5oFVceqlQMLIay/aMacaPhz4=; b=UlSpzajE/IzIwd78rtfagOUN6QYFvAXI4oqVOuqMk7frGLPofsRdsOdjdtXrjpamMV rnAKoan9NUyYxZ0qhN7riso/0WuchCHT3QkrXPdcZBYWtDeQ7hDFesIeoHdywUW5GIJO 7PFZqKCPrlvxU63ShZtrXcvhUKaLvH4Os2RUoLPJE7KmHILqyzxTGI3KLLctZMbtpFCs g/hiOhDW/ABSS+GGcYo2sfYrQNKkYIknP1SM6B3KZhwtfcKIVzsec4BpYL0x0xjYN9TN qxg3joRgRz5LHQaFOWXIjeYdHecX0e/2y2LecOosJG0hhjjed1sXwl2s73QZLYoEw+0e LKVQ== 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=LY3GRx6BfoLPdABbTBF5oFVceqlQMLIay/aMacaPhz4=; b=XWoQ07k3x6qLrKYNABUDycAz/4nQDJ2/vtII/4+ukOkl0iSK4c1jLbJc5kgLmZqvre L5WHnxpXBAs8GT37XDkAve3xlZolRRLvw+hIsVsNhtA/YOjGSOB+F2DwvAB2ZomePcUp wnSri5F24dg2BErumDefv/DLlE4Wnt5qq6eEgSyI+XTHadDSC4y6Ea8+xq7Ezs6irhJ3 5lwk9pdJVEy+rLl/KbyLmaiqIWVDPSFN1eF3m7iwWVhhWBNRGZ3dl1O0ozacfYTvZbcI njUJS7kt4jdX+RHfsw6dnDipFatkvpXMWtw42mTOJZvGVsfv0bz++CNyvNEdpThTvDHH C+/g== X-Gm-Message-State: AOAM530XyCbnyzwuPXpjags2l3CuvPECG629fQpchsIBS7ej/F8lJsP4 XAfo+VafVIPs8TMJtzqL8nh262Nry96DC1SKoyEaXsap X-Google-Smtp-Source: ABdhPJzotOzUaH5BYuFuZNoifuuR5inpAoJu71p/Omh8lw6iT3zHcKjWUzFmv5oFuF4X2BQLYQJ81iMJUg1J4WnbISM= X-Received: by 2002:a50:d785:: with SMTP id w5mr25026537edi.212.1593558727038; Tue, 30 Jun 2020 16:12:07 -0700 (PDT) MIME-Version: 1.0 References: <87k0zx8n89.fsf@gnu.org> In-Reply-To: <87k0zx8n89.fsf@gnu.org> From: conjaroy Date: Tue, 30 Jun 2020 19:11:31 -0400 Message-ID: Subject: Re: Dependencies between service extensions To: Marius Bakke Received-SPF: pass client-ip=2a00:1450:4864:20::52d; envelope-from=conjaroy@gmail.com; helo=mail-ed1-x52d.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix@gnu.org Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (body hash did not verify) header.d=gmail.com header.s=20161025 header.b=UlSpzajE; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: B9zA6t/4rdcv Hello Marius, Thanks a lot for your reply - I agree that the concept of a meta-service to factor out common startup tasks seems logical. Based on your example, it sounds like you're suggesting that if I have a service that extends both activation-service-type and shepherd-root-service-type, and if the Shepherd extension service defines its own service dependencies (via shepherd-service-requirement), then the activation-service-type extension script will run in a context where those required services are active? I've spent a few days investigating how the service graph works and here's what I think is happening: - Individually, activation-service-type and shepherd-root-service-type concatenate their respective service extension scripts into a single script. - These two service types in turn extend boot-service-type, so when extensions of boot-service-type are processed, the combined activation-service-type boot script is concatenated with the combined shepherd-root-service-type boot script (in that order, apparently). - Therefore, at startup, Guix executes scripts for all activation-service-type extensions before starting any Shepherd services. So while the idea of performing initialization as a separate service still makes sense, I believe that any logic depending on other Shepherd services needs to run as a shepherd-root-service-type extension instead of an activation-service-type extension. If any of the above is incorrect, I'd love to hear more! Cheers, Jason On Tue, Jun 23, 2020 at 5:51 PM Marius Bakke wrote: > conjaroy writes: > > > Greetings help-guix, > > > > I've been a casual user of Nix for a couple of years and have decided to > > test the waters with Guix. While I'm looking forward to spending time > with > > Lisp after many years away, my biggest impression is that Guix seems to > > have well-documented interfaces in cases where Nix relies more on loose > > conventions. > > > > After reviewing the manual and some of the service definitions, I'd like > a > > better understanding of how to implement a common pattern. Let's say > that I > > have some application Foo that uses an external system for persistence, > > like a SQL database. Before starting up service Foo I need to ensure both > > that the database service is running and that the database instance for > Foo > > has been initialized, because Foo doesn't know how to initialize the > > database on its own. > > > > The first issue (how to ensure that the database service is up) seems to > be > > solved by adding a shepherd-root-service-type service extension that > > declares a set of "requirements". And the second issue (performing > > pre-startup initialization) seems to be handled by the > > activation-service-type extension. So far so good. > > > > But I couldn't find documentation on whether service activation scripts > can > > safely rely on other services that happen to be declared as requirements > in > > the shepherd-root-service-type extension. And while I found many > activation > > scripts that do simple things like modifying the filesystem, I couldn't > see > > any that interact directly with other services. However, I did see some > > evidence of service extensions relying on the side effects of other > service > > extensions: a number of activation scripts call "getpwnam" for info on > > system accounts that could exist only if the corresponding > > account-service-type extension has already been executed. > > > > So my questions are: could someone clarify best practices for > initializing > > state in Service A before Service B starts up? And is there anything > about > > the ordering/dependencies of a service's extensions that could be better > > documented in the manual? > > To encode requirements for an activation script, I think you need to > declare a service type for it with appropriate requirements, and make > the start and stop actions "noop". Then you can have other services > depend on the "activation service". > > I did something similar in a service I'm working on that consists of > many different daemons. To avoid having to run essentially the same > activation script on each, I created a "common" service that all daemons > depend upon. It's fairly verbose (you don't need a record type), but > looks like this: > > --8<---------------cut here---------------start------------->8--- > ;; This is a dummy service that all Ganeti daemons depend upon, mainly to > ;; avoid having the same activation snippet on each. > (define-record-type* > ganeti-common-configuration make-ganeti-common-configuration > ganeti-common-configuration? > (ganeti ganeti-common-configuration-ganeti ; > (default ganeti)) > (directories ganeti-common-configuration-directories ;list of strings > (default '("/var/log/ganeti" > "/var/log/ganeti/kvm" > "/var/log/ganeti/os" > "/var/lib/ganeti/rapi" > "/var/lib/ganeti/queue" > "/var/run/ganeti/bdev-cache" > "/var/run/ganeti/socket" > "/var/run/ganeti/instance-disks" > "/var/run/ganeti/instance-reason" > "/var/run/ganeti/livelocks")))) > > (define (ganeti-common-activation config) > (let ((directories (ganeti-common-configuration-directories config))) > #~(begin > (use-modules (guix build utils)) > (for-each mkdir-p '#$directories)))) > > (define ganeti-common-service > (lambda _ > (list (shepherd-service > (documentation "Create the directories required by Ganeti.") > (provision '(ganeti-common)) > (requirement '(file-systems)) > ;; Do nothing but the activation snippet, at least for now. > (start #~(const #t)))))) > > (define ganeti-common-service-type > (service-type (name 'ganeti-common) > (extensions > (list (service-extension activation-service-type > ganeti-common-activation) > ;; This service also installs Ganeti to the profile > ;; to make gnt-cluster, etc readily available. > (service-extension profile-service-type > (compose list > > ganeti-common-configuration-ganeti)) > (service-extension shepherd-root-service-type > ganeti-common-service))) > (default-value (ganeti-common-configuration)) > (description > "This service creates directories used by other Ganeti > daemons."))) > --8<---------------cut here---------------end--------------->8--- >