Hacker News Reader

Comment by 0xdeadb00f | Hacker News Reader

I'm certainly not a layperson, but systemd frequently confuses me.

I want to edit a service to harden it for example. Oh, wait I shouldn't edit it directly with vi? Because it gets overwritten by package updates. Okay, makes sense, I need to use systemctl edit instead. But that opens a file that has everything commented out. Do I uncomment the [Unit] heading? What do I need to keep and where do I add my additions? I recall there being a comment at the start of this file, but unless I'm misremembering it doesn't answer that.

All I ask of it to do one thing - start something.service after other.service. yet it just refuses to order them this way. Why? I have no idea. I also have no idea where to start debugging a problem like this. There's a billion ways to try and do this after all: do I add Before=something to other.service? Do I add After=other to something.service? Both? Wants=something?

View on HN

> I want to edit a service to harden it for example. Oh, wait I shouldn't edit it directly with vi? Because it gets overwritten by package updates.

I don't think you're supposed to edit anything inside /usr, except perhaps /usr/local, but even that has a better alternative in the form of $HOME/.local, which is a well defined standard at this point.

Maybe I'm unaware or mistaken but if you're editing anything inside /usr as a normal user, you're either using Linux wrong or doing something unexpected or unusual. This is why requests to make GUI file explorers have root escalation capabilities sound absurd to me. I can't think of a reason why one would need root access when using a file manager, especially a GUI file manager.

> Maybe I'm unaware or mistaken but if you're editing anything inside /usr as a normal user,

I'm not doing any of this as a normal user. I'm doing all of this as root

Even in that case, if you're manually editing anything inside /usr either by being root or by using sudo, you're doing something wrong or unexpected.

Anything inside /usr should only ever be modified by the package manager, not by the root user, or any other user for that matter.

If you want to make system wide changes, make them in /etc. If you want to make user specific changes, make them in $HOME/.config, $HOME/.local. Your package manager should never overwrite anything in /etc or $HOME. If it does, it's a bug.

So here's the thing, right. You are correct. And I agree.

I'll admit something; I forgot where the service files were (I don't use systemd often). So, in my unix wisdom I used `find` to find the files ending with 'service'. The only ones that came up were in /usr/lib

You're right, I'd typically never edit files in /usr. But I wasn't sure how else to do it at the time.

systemctl edit --full does what you want.

I wish package managers would make patching packages easy, this kind of thing is so much more manageable on Nix.

> it gets overwritten by package updates

This doesn't happen. The package manager installs the new configuration under a different name so that you do not lose your changes and can merge them easily.

what they are saying is that they edited the file in /usr/lib , which definitely would get overwritten. You're supossed to copy it into /etc/systemd/ for the appropriate service type.

I think you all proved the point that this system is too complicated for anyone outside of a small group of professional IT people.

Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers?

I have lost track how often that happened with sysvinit, because the "logic" how to treat customisations was usually handled by the package manager and they messed it up regularly.

systemd has a standard way to handle customisations. As long as you put everything you do in /etc/systemd/system, everything is fine. It's simple and works across distributions.

> Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers?

Traditionally, init scripts were installed into /etc but package managers (or at least some of them?) took/take care to not overwrite files under /etc but instead let you merge in the new changes.

It's complicated because it is complicated.

It's like saying a car is too complicated because I can't just swap the engine out without any prior knowledge. It's not designed for the average guy to be able to do that.

systemd is not some product meant for the average Joe, it's an integral part of the system for managing services and other things. To run a web server at least somewhat reliably you don't even need a lot of systemd knowledge but you still need to know some networking, firewalls, DNS, in general how the internet works, how to configure a web server and other services, some basic security. If you don't want to learn these things then there are managed services that you pay to do those things for you or you hire someone to run it for you. Just like you take your car to a mechanic when you're not interested in figuring out how to reassemble the engine.

Yeah, things can always be improved and made simpler but to create something fool-proof for the average person would take a huge amount of work and there would need to be a business opportunity there for someone to invest in that or there would need to be some passionate generous soul that would invest their time in a project like that.

And like I already mentioned, there are already solutions to the "it's too complicated" problem: 1) companies offering managed services, 2) companies/individuals for hire to do it for you.

Reply on news.ycombinator.com