From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2851 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Casper Ti. Vector" Newsgroups: gmane.comp.sysutils.supervision.general Subject: mdevd / udevd issues, and the issue of "reverse" dependencies Date: Tue, 11 Feb 2020 01:19:43 +0800 Message-ID: <20200210171943.tzjltctjry2iqysx@CasperVector> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="99361"; mail-complaints-to="usenet@ciao.gmane.io" To: supervision@list.skarnet.org Original-X-From: supervision-return-2440-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Mon Feb 10 18:19:55 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1j1Civ-000Pkh-II for gcsg-supervision@m.gmane-mx.org; Mon, 10 Feb 2020 18:19:53 +0100 Original-Received: (qmail 17520 invoked by uid 89); 10 Feb 2020 17:20:17 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 17513 invoked from network); 10 Feb 2020 17:20:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mail-followup-to:mime-version :content-disposition; bh=vKJwBQ5cSUj05g2Il6i0CJzk/+fxL7/nNNObgo2lBoU=; b=PKhygWfK5ES69DZWVz4BA7tqosK7dJ3ZlQh+pvrmerg0THhjkxEJX+BwWICGEmWb9A K7e7A5nQ4A5zh/FyL7Q6x9Y10GVhRcQPIyZGFyggvypiZzU2zpK3M62HGwRGitHr3Tk8 w3aglWoq77RH3rWv1DxsQDd1jJpe9gnUfKiEYdllGn/ifOfahYLA/jOFrKOjWa4vgXUn vgTF90buQsVwdzQUGReQ+1S/ewYU1tcbiDeU+FkHivfZuG88TRGL2mu0AByf6YwnCk1U OMdem/xs47Vn5MLKFag7wKv+XqghZOlfyLC2GxdLzzMT+qOIvUaLV5GIto6TeHJ9ElU2 1mIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mail-followup-to :mime-version:content-disposition; bh=vKJwBQ5cSUj05g2Il6i0CJzk/+fxL7/nNNObgo2lBoU=; b=Z6zd2+r2qWT8KRoz8FwBaq94B+n7ZnG8/FyJyaTwd9o5tXOUL4bd6VGYkunWRfBREt NZaU/4EAJMagCMMY/CDP3x90uAAAEezx6LLEJOp2AhrSjN/YyTkHR7da3nllnWZP+tBU c0ihbYFv2EKbrxdHrPrcmK+w3qUrg/D0DdTzRhDz4VGlb4EjktYItP6GpV2cmcF+jqir U2HU8VcqeBbd7iSZj3aGhJg0M4DwjaUkFTEiIIpK4jt8oNJC02RFwYl7B7LdcqkhHTD0 Gkxo9Q9EqnpwBFPnciUKgbTVneS0msrAMin/PjeBRHwuoBjhxCMsKiPvd5vEV//TkEGo d76g== X-Gm-Message-State: APjAAAUHQYgzZpxj8wD/asDQKsm78e1yHH5VKvnoKpWJfPzB8+3Vn6gP FbzblC1QLIK3o5XA8GqXxPZlVSd1 X-Google-Smtp-Source: APXvYqyiIpKMLlLWcDC5Z7edKPRVqSPuqQKn+tjnMIxFEx4tviOEm4O7LH7RNUYzkLpr0/i5fMe/+g== X-Received: by 2002:a7b:c932:: with SMTP id h18mr6267wml.171.1581355188491; Mon, 10 Feb 2020 09:19:48 -0800 (PST) X-Google-Original-From: "Casper Ti. Vector" Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2851 Archived-At: I recently added service definitions for mdevd into slew, during which I switched from a `devd' longrun (which has a dedicated logger, and so requires a R/W filesystem) that depends on a `devices' oneshot (starting a temporary devd process to coldplug basic devices) plus a `devd' longrun to a single `devd' longrun (which starts early, and just logs to the catch-all logger) followed by a `devices' oneshot (which just do the coldplug). This has obvious benefits, at least for now. udevd does not have a readiness notification mechanism (polling for the existence of /run/udev/control surely does not count), and s6's fd-based mechanism does not integrate well with the shell (at least I have not come up with a way that avoids the hassle of setting up a temporary fifo and dancing with foreground and "background" processes that play with the fifo). So the `devices' oneshot is destined to be complex if "up" is not to be identified with "ready". (Another issue, currently unsolved, is that mdevd does not have a "udevadm settle" equivalent, so that in theory we are not sure the basic devices are fully coldplugged when `mdevd-coldplug' exits.) In the above, you have seen that I switched from `devd' depending on `devices' to the converse. Suppose the problem of handling readiness in the shell could be done in a "magically simple" way, I would personally prefer the original way. However, I would like the switch between mdev, mdevd, udev etc to be painless, so `devd' is not necessarily present; instead, I want `devices.mdevd' / `devices.udevd' to automatically drag `devd' into the dependency tree, even if it is `devd' that depends on `devices' instead of the converse. This request is admittedly based on a fictional premise, but the supposed relation between `devices' and `devd' is similar to that between `wpa_supplicant' and `wpa_cli', and the latter is not fictional. I do not find this kind of "reverse" dependencies trivially doable in preprocessors (like slew's `prep'). The strightforward way to make service `srv1' reverse-depend on `srv2' is to create a bundle that contains both `srv1' and `srv2', and then to make all that depend on `srv1' actually depend on the bundle; but how should we name the services? To minimise rewriting of config files, we would naturally considering renaming the original `srv1' to something else and let the bundle take the name. However, the scripts in the original `srv1' may change its behaviour based on the service name (eg. `getty.tty1' and `dhcpc.eth0'), so some careful planning are needed to prevent the renaming procedure from crashing with this mechanism. Any thoughts on these issues? Thank you in advance. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C