Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday December 10 2019, @02:06PM   Printer-friendly

Debian Developers Take To Voting Over Init System Diversity

It's been five years already since the vote to transition to systemd in Debian over Upstart while now there is the new vote that has just commenced for judging the interest in "init system diversity" and just how much Debian developers care (or not) in supporting alternatives to systemd.

Due to Debian developers having differing opinions on handling non-systemd bugs in 2019 and the interest/commitment to supporting systemd alternatives in the scope of Debian packaging and various related friction points, they've taken to a new general resolution over weighing init system diversity.

The ballot is available on-line. The choices are:

Choice 1: F: Focus on systemd
Choice 2: B: Systemd but we support exploring alternatives
Choice 3: A: Support for multiple init systems is Important
Choice 4: D: Support non-systemd systems, without blocking progress
Choice 5: H: Support portability, without blocking progress
Choice 6: E: Support for multiple init systems is Required
Choice 7: G: Support portability and multiple implementations
Choice 8: Further Discussion

[Ed. note: I'm not sure what the letters after the choice numbers indicate, nor do I know where "C" disappeared to.]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Informative) by Anonymous Coward on Tuesday December 10 2019, @07:43PM (12 children)

    by Anonymous Coward on Tuesday December 10 2019, @07:43PM (#930727)

    Too bad that is the wrong service. NetworkManager is a RedHat project under GNOME, that interfaces with systemd-networkd among others. Systemd and FreeDesktop haven't merged completely yet. Now, I don't want you to claim that I got you on a technicality, so I also want to point out that you would have missed systemd-resolved [archlinux.org], which is probably what GP was talking about in the first place.

    Starting Score:    0  points
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  

    Total Score:   1  
  • (Score: 0) by Anonymous Coward on Tuesday December 10 2019, @08:11PM (11 children)

    by Anonymous Coward on Tuesday December 10 2019, @08:11PM (#930745)

    systemd-resolved is dependent on NetworkManager on my systems.

    Disabling/masking it prevents systemd-resolved from running.

    If that's not the case on other distros, I'm sure that generalizing it would work too:

    systemctl disable systemd-resolved
    systemctl mask systemd-resolved

    Or any other unwanted service for that matter.

    I trust that GP would be smart enough to figure that out.

    My apologies for any confusion, friend.

    • (Score: 0) by Anonymous Coward on Tuesday December 10 2019, @11:26PM (10 children)

      by Anonymous Coward on Tuesday December 10 2019, @11:26PM (#930849)

      If it weren't for the black magic that systemd programmers got from their RedHat overlords, I'd think you are lying. It is literally the opposite on the machine I checked. On the one hand, I wonder what sort of trick was used to reverse dependencies like that. But on the other hand, I'm not sure I do. I bet it has something to do with the unholy merging of FreeDesktop and systemd or maybe wifi-enabled vs ethernet-only machines. Either way, have fun troubleshooting that, especially across distros.

      • (Score: 0) by Anonymous Coward on Wednesday December 11 2019, @12:09AM (9 children)

        by Anonymous Coward on Wednesday December 11 2019, @12:09AM (#930870)

        If it weren't for the black magic that systemd programmers got from their RedHat overlords

        WTF are you going on about? There's no magic.* There's just code.

        Your inane hyperbole would be amusing, if it wasn't so sad. I feel sorry for you.

        Either way, have fun troubleshooting that, especially across distros.

        I don't need to. My installations disable all that garbage by default. When you bother to get a clue (you might try it sometime), there are all sorts of things you can do. Funny that.

        *SCSI is *NOT* magic. There are *fundamental technical reasons* why you have to sacrifice a young goat to your SCSI chain every now and then

        • (Score: -1, Troll) by Anonymous Coward on Wednesday December 11 2019, @03:00AM

          by Anonymous Coward on Wednesday December 11 2019, @03:00AM (#930931)

          I don't need to. My installations disable all that garbage by default.

          Until new version of systemd adds more garbage, or removes a way for you to disable existing garbage. When you bother to get a clue (you might try it sometime), you can spot a game you cannot win. Funny that.

        • (Score: 0) by Anonymous Coward on Wednesday December 11 2019, @05:43AM (7 children)

          by Anonymous Coward on Wednesday December 11 2019, @05:43AM (#930972)

          What I was saying is that on one system NetworkManager won't start without systemd-resolved and on the other systemd-resoved apparently won't start without NetworkManager. In order for that to be the case, somewhere along the line NetworkManager and systemd-resolved were changed to make that requirement go the other direction. That is why I said "black magic" as a handwave to both the feature change required for that and the distro differences necessary for that requirement. And the reason why that is "fun" between distros is that there is apparently no clear requirement difference or concept between them, unlike your X client requiring an X server or Apache requiring a network or Plymouth requiring a console. Its just one more gratuitous waste of cognitive effort (usually while under time pressure) to figure out which is which on the systems you are switching between.

          Also, as you tell me to "get a clue," if the dependency between the two can apparently switch between distros and versions and all you do is disable NetworkManager, how can you be sure you actually disabled it all? You'd have to check both. That is the point. Even in disabling them, such inconsistent behavior results in unnecessary work or odd problems could arise when trying to run what you do want.

          • (Score: 0) by Anonymous Coward on Wednesday December 11 2019, @08:28AM (5 children)

            by Anonymous Coward on Wednesday December 11 2019, @08:28AM (#930988)

            What I was saying is that on one system NetworkManager won't start without systemd-resolved and on the other systemd-resoved apparently won't start without NetworkManager.

            That's not "black magic" as you say. The appropriate thing to do, IMHO, is not to use any of that garbage, as it doesn't add anything useful (systemd-resolved is a stub resolver which is completely redundant, and NetworkManager really only provides utility when you have removable network devices -- which can be useful, but is mostly an edge case), as just about all the functionality it provides (except as I noted) is provided by solid tools already installed on your system.

            Also, as you tell me to "get a clue," if the dependency between the two can apparently switch between distros and versions and all you do is disable NetworkManager, how can you be sure you actually disabled it all? You'd have to check both. That is the point. Even in disabling them, such inconsistent behavior results in unnecessary work or odd problems could arise when trying to run what you do want.

            Yes, I did. Firstly, your description ("black magic") made it pretty clear that you don't understand how systemd dependencies work, nor did you provide *any* useful information. That's *two* areas where you aren't displaying "a clue."

            If you did understand it, you'd realize that systemctl mask <service> will block any attempt to start that service, even if it's required by a dependency, which will cause that dependent service to fail as well. When it comes to systemd-resolved and/or NetworkManager, that's as it should be IMHO.

            If you don't want one or both of those to run, then you absolutely need to check to make sure one or both is not just disabled, but masked as well -- as a disabled service will still start if a service says it's dependent upon it. Which you, apparently, didn't know -- hence my statement.

            This isn't rocket surgery. And while I generally prefer init systems other than systemd (I'd note that systemd-resolved and NetworkManager are *not* part of the init system, but separate tools that are poor replacements for existing tools and shouldn't be used, IMHO), systemd does function as an init system *and* provides relatively consistent results.

            However, those results are highly dependent on the configuration, order of execution and management of service dependencies. If those settings/configuration aren't configured properly, you will almost certainly get inconsistent results, and often serious problems. What's more, the same is true for sysV, Upstart and every other init system as well.

            If you don't understand how such things work in systemd, there's a whole raft of documentation that will explain it to you in long and painful detail.

            It's clear that you don't really understand how to use and configure systemd effectively. As such, it would make sense to either learn what you'd need to know to do so, or use a different init system.

            Personally, it's not a huge deal to use systemd (specifically the init system -- just about all the rest of the systemd-<whatever> stuff is redundant and inferior to other, existing tools, which is why I ensure they are disabled/masked on all my systems). SysV and other init systems work very well, and I've used most of them over the past 30 years or so.

            And so, yes. If you're going to use a distro that features systemd as its init system, then you definitely should get a clue and learn how it works. Otherwise, you're just asking for problems. As you've already discovered.

            • (Score: -1, Troll) by Anonymous Coward on Wednesday December 11 2019, @12:03PM

              by Anonymous Coward on Wednesday December 11 2019, @12:03PM (#931018)

              So many words to say "I'm confused".

              Firstly, your description ("black magic") made it pretty clear that you don't understand how systemd dependencies work

              AC wrote "black magic" in regards to changing dependencies between services, not to how disabling or masking works.

              systemd-resolved is dependent on NetworkManager on my systems.

              nor did you provide *any* useful information

              Letting you know that NetworkManager depends on systemd-resolved on other systems is very useful information, but you are blinded by hubris.

              If you're going to use a distro that features systemd as its init system, then you definitely should get a clue and learn how it works.

              Looks like you have more learning to do. Otherwise, you will have problems when systemd gets updated.

            • (Score: 0) by Anonymous Coward on Wednesday December 11 2019, @11:03PM (3 children)

              by Anonymous Coward on Wednesday December 11 2019, @11:03PM (#931251)

              You are saying a lot about things not about my point. My point isn't how to disable anything or how dependencies actually work or anything to do with init systems, even systemd. I understand that using "Wants," "Requisite," "Requires," etc. you can make anything depend on anything else. I also understand hard vs soft dependencies and explicit vs implicit dependencies. But none of that is the issue I was attempting to raise.

              What I was pointing out is that usually there is some logic as to why things depend on each other, especially by default, as shown in the examples I provided. In the case of NetworkManager and systemd-resolved, that is broken because you have one system where the relationship goes one way and another where it goes the other. There is, apparently, no logical order to the way those two services are related, which is somewhat fascinating given what they are supposed to do. That is the point, the entire point, I was attempting to make, with everything else being aside or conceptual fallout.

              • (Score: 0) by Anonymous Coward on Thursday December 12 2019, @01:54AM (2 children)

                by Anonymous Coward on Thursday December 12 2019, @01:54AM (#931295)

                What I was pointing out is that usually there is some logic as to why things depend on each other, especially by default, as shown in the examples I provided. In the case of NetworkManager and systemd-resolved, that is broken because you have one system where the relationship goes one way and another where it goes the other. There is, apparently, no logical order to the way those two services are related, which is somewhat fascinating given what they are supposed to do. That is the point, the entire point, I was attempting to make, with everything else being aside or conceptual fallout.

                I'd venture to guess that the publishers of any specific distro have reasons (whether they are good reasons or not) as to why they set the default service dependencies the way they do. That such defaults aren't the same between different distros isn't surprising, or very interesting -- at least not to me.

                Given that many distros rely, by default, on NetworkManager to bring up networking and systemd-resolved requires the network to be up in order to function, it's not surprising that there would be some sort of dependency there.

                Are you arguing that there should be a "standard" set of dependencies across every distro? That would be a pretty tough row to hoe, IMHO. What's more, I don't think it's a good idea. Distros differ because they have different foci and/or provide different sets of functionality. I like that there are many different distros myself.

                If consistent configuration is important to you, perhaps you should just settle on one specific distro and use that -- then you won't have issues with differing default dependencies.

                Perhaps I'm missing something important? If so, do tell, as it's not clear to me what makes this important or relevant.

                • (Score: 0) by Anonymous Coward on Thursday December 12 2019, @04:22AM (1 child)

                  by Anonymous Coward on Thursday December 12 2019, @04:22AM (#931322)

                  Exactly, there is an underlying logic available as to why systemd-resolved should depend on NetworkManager (or alternatives like connman, wicd, systemctl-networkd, etc.). But then you have other systems where NetworkManager depends on systemd-resolved, ostensibly because it requires some feature of it like resolving a domain or network name to function. That is what I find interesting. Either the technology behind them changed or the packagers' thinking differs to the point where the services relationship reversed. Its not that there should be a "standard" or that all of them be the same; its that there is usually an underlying logic to any human system. Different strokes for different folks, but I find the underlying idea of such a reversal fascinating, and somewhat "magical" (to harken back to an earlier term). As if next year the packagers made it so that bringing up your network required ssh or nginx running or your X server refusing to start if a client didn't load. Regardless, there would have to be some major differences in either the thought process or the underlying software for such to occur.

                  • (Score: 0) by Anonymous Coward on Thursday December 12 2019, @09:25PM

                    by Anonymous Coward on Thursday December 12 2019, @09:25PM (#931539)

                    But then you have other systems where NetworkManager depends on systemd-resolved, ostensibly because it requires some feature of it like resolving a domain or network name to function. That is what I find interesting.

                    I have some ideas about that, with the caveat that I don't have any actual information from those who made such choices.

                    As you're almost certainly aware, even if you disable a service, it can still be started by another service that declares it *either* dependent on that service, or dependent on *another service* that's dependent on the disabled service. That dependency tree can be several levels deep.

                    Which is why the 'mask' (which keeps a service from starting under *any* circumstances) command is necessary for systemctl/systemd. If any service can start any other service simply by asking for it (or having a dependency or even a dependency of a dependency do so), that's a *huge* security and stability risk.

                    Interestingly, on both Fedora Core 30 (RH-based) and MXLinux 19(Debian-based), the NetworkManager (/usr/lib/systemd/system/NetworkManager.service) unit file specifies:

                    [Unit]
                    Description=Network Manager
                    Documentation=man:NetworkManager(8)
                    Wants=network.target
                    After=network-pre.target dbus.service

                    Before=network.target network.service

                    ---snip---

                    [Install]
                    WantedBy=multi-user.target
                    Also=NetworkManager-dispatcher.service

                    # We want to enable NetworkManager-wait-online.service whenever this service
                    # is enabled. NetworkManager-wait-online.service has
                    # WantedBy=network-online.target, so enabling it only has an effect if
                    # network-online.target itself is enabled or pulled in by some other unit.
                    Also=NetworkManager-wait-online.service


                    [emphasis added]

                    And the systemd-resolved (/usr/lib/systemd/system/systemd-resolved.service) unit file specifies:


                    ---snip---
                    [Unit]
                    --snip---
                    DefaultDependencies=no
                    After=systemd-sysusers.service systemd-networkd.service
                    Before=network.target nss-lookup.target shutdown.target
                    Conflicts=shutdown.target
                    Wants=nss-lookup.target
                    ---snip--
                    [Install]
                    WantedBy=multi-user.target
                    Alias=dbus-org.freedesktop.resolve1.service

                    [emphasis added]

                    What's more, neither one starts systemd-resolved by default. Out of curiosity, which distributions did you look at that not only started systemd-resolved by default, but also had the dependencies juxtaposed?

                    I wonder if the folks who maintain the distros you looked at have some published reasoning behind their choices.

          • (Score: 0) by Anonymous Coward on Wednesday December 11 2019, @07:37PM

            by Anonymous Coward on Wednesday December 11 2019, @07:37PM (#931190)

            And the reason why that is "fun" between distros is that there is apparently no clear requirement difference or concept between them

            Who says every distros must/should/can apply the same sets of dependencies in their init system? That's not (and never has been) the case for other init systems across distros, so why should it be so for systemd?

            Also, as you tell me to "get a clue," if the dependency between the two can apparently switch between distros and versions and all you do is disable NetworkManager, how can you be sure you actually disabled it all?

            By making sure you actually understand how this stuff works/is supposed to work. And different distros do things differently -- if they didn't, they would be the same distro. That's really freaky, right? I'm getting chills just thinking about it.