From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 08 08:36:06 2022 Received: (at 59866) by debbugs.gnu.org; 8 Dec 2022 13:36:06 +0000 Received: from localhost ([127.0.0.1]:56811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3H4I-00033K-7p for submit@debbugs.gnu.org; Thu, 08 Dec 2022 08:36:06 -0500 Received: from mail-ej1-f66.google.com ([209.85.218.66]:40764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3H4G-00032r-32; Thu, 08 Dec 2022 08:36:04 -0500 Received: by mail-ej1-f66.google.com with SMTP id b2so3910445eja.7; Thu, 08 Dec 2022 05:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=NLSGOOf2eRBAwiYW6X8+LYnqDTQCwpP7U+hL/+ZUHVQ=; b=nigV6vxdvqjvSTOBVGJyMbgXrlmDMcah6CMYU/lv5MW5wZT+kBSuknsHSss1CdDjUY 6wRpQtaQI5omo1xhgw+PKP1ob4YB4ZTGDInr8WeZSdG3Sii2Ah5VpzXwFCMkwmAmf1eN wRpFNNDLkR2jJ88h6EDYxYEM4wF3ouMvrVW70uZcAEsVdtfkgGLA3jnb3BLuNy8ATVWr tdamTH7ktq2IB1x82EsiLpWkEFerMn+tz0d1Vlsnz5aYHp7d35h+xI2AH5radpNkbYYi B3OlfNb4nhb9OhgbTSKFi+W4ssNJuCh1TqfOjI9l5CUUDffwiE4PrpQJMoism9pG/wG9 mHug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=NLSGOOf2eRBAwiYW6X8+LYnqDTQCwpP7U+hL/+ZUHVQ=; b=eWuofNeZrctnoL2UbNalrbcOaQ3WKlwJwIY8Ne6bh32NymI6g0h2Hd6jnLoJsChZIh eLOPCADI+aggBnVFyzP/so3Mx8JStyqkKK8cs0t4fvQVxiap+DIAc+czT3ai3iHNgiTE irUqN7KS3tCCJm4XZ6+Jkru2rRI//qeEMa8xGR4UxDq0rjPCcDaNWyxukO35wPtKZT27 KDlSAB8QeJ59NAFPBUnh7SELHFRKCN2/86DrRyXEAVCazAIphJylpfCYGUy/i2tHvBFP XH5bGpnTIjU2mKRKc3REXK8cFZ2e0TL+lwaJOhdJqV35VqFeGtg8wcjx68UrsUsgD0bs Sqag== X-Gm-Message-State: ANoB5pkQ2329GieiWpoRajUiVj0L2JUQEqOBszVd7KluM5r9VrzGSebw 8xwox0JAldLPqifJnBjHrZI= X-Google-Smtp-Source: AA0mqf5Ln50FtyONi6KSjrGOB+MJbHvtPfzUlpfihVKWxpPlvU/LquS4omNId7i5rnq+03w5Lt3aQQ== X-Received: by 2002:aa7:cd02:0:b0:46c:9536:8598 with SMTP id b2-20020aa7cd02000000b0046c95368598mr15835083edw.123.1670506557965; Thu, 08 Dec 2022 05:35:57 -0800 (PST) Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id i26-20020aa7dd1a000000b0045c47b2a800sm3358568edv.67.2022.12.08.05.35.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 05:35:57 -0800 (PST) Message-ID: Subject: Re: [PATCH 0/2] services: mpd: Refactor MPD service From: Liliana Marie Prikler To: mirai , 59866@debbugs.gnu.org Date: Thu, 08 Dec 2022 14:35:55 +0100 In-Reply-To: <71f31a0d-cc58-a0e6-4aa4-b5c46513c835@makinata.eu> References: <6e66967984d1bc22d8abf5dd4b07c1a20b4b06ee.camel@gmail.com> <71f31a0d-cc58-a0e6-4aa4-b5c46513c835@makinata.eu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 59866 Cc: 54986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Am Donnerstag, dem 08.12.2022 um 13:11 +0000 schrieb mirai: > On 2022-12-07 18:27, Liliana Marie Prikler wrote: > > Note that there is [1], which attempts to make it so that shepherd > > endpoints can be specified in lieu of MPD endpoints.=C2=A0 You don't > > need to implement this logic =E2=80=93 you are free to do so if you wan= t to > > =E2=80=93 but could you make it so that there is an explicit endpoint > > abstraction that would allow for extension later on? > >=20 > > Cheers > >=20 > > [1] https://issues.guix.gnu.org/54986 >=20 > Hi, >=20 > After reading issue #54986, regarding mpd escaping shepherd > management, my guess is that there could be two issues at play here: >=20 > * mpd.conf was serialized with pid_file [1]. The safest is > to actually not serialize any unused directives and let MPD decide > based on what's actually present. pid_file should only be set if > MPD is to be launched as a "daemon process". [2] >=20 > * But the service definition for MPD is launched with '--no-daemon' > option as seen in [3], which could be triggering a bug in MPD. It's > probably worth testing the combinations of having pid_file set and > invoking --no-daemon. Nice catch, but completely unrelated to the issue. In neither case do we ever spawn MPD as a regular daemon, yet only in the systemd case does shepherd have a problem with it. That statement was concerning shepherd's (mis)management of sockets, not MPD. > > but could you make it so that there is an explicit endpoint > > abstraction that would allow for extension later on? >=20 > If I'm understanding correctly what [1] is about, I think this can be > implemented through the 'extend' interface. See how certbot adds a > nginx-server-configuration to a nginx-service-type through the > 'extend' interface. For MPD, this would amount to appending the > 'adresses' field with "adequately formatted" values. This doesn't work for #54986, which makes it so that in-file addresses are ignored in favour of handing over the sockets directly through shepherd. Looking at [4], it appears the meaning of "port" is closer to that of a default port, as addresses can have ports in them. But I would still prefer addresses to be "endpoints", which if they happen to be a list of strings are taken as MPD addresses and if they happen to be shepherd endpoints are passed on to the shepherd service. WDYT? [4] https://mpd.readthedocs.io/en/stable/user.html#client-connections