this post was submitted on 07 Mar 2024
476 points (96.5% liked)

linuxmemes

21210 readers
145 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] [email protected] 15 points 8 months ago (4 children)

    I am fine with systemd. It works. It is more complicated than init.d

    Before you copied some random file you edited and put it in init.d and it worked. Now you copy some systemd services file into systemd and run enable and start and it doesn't work because you don't know what you are doing.

    I didn't know what I was doing in init.d too but now I have to learn systemd services. Once you know a bit it will work then (probably)

    [–] [email protected] 24 points 8 months ago

    I disagree. Before I had to copy and edit a huge-ass script (100+ lines) in init.d where 80% of it was concerned with PID files. I just want to start a process on boot, why is it so hard?

    Now I can look at the documentation and write a simple unit file myself. It's like 4 lines.

    [–] [email protected] 13 points 8 months ago* (last edited 8 months ago)

    init.d wasn't really what you'd call an "init" "system." It was shell + conventions about how to write shell scripts to manage each service. It effectively offloaded most of the work people wanted an init system/service supervisor to do onto developers that just needed to ship a system service. To be honest, it was insane. Templates/patterns/best practices emerged, but at the end of the day, init.d was just shell, and it caused tons of problems.

    The extra complexity of systemd is in exchange for dependency management, service supervision, tons of things that are important/desirable for sysadmins/developers today, but are all far outside the scope of init. I'd much rather cope with the extra complexity of systemd in exchange for being able to write an actual service definition file.

    [–] [email protected] 10 points 8 months ago (1 children)

    Before you copied some random file you edited and put it in init.d and it worked.

    Before you copied some random file you edited and put it in init.d and it appeared to be working but then failed in random ways the first time you restarted, the first time you rebooted, the first time you restarted it via sudo instead of directly as root since some environment variable differed,...

    So really it only appeared to be working in my experience because you had no real way to check.

    [–] [email protected] 3 points 8 months ago (1 children)

    I mean it should be obviously clear that copying random files isn't sth. You should do anyways

    [–] [email protected] 4 points 8 months ago

    Well, in this context what we are talking about is some random init script from some other service because nobody wants to write all that crap from scratch every time.

    [–] [email protected] 2 points 8 months ago

    The systemd init units should be setup when you install a package.