• rtxn@lemmy.worldMEnglish
    1·
    2 months ago
    [     *] (3 of 3) A stop job is running for User Manager for UID 1000... (1m12s / 3m)
        • prime_number_314159@lemmy.world
          1·
          2 months ago

          Systemd is trying to stop a service. To do an action to a service (or any unit), it runs a job. The job to stop a service is called a stop job. Once the stop job is taken off the job queue, the stop job is running.

          The method of stopping a service is configurable, but the default is to send a kill signal to the MainPID, then wait for the process to exit. If it doesn’t, after a timeout, the kill is reattempted with a harsher signal.

  • cley_faye@lemmy.world
    1·
    2 months ago

    systemd, as a service manager, is decent. Not necessarily a huge improvement for most use cases.

    systemd, the feature creep that decides to pull every single possible use case into itself to manage everything in one place, with qwirks because making a “generic, do everything” piece of software is not a good idea, is not that great.

    systemd, the group of tools that decided to manage everything by rewriting everything from scratch and suffering from the same issue that were fixed decades ago, just because “we can do better” while changing all well known interfaces and causing a schism with either double workload or dropping support for half the landscape from other software developer is really stupid.

    If half the energy that got spent in the “systemd” ecosystem was spent in existing projects and solutions that already addressed these same issues, it’s likely we’d be in a far better place. Alas, it’s a new ecosystem, so we spend a lot of energy getting to the same point we were before. And it’s likely that when we get close to that, something new will show up and start the cycle again.

  • MonkderVierte@lemmy.ml
    1·
    2 months ago

    Bullshit, there’s always reasons listed. Some more, some less opiniated, but there’s always lists.

    For me personally:

    • no portability
    • not-invented-here syndrome
      • manages stuff it shouldn’t, like DNS
      • makes some configurations unneccessarily complicated
    • more CVE than all other init together
      • service manager that runs with PID 0
    • BaumGeist@lemmy.ml
      0·
      2 months ago

      To the feature creep: that’s kind of the point. Why have a million little configs, when I could have one big one? Don’t answer that, it’s rhetorical. I get that there are use cases, but the average user doesn’t like having to tweak every component of the OS separately before getting to doom-scrolling.

      And that feature creep and large-scale adoption inevitably has led to a wider attack surface with more targets, so ofc there will be more CVEs, which—by the way—is a terrible metric of relative security.

      You know what has 0 CVEs? DVWA.

      You know what has more CVEs and a higher level of privilege than systemd? The linux kernel.

      And don’tme get started on how bughunters can abuse CVEs for a quick buck. Seriously: these people’s job is seeing how they can abuse systems to get unintended outcomes that benefit them, why would we expect CVEs to be special?

      TL;DR: That point is akin to Trump’s argument that COVID testing was bad because it led to more active cases (implied: being discovered).

    • renzev@lemmy.worldOPEnglish
      1·
      2 months ago

      I’m more of a runit guy, but I started using Alpine recently, and I have to say, openrc is also pretty nice!

  • mogoh@lemmy.ml
    0·
    2 months ago

    The systemd debate is basically dead. There are very few against it, but many accept it by now. Just avoid phoronix forum and some other places.

    • tortina_original@lemmy.world
      0·
      2 months ago

      “Just avoid places that sysadmins and security guys frequent and get your opinions on systemd from memes and people running arch on home machine”. Great plan.

      Systemd is absolute and utter shit, especially from security perspective.

      Noone was asking security guys but package maintainers.

      My favorite systemd thing is booting up a box with 6 NICs where only 1 was configured during the initial setup. Second favorite is betting on whether it will hang on reboot/shutdown.

      Great tool, 10/10.

      • qjkxbmwvz@startrek.website
        1·
        2 months ago

        My favorite was when the behavior of a USB drive in /etc/fstab went from “hmm it’s not plugged in at boot, I’ll let the user know” to “not plugged in? Abort! Abort! We can’t boot!”

        This change over previous init behavior was especially fun on headless machines…

      • renzev@lemmy.worldOPEnglish
        1·
        2 months ago

        I’ve gotten into quite a lot of systemd-related flame wars so far, and what strikes me is that I haven’t heard a single reason why systemd is good and should be used in favor of openrc/sysvinit/whatever. The only arguments I hear in favor of systemd, even from the its diehard defenders, are justifications why it’s not that bad. Not once have I heard someone advocate for systemd with reasoning that goes likes “Systemd is superior to legacy init systems because you can do X much easier” or “systemd is more secure because it’s resistant against Y attack vector”. It’s always “Linus says it’s allright” or “binary logfiles aren’t a problem, you can just get them from journald instead of reading the file”, or “everyone already uses it”.

        When it comes to online discourse, systemd doesn’t have advocates, it has apologists.

  • SavvyWolf@pawb.socialEnglish
    3·
    2 months ago

    “I hate systemd, it’s bloated and overengineered” people stay, perched precariously on their huge tower of shell scripts and cron jobs.

    • azertyfun@sh.itjust.works
      1·
      2 months ago

      Wait until you learn about debhelper.

      If you use a debian-based system, unless you have actively looked at the DH source, the one thing that built virtually every package on your system, you do not get to say anything about “bloat” or “KISS”.

      DH is a monstrous pile of perl scripts, only partially documented, with a core design that revolves around a spaghetti of complex defaults, unique syntax, and enough surprising side effects and crazy heuristics to spook even the most grizzled greybeards. The number of times I’ve had to look at the DH perl source to understand a (badly/un)documented behavior while packaging something is not insignificant.

      But when we replaced a bazillion bash scripts with a (admittedly opinionated but also stable and well documented) daemon suddenly the greybeards acted like Debian was going to collapse under the weight of its own complexity.

    • Damage@feddit.it
      2·
      2 months ago

      huge tower of shell scripts and cron jobs.

      That’s bloat. I start all my services manually according to my needs. Why start cupsd BEFORE I need to print anything?