Re: tmpfiles.d and docker images (was Re: opentmpfiles & opensysusers, and its use in the Debian policy)

On 2/19/20 1:55 AM, Michael Hudson-Doyle wrote: > On Fri, 3 Jan 2020 at 06:29, Simon McVittie > wrote: > > On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote: > > The advantages of sysusers.d and tmpfiles.d are that you don't need to > > call some magic

Re: tmpfiles.d and docker images (was Re: opentmpfiles & opensysusers, and its use in the Debian policy)

❦ 19 février 2020 13:55 +13, Michael Hudson-Doyle : > So in Ubuntu we got this interesting bug > https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 which can be > summarized as saying that haproxy doesn't work out of the box in a docker > container, because it installs a tmpfiles.d s

tmpfiles.d and docker images (was Re: opentmpfiles & opensysusers, and its use in the Debian policy)

On Fri, 3 Jan 2020 at 06:29, Simon McVittie wrote: > On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote: > > The advantages of sysusers.d and tmpfiles.d are that you don't need to > > call some magic scripts. > > You only need to write declarative configuration files. > > Individual packa

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Zbigniew Jędrzejewski-Szmek writes: > we talked this over in systemd upstream, and decided to make the promise > a bit more official [0]. Independent operation of a bunch of programs is > now explicitly covered, and the stability promise has been extended to > more interfaces. The old wiki page w

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Thu, Jan 02, 2020 at 10:04:28AM -0800, Russ Allbery wrote: > Matthias Klumpp writes: > > > I find that statement quite encouraging. Of course they don't commit > > to not having those depend on systemd-as-PID1, but there really isn't > > a reason to create that dependency, and if for whatever

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/3/20 1:50 PM, Ansgar wrote: > (Probably Thomas forgot to push the branches to GitLab.) Yes, that's the case. My apologies for this. Cheers, Thomas Goirand (zigo)

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/3/20 10:39 PM, Marco d'Itri wrote: > On Jan 03, Thomas Goirand wrote: > >> Could you please, therefore, tell me what feature is missing? If you > If I am not mistaken then you started arguing that we should consider an > hypothetical alternative implementation with missing features, so mayb

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-04 at 05:57, Simon McVittie wrote: > On Fri, 03 Jan 2020 at 19:52:33 -0500, The Wanderer wrote: > >> On 2020-01-03 at 19:33, Simon McVittie wrote: >> >>> D-Bus activation is a D-Bus feature where instead of starting a >>> D-Bus service (another sort of daemon) "eagerly" in case it mi

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, 03 Jan 2020 at 19:52:33 -0500, The Wanderer wrote: > On 2020-01-03 at 19:33, Simon McVittie wrote: > > D-Bus activation is a D-Bus feature where instead of starting a > > D-Bus service (another sort of daemon) "eagerly" in case it might be > > needed, the dbus-daemon starts that D-Bus servi

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/3/20 10:05 AM, Thomas Goirand wrote: > On 1/3/20 2:33 AM, Sam Hartman wrote: >> Secondly, by using systemd-tmpfiles when we can, we gain support for any >> additional features that are implemented. > > That's where I don't agree. While it's nice to have such a declarative > system, I don't

Re: opentmpfiles & opensysusers, and its use in the Debian policy

> "Thomas" == Thomas Goirand writes: Thomas> On 1/3/20 7:31 PM, Russ Allbery wrote: Thomas> explore and develop alternate init systems and alternatives to systemd Thomas> features." Thomas> Exploring alternatives is precisely what I'm doing. The same way I've Thomas> fe

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-03 at 19:33, Simon McVittie wrote: > On Fri, 03 Jan 2020 at 18:07:36 -0500, The Wanderer wrote: > >> What I'm concerned about is dbus socket activation, or similar, >> leading to e.g. logind getting activated by logging in at the text >> console. >> >> I thought I understood that sock

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, 03 Jan 2020 at 18:07:36 -0500, The Wanderer wrote: > What I'm concerned about is dbus socket activation, or similar, leading > to e.g. logind getting activated by logging in at the text console. > > I thought I understood that socket activation via dbus was one of the > features which didn

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Am Sa., 4. Jan. 2020 um 00:16 Uhr schrieb Russ Allbery : > > The Wanderer writes: > > > What I'm concerned about is dbus socket activation, or similar, leading > > to e.g. logind getting activated by logging in at the text console. > > > I thought I understood that socket activation via dbus was o

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, 03 Jan 2020 at 14:43:48 -0800, Russ Allbery wrote: > The Wanderer writes: > > If I recall and understand correctly, installing systemd-the-package > > will result in at least some of the daemons therein [being run] > > This is the bit that I'm fairly sure is not the case. > > All of the

Re: opentmpfiles & opensysusers, and its use in the Debian policy

The Wanderer writes: > What I'm concerned about is dbus socket activation, or similar, leading > to e.g. logind getting activated by logging in at the text console. > I thought I understood that socket activation via dbus was one of the > features which didn't require systemd as PID-1 to functio

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-03 at 17:43, Russ Allbery wrote: > The Wanderer writes: > >> If I recall and understand correctly, installing >> systemd-the-package will result in at least some of the daemons >> therein - including both systemd itself, and systemd-logind - being >> set up to run automatically in the

Re: opentmpfiles & opensysusers, and its use in the Debian policy

The Wanderer writes: > If I recall and understand correctly, installing systemd-the-package > will result in at least some of the daemons therein - including both > systemd itself, and systemd-logind - being set up to run automatically > in the correct contexts (whether by scripted invocation set

Re: opentmpfiles & opensysusers, and its use in the Debian policy

(Here's another one I may later wind up regretting; I'm out on too many if-I-remember and if-I-understand limbs, and am thus speaking based on too many possibly-false premises, and I'm also now explaining personal preferences which might readily be deemed too minor or too niche to be reasonable to

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Jan 03, Thomas Goirand wrote: > Could you please, therefore, tell me what feature is missing? If you If I am not mistaken then you started arguing that we should consider an hypothetical alternative implementation with missing features, so maybe you should explain what may be missing. > > A

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Thomas Goirand writes: > Yes, there's drawbacks in general. However, you *cannot* just say, we're > going to use the systemd implementation "just because it's the > refrence", without even giving me some space to at least *TRY* the > alternative, to see if it's valuable or not. Yes, I agree. >

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/3/20 7:15 PM, Marco d'Itri wrote: > On Jan 03, Thomas Goirand wrote: > >> That's where I don't agree. While it's nice to have such a declarative >> system, I don't think it's reasonable to impose the implementation of >> any change to systemd to all the other init systems. > I do. Good luck

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Jan 03, Thomas Goirand wrote: > Yes, there's drawbacks in general. However, you *cannot* just say, we're > going to use the systemd implementation "just because it's the > refrence", without even giving me some space to at least *TRY* the As usual this is about much more than you, and I am qui

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/3/20 7:31 PM, Russ Allbery wrote: > The guidance of option B is that we are committing to reviewing and > working collaboratively with anyone who wants to support alternate init > systems, but that implementation strategy is subject to technical review. It reads: "However, Debian remains an

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, Jan 03, 2020 at 02:29:37PM -0500, The Wanderer wrote: > The accepting of init scripts seemed to me like an essential piece of > making sure those scripts would be present wherever they would be > needed. Your suggestion above seems to provide a way to make it less > essential, and thus woul

Re: opentmpfiles & opensysusers, and its use in the Debian policy

> "Russ" == Russ Allbery writes: Russ> So far as I can tell, installing the systemd package by itself shouldn't Russ> do anything. It's possible that I'm wrong, but if so, it might be easier Russ> to just fix that problem rather than splitting out binaries. It's also Russ

Re: opentmpfiles & opensysusers, and its use in the Debian policy

The Wanderer writes: > On 2020-01-03 at 13:35, Russ Allbery wrote: >> The Wanderer writes: >>> If the maintainers of systemd-the-package would be willing to not only >>> split out these binaries into standalone package(s), but accept such >>> init scripts for inclusion in those packages, >> Why

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, Jan 03, 2020 at 10:31:53AM -0800, Russ Allbery wrote: > Support for kFreeBSD and Hurd is obviously a valid argument in favor of > some level of support for non-systemd implementations. But then there is the question on how much work it would be to port the **systemd** implementations to Fr

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-03 at 13:35, Russ Allbery wrote: > The Wanderer writes: > >> Unless my understanding of the architecture of >> systemd-the-init-system is entirely incorrect, running these >> .service'es is handled by /bin/systemd. If having these programs >> run at boot time is considered essential t

Re: opentmpfiles & opensysusers, and its use in the Debian policy

> "Marco" == Marco d'Itri writes: >> You are being obviously biased toward systemd here. Just try to think a Marco> Indeed: obviously, most people actually do not mind using systemd... >> 2nd time: the same way, what if opentmpfiles implements a new feature >> that is *not*

Re: opentmpfiles & opensysusers, and its use in the Debian policy

The Wanderer writes: > Unless my understanding of the architecture of systemd-the-init-system > is entirely incorrect, running these .service'es is handled by > /bin/systemd. If having these programs run at boot time is considered > essential to full functionality of these facilities - and I'd be

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Thomas Goirand writes: > I think you and many others should be extremely careful when talking > about proposal B just as if it was a clear winner of the poll. If you > are then discarding the opinion of everyone else who didn't want it as > the winning option, and not consider the GR result as a

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Jan 03, Thomas Goirand wrote: > That's where I don't agree. While it's nice to have such a declarative > system, I don't think it's reasonable to impose the implementation of > any change to systemd to all the other init systems. I do. Good luck persuading the consumers of this API that they s

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/3/20 2:23 PM, Sam Hartman wrote: > Proposal B is about letting you innovate (for example doing your own > implementation of tmpfiles that you opt into on a per-package basis) and > doing the integration work for alternatives like elogind where you > cannot use the systemd interface. > > --Sa

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-03 at 09:13, Ansgar wrote: > The Wanderer writes: > >> However, as it remains the case that they are shipped in the same >> package as /bin/systemd, and as I gather (mostly from this thread, >> I think) that some of the ways they are expected to be invoked >> probably rely on having s

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-03 at 07:50, Ansgar wrote: > The Wanderer writes: > >> On 2020-01-02 at 08:14, Thomas Goirand wrote: >> >>> As I wrote, no need to complain, but act. >>> >>> https://salsa.debian.org/debian/opentmpfiles >> >> For me (with no salsa account, therefore not logged in; I don't >> know if

Re: opentmpfiles & opensysusers, and its use in the Debian policy

The Wanderer writes: > On 2020-01-02 at 08:14, Thomas Goirand wrote: >> As I wrote, no need to complain, but act. >> >> https://salsa.debian.org/debian/opentmpfiles > > For me (with no salsa account, therefore not logged in; I don't know if > that makes any difference), this page states "The repos

Re: opentmpfiles & opensysusers, and its use in the Debian policy

The Wanderer writes: > However, as it remains the case that they are shipped in the same > package as /bin/systemd, and as I gather (mostly from this thread, I > think) that some of the ways they are expected to be invoked probably > rely on having systemd-the-daemon running They don't rely on the

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-03 at 08:50, Andrej Shadura wrote: > Hi, > > On Fri, 3 Jan 2020 at 14:02, The Wanderer > wrote: > >> On 2020-01-02 at 09:03, Sam Hartman wrote: >> >>> My understanding is that systemd's implementation of tmpfiles >>> and sysusers works even while systemd is not pid 1. Why do we >>>

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Hi, On Fri, 3 Jan 2020 at 14:02, The Wanderer wrote: > On 2020-01-02 at 09:03, Sam Hartman wrote: > > My understanding is that systemd's implementation of tmpfiles and > > sysusers works even while systemd is not pid 1. Why do we need > > multiple implementations for Debian ports where systemd ru

Re: opentmpfiles & opensysusers, and its use in the Debian policy

> "Thomas" == Thomas Goirand writes: Thomas> On 1/3/20 2:33 AM, Sam Hartman wrote: >> Secondly, by using systemd-tmpfiles when we can, we gain support for any >> additional features that are implemented. Thomas> That's where I don't agree. While it's nice to have such a decl

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-02 at 09:03, Sam Hartman wrote: > My understanding is that systemd's implementation of tmpfiles and > sysusers works even while systemd is not pid 1. Why do we need > multiple implementations for Debian ports where systemd runs? There are those who don't run systemd-the-daemon even as

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 2020-01-02 at 08:14, Thomas Goirand wrote: > As I wrote, no need to complain, but act. > > https://salsa.debian.org/debian/opentmpfiles For me (with no salsa account, therefore not logged in; I don't know if that makes any difference), this page states "The repository for this project is empt

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/3/20 2:33 AM, Sam Hartman wrote: > Secondly, by using systemd-tmpfiles when we can, we gain support for any > additional features that are implemented. That's where I don't agree. While it's nice to have such a declarative system, I don't think it's reasonable to impose the implementation of

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, Jan 03, 2020 at 09:20:44AM +0100, Thomas Goirand wrote: > On 1/2/20 6:01 PM, Matthias Plump wrote: > > I don't have both of those. Since I am on an usrmerged system though, > > /bin/systemd-sysusers and /usr/bin/systemd-sysusers are exactly the > > same binary. Maybe that's the thing that c

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, 03 Jan 2020 at 09:18:58 +0100, Thomas Goirand wrote: > ... after this discussion, it looks like we would prefer: > /bin/systemd-tmpfiles and /bin/systemd-sysusers > > For this, we need systemd to use update-alternatives for them then, so > that opentmpfiles & opensysusers do not need to us

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/2/20 6:01 PM, Matthias Plump wrote: > I don't have both of those. Since I am on an usrmerged system though, > /bin/systemd-sysusers and /usr/bin/systemd-sysusers are exactly the > same binary. Maybe that's the thing that caused a bit of confusion? I'm not on a usrmerged system, and I have bot

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/2/20 5:13 PM, Ansgar wrote: > Thomas Goirand writes: >> My proposal is for Debian to standardize on: >> /bin/tmpfiles >> and: >> /usr/bin/sysusers > > Why rename things? I don't mind either ways, but... ... after this discussion, it looks like we would prefer: /bin/systemd-tmpfiles and /bin

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/2/20 7:08 PM, Russ Allbery wrote: > I really want to get rid of maintainer scripts as much as possible in > favor of pure declarative syntax in the packages. I think the fewer > Debian packages that need maintainer scripts, the easier the distribution > as a whole will be to maintain, analyze

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On 1/2/20 6:28 PM, Simon McVittie wrote: > On systemd systems, that's approximately: > > - run systemd-tmpfiles when a package installs a tmpfiles.d snippet > (this is added to the package's postinst by dh_installsystemd) > > - run systemd-sysusers when a package installs a sysusers.d snippet >

Re: opentmpfiles & opensysusers, and its use in the Debian policy

> "Lorenz" == Lorenz writes: Lorenz> Sam Hartman wrote: >> My understanding is that systemd's implementation of tmpfiles and >> sysusers works even while systemd is not pid 1. >> Why do we need multiple implementations for Debian ports where systemd >> runs? >> I unde

Re: opentmpfiles & opensysusers, and its use in the Debian policy

[ please keep me in CC, I'm not subscribed to this list] Sam Hartman wrote: > My understanding is that systemd's implementation of tmpfiles and > sysusers works even while systemd is not pid 1. > Why do we need multiple implementations for Debian ports where systemd > runs? > I understand why we

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Simon McVittie: > [...] > > The opentmpfiles and opensysusers packaging will need to arrange to do > something analogous, most likely in cooperation with dh_installsystemd > or some other debhelper step for the first two points, and with LSB init > scripts for the tasks where systemd uses one-shot

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Jan 02, Thomas Goirand wrote: > My proposal is for Debian to standardize on: > /bin/tmpfiles > > and: > /usr/bin/sysusers We already have an interface used by many packages, hence I see no reason to change it. Actually it is still not obvious to me why Debian would need a second implementa

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Simon McVittie writes: > Using dpkg triggers to run the tmpfiles and sysusers tools automatically > is probably not enough, because a package's postinst will often run > system services (systemd unit, LSB init script, etc.), and those system > services need to be run *after* creating at least thi

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Matthias Klumpp writes: > I find that statement quite encouraging. Of course they don't commit > to not having those depend on systemd-as-PID1, but there really isn't > a reason to create that dependency, and if for whatever reason there > will be one at some point, we can switch away on systems

Re: opentmpfiles & opensysusers, and its use in the Debian policy

> "Simon" == Simon McVittie writes: Simon> I think this is partly down to whether the systemd maintainers (both Simon> upstream and downstream) are willing to support this use, or whether Simon> they would prefer non-systemd-booted systems to use a reimplementation Simon> wh

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Am Do., 2. Jan. 2020 um 18:41 Uhr schrieb Simon McVittie : > [...] > I seem to remember a systemd upstream developer being asked during > recent discussions whether they were willing to guarantee that > systemd-tmpfiles and systemd-sysusers will continue to work when used on > non-systemd-booted sy

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Thu, 02 Jan 2020 at 09:03:24 -0500, Sam Hartman wrote: > My understanding is that systemd's implementation of tmpfiles and > sysusers works even while systemd is not pid 1. > Why do we need multiple implementations for Debian ports where systemd > runs? I think this is partly down to whether th

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote: > On Thu, Jan 2, 2020 at 9:22 PM Thomas Goirand wrote: > [...] > > My proposal is for Debian to standardize on: > > /bin/tmpfiles > > > > and: > > /usr/bin/sysusers FWIW, the systemd versions of both tools are canonically in /bin (that's

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Am Do., 2. Jan. 2020 um 17:28 Uhr schrieb Ansgar : > > Thomas Goirand writes: > > [...] > > I'm not sure why > > there's both /bin/systemd-sysusers and /usr/bin/systemd-sysusers, and > > which one should be used. > > For the same reason there is /bin/bash and /usr/bin/bash probably? I don't have b

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Thomas Goirand writes: > My proposal is for Debian to standardize on: > /bin/tmpfiles > and: > /usr/bin/sysusers Why rename things? > I'm not sure why > there's both /bin/systemd-sysusers and /usr/bin/systemd-sysusers, and > which one should be used. For the same reason there is /bin/bash and /u

Re: opentmpfiles & opensysusers, and its use in the Debian policy

On Thu, Jan 2, 2020 at 9:22 PM Thomas Goirand wrote: [...] > My proposal is for Debian to standardize on: > /bin/tmpfiles > > and: > /usr/bin/sysusers > I don't understand why we need these. The advantages of sysusers.d and tmpfiles.d are that you don't need to call some magic scripts. You only

Re: opentmpfiles & opensysusers, and its use in the Debian policy

My understanding is that systemd's implementation of tmpfiles and sysusers works even while systemd is not pid 1. Why do we need multiple implementations for Debian ports where systemd runs? I understand why we might want alternatives for kfreebsd and hurd. But if my understanding that the systemd

Re: opentmpfiles & opensysusers, and its use in the Debian policy

Hi Thomas, Thank you for working on these! On Thu, Jan 02, 2020 at 02:14:34PM +0100, Thomas Goirand wrote: > As I wrote, no need to complain, but act. > > https://salsa.debian.org/debian/opentmpfiles > https://salsa.debian.org/debian/opensysusers > > Both are now in the NEW queue, and both need