Systemd systemctl edit command SysVInit alternative?

[0x6A7232]

So, I need to do sudo systemctl edit libvirtd this (copied to the end, below for convenience):

But when I do I get

Code: Select all

$ sudo systemctl edit libvirtd
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

Is there any simple way around this without just giving up on MX's penchant for SysVInit and setting Systemd as the default in MX Boot Options?? Trying to look up alternatives to systemctl edit and all I get is years old guides for switching TO systemd FROM Init. At this point I might as well just throw in the towel as nothing seems to work right on SysV without workarounds that don't always work 100% of the time (installations that manage to bork the compatibility symlinks, or programs that detect that systemd isn't running and throw a tantrum, refusing to run).

I'm running Arch Linux and have been running into trouble trying to use QEMU/KVM on

Code: Select all

virt-manager

, and this problem is likely to address my issues while using the similar

Code: Select all

gnome-boxes

.

Resolution

This error was related to the driver opencl-amdgpu-pro-orca. This answer details some background of what causes the error. Here's how I went about resolving the problem:

1. Run

Code: Select all

sudo systemctl edit libvirtd

, which opens Nano.

• That command creates a temporary file which will save to become

  Code: Select all

  override.conf

  within the directory of the

  Code: Select all

  libvirtd

  service.

2. Enter the following into this (empty in my case) file:

Code: Select all

[Service]
Environment="LD_LIBRARY_PATH=/usr/lib"

3. Restart

Code: Select all

libvirtd

with

Code: Select all

sudo systemctl restart libvirtd

.
4. Open

Code: Select all

virt-manager

. The error should not be present.

• It's worth noting that I did not need to reboot following these changes.

[DukeComposed]

At this point I might as well just throw in the towel as nothing seems to work right on SysV without workarounds that don't always work 100% of the time

Funny, I'd say the same thing about systemd.

That command creates a temporary file which will save to become

Code: Select all

override.conf

within the directory of the

Code: Select all

libvirtd

service.

Maybe I'm misunderstanding something, but what you're describing here are the basic steps of opening a text file and editing it. Is this really something you need your init system to do for you? Admittedly, systemd isn't just an init system anymore but a large, complex, and poorly-coded Gordian knot of interdependent libraries and bespoke tools. If you're complaining that editing files is broken under sysvinit, I have to wonder why you're using systemctl at all just to invoke a text editor.

I think you can specify kernel options in MX Boot Options if you want to stick to systemd full-time. There's also a systemd-only MX Linux respin that makes this step unnecessary.

[dolphin_oracle]

under sysV, the /etc/init.d/libvirtd init script is what you want to edit. just use any text editor. sysV does not use the systemd service files anyway.

the main kicker, is you can't use systemctl commands under sysV.

[0x6A7232]

At this point I might as well just throw in the towel as nothing seems to work right on SysV without workarounds that don't always work 100% of the time

Funny, I'd say the same thing about systemd.

That command creates a temporary file which will save to become

Code: Select all

override.conf

within the directory of the

Code: Select all

libvirtd

service.

Maybe I'm misunderstanding something, but what you're describing here are the basic steps of opening a text file and editing it. Is this really something you need your init system to do for you? Admittedly, systemd isn't just an init system anymore but a large, complex, and poorly-coded Gordian knot of interdependent libraries and bespoke tools. If you're complaining that editing files is broken under sysvinit, I have to wonder why you're using systemctl at all just to invoke a text editor.

I think you can specify kernel options in MX Boot Options if you want to stick to systemd full-time. There's also a systemd-only MX Linux respin that makes this step unnecessary.

The issue is that the text file does not exist and must be created. Where is it supposed to be? In the directory of the libvirtd service. Oh, but I'm not really using systemd, now am I? So I'd much prefer to use a command to put it where it needs to go without me stabbing in the dark.

Unfortunately as was pointed out, you can't use systemctl commands.

I don't mind using SysV but for whatever reason everyone is going full exclusive systemd (which is very odd given how you have 5 different install instructions for if you're using Debian based, Fedora, Arch based, etc etc etc).

Regardless, for now I'll probably just boot systemd and run the systemctl command. After that I might go back, idk. I did make a thread about systemd and sysv here

[DukeComposed]

The issue is that the text file does not exist and must be created. Where is it supposed to be? In the directory of the libvirtd service. Oh, but I'm not really using systemd, now am I? So I'd much prefer to use a command to put it where it needs to go without me stabbing in the dark.

Then don't stab in the dark. If you want to run a foo service, you should, at the very least, read the foo documentation and learn how the basic control features of that software work. Every service will be different. This is not a bug, this is hundreds and thousands of developers building different software over several decades to do different things for different purposes.

It's fine to have your tools do the work for you. It's dangerous to fall into the trap of letting your tools do your thinking for you.

I don't mind using SysV but for whatever reason everyone is going full exclusive systemd (which is very odd given how you have 5 different install instructions for if you're using Debian based, Fedora, Arch based, etc etc etc).

No, everyone is not going full exclusive systemd. I think the maintainers of Gentoo, Void, Slackware, Artix, Devuan, antiX, MX, CRUX, Alpine, many more, as well as illumos, smartOS, openIndiana, and the dev teams of every BSD distro would beg to differ. You seem to me very quick to want to ignore fifty years of history and lessons learned building the foundational principles of system administration and sweep it all under the rug in favor of having systemctl do everything for you.

Knowing where services live on a Debian-based machine is a very basic principle and something you should learn regardless of which init system you pick. There are just basic ideas to running a UNIX-like machine you need to know if you want to start customizing it. You owe it to yourself to learn what /etc looks like, what lives under /usr/share, and what the service and update-rc.d commands do. Is this all more work than running systemctl something? Maybe. Fedora works differently than Debian does. So does SUSE. You might even want to get a job doing this kind of thing for money some day. It helps to understand what machines do, how they do them, and why they do things they way they do.

Regardless, for now I'll probably just boot systemd and run the systemctl command. After that I might go back, idk.

And you're welcome to do so. I recommend you switch to the systemd-only respin for convenience. I just wonder what you're going to do when there isn't a systemctl command to fix everything and you actually have to start learning how your software works in order to solve the problem. I promise you, systemd will bite you one day, as it does everyone, and I hope you'll know what to do when that happens.

[pbear]

What a bunch of FUD. Anyhoo, @0x6A7232, consistent with your comment in the other thread, if you want to use systemd, there's a lot to be said for running a distro which supports it. Debian is very good, provided you're comfortable with CLI for system management. If you want GUI system apps, take a look at LMDE (Mint's Debian derivative, as distinguished from its main edition, which is based on Ubuntu). And there are others.

[asqwerth]

@pbear

I think the OP's point/questions in the other thread are:
- "why can't I use systemctl commands in sysvinit?" and

- "why can't MX make some tool so that when people apply systemctl commands they find on the internet , it will work in sysvinit?"

It would appear they were hoping to stick to Sysvinit but also wonder why they can't use 'systemctl edit' as the command to edit sysv service scripts. Hmm.


It's like if you are running Arch, you don't go "why can't I use sudo apt full-upgrade to update my Arch system?" [NB. I've seen such posts in Manjaro forum!] because it's a totally different package manager that doesn't use the apt commands.

[manyroads]

FWIW. Incompatibility will always be an issue. There are simply too many moving parts, people's style preferences vary greatly, skill levels are incredibly uneven across the computing world. It has been thus during my entire 50+ year computing experience(s).

My recommendation is always to try and find a viable solution that works for you. By all means hunt for solutions & options. Do not worry when you have do perform some special work in order to get your system to work, as you prefer. That all should be part of the fun & the journey.

Back under my rock, I go....

[0x6A7232]

Le sigh.

Linux distro help: We will never allow you to be a successful power user without becoming a full-on Unix guru on the equivalent of a Windows power user that can modify their own driver installation files and hand edit the registry entries involved with a text editor. Learn to code, scrub!!

Also Linux: Why no year of the Linux desktop?

A gross oversimplification, I know. And I do appreciate the time and input given, it's just I don't want to spend hours and hours learning the minutia of a system that I'm not going to be delving very often (as I will therefore forget it and it will be a waste of time as I'd have to re-learn it every 3-5 years - same reason I never got around to learning how to modify Windows driver files to fix OEM incompatibility with hardware that should work but doesn't because it was re-branded, it's a pain right in the butt and you'll just have to re-learn it in a few years when you re-install your system.. I think I did manage to do it, once, by splicing some entries from one driver inf to the other, for a Creative Sound Blaster Live or similar, what a headache that was).

And you know... I simply gave up and didn't use the service; project is abandoned for now. Thanks again to all for the input.