How to "load" a systemd Unit file?

English Applications
1

Came across something curious I hadn’t noticed before…

First, I found that “systemctl -a” doesn’t actually display “all” Units on the system - It only displays all “loaded” Unit files.

Objective:
Install ssh server on 13.1.

Procedure:
If needed, but most likely already installed

zypper in openssh

Now, how to start the service? I started looking for the Unit file…
The following does not return the Unit file

systemctl -a | grep ssh

But the following does

systemctl list-unit-files | grep ssh

You can’t enable much less start an unloaded Unit file, I couldn’t find a way to activate the ssh Unit file except by the following way…
Exhausting everything I could think of and not finding anything in documentation I read(I may have missed something), I invoked ssh the “old, SystemV” way…

# /etc/init.d/bin/ssh start

Which did the trick. Now you can view the running ssh service

systemctl status ssh

I’m sure there should be a way to “load” the ssh Unit file without a SystemV init start command, looking for the right command
BTW - I think it’s really cool how the openSUSE folks have made ssh server installation so quick and painless… automating tasks like server key generation and installation, and configuring the ssh config file to automatically support most likely desired features like X11 forwarding, binding to any/all network interfaces. Kudos to the people who did that.

TSU

2

Unit files are “loaded” on boot.
To make systemd rescan which ones are installed, run:

systemctl daemon-reload

But installing the “openssh” package should do that automatically.
It runs “systemctl daemon-reload” in the postinstall script, at least in the 13.1 package.

You can’t enable much less start an unloaded Unit file

No. And you cannot load it either.

Exhausting everything I could think of and not finding anything in documentation I read(I may have missed something), I invoked ssh the “old, SystemV” way…

# /etc/init.d/bin/ssh start

Which did the trick.

I doubt that.
Shouldn’t it rather be “/etc/init.d/sshd start”?
At least that’s where it is installed on my 13.1 system.
There is no /etc/init.d/bin/ssh .

Now you can view the running ssh service

systemctl status ssh

No. The service is called “sshd”, at least on my system.
This should show its status therefore:

systemctl status sshd

I’m sure there should be a way to “load” the ssh Unit file without a SystemV init start command, looking for the right command

If you want to start the ssh service, run:

systemctl start sshd

To enable starting it at boot:

systemctl enable sshd

Or just use YaST->System->Services Manager for all of that.

3

  1. Yes, the actual ssh init file is /etc/init.d/sshd

  2. No, apparently this is new to me that openSUSE does not necessarily load all installed Unit files on boot. And that’s the crux, up until now I thought that “systemctl -a” should list every Unit file on the system no matter the state… But after my discovery that it doesn’t I read the description of “systemctl -a” more closely and there in the "Help it clearly says that there can be a difference between “loaded” Unit files and Unit files simply on the system which I then described in my post (systemct list-unit-files).

The point is, by default the sshd Unit file exists on the system but is “unloaded” so you <cannot> “systemctl start” or “systemctl enable” the Unit file. And, you can reboot the system all you want but by default it will not “load.”

Not believing what I was looking at first, I then inspected and verified this on 4 existing VM guests I’ve built over time and this exists on all of them.

TSU

4

The actual relevant service is sshd.service, and doing

rpm -ql openssh

would have listed the corresponding service file

/usr/lib/systemd/system/sshd.service

with the status being reported by

systemctl status sshd

Well it’s the service that you should be interested in, and the full list can be got from

systemctl list-unit-files

The point is, by default the sshd Unit file exists on the system but is “unloaded” so you <cannot> “systemctl start” or “systemctl enable” the Unit file. And, you can reboot the system all you want but by default it will not “load.”

Why are you surprised about that? Again, it’s the (systemd) service that you want to enable - in this case ‘sshd.service’.

5

And in addition:
“systemctl -a” does show the sshd.service: (at least on my 13.1 system :wink: )

# systemctl -a |grep ssh
sshd.service                   loaded active   running   OpenSSH Daemon

If you still think your sshd.service is not loaded, please post the output of:

systemctl status sshd
6

If you run “systemctl status sshd.service” in the exact order you describe, you will see the error
“Unit file not found”

As I’m describing, the Unit file has to be loaded before you can execute any systemd commands against it.

I encourage anyone to verify for yourself what I’ve described…
If anyone is running virtualization and has a ton of little used specific purpose openSUSE Guests created over time like I do, you can verify all this in a few minutes, every one will exhibit what I described.

Otherwise, unless your current physical machine hasn’t had the ssh service started before you won’t be able to see this on your current machine.

TSU

7

Only if your system has run the sshd service sometime in the past.
Can you say you are sure you’ve <never> run the sshd service before, ever?

TSU

8

No:

:~> systemctl status sshd.service
sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Fre 2014-08-22 10:08:59 CEST; 6h ago
 Main PID: 935 (sshd)
   CGroup: /system.slice/sshd.service
           └─935 /usr/sbin/sshd -D

And I never loaded anything manually.

As I’m describing, the Unit file has to be loaded before you can execute any systemd commands against it.

Again, it is loaded on boot.

And also again, if it’s different for you, please post the actual output of “systemctl status sshd.service” to prove it and so that people are able to help you.

9

No, of course not. It is enabled here, so it is started (not “run”) automatically during boot.

But how could I have ever enabled it, if it has to be “loaded” or “run” first as you claim. I never did that. And yes, I am sure about that.

(PS: no, you do not “run” service files… :wink: )

And another time: where’s your output of “systemctl status sshd.service”?

10

Ok,
Figured out the likely issue, my User error.

I was trying to get the status of “ssh” instead of “sshd”
Still, am a bit mystified that the followed doesn’t return a result until the sshd is run at least once

systemctl -a | grep ssh

The above of course should have returned any “ssh” and “sshd” results, but returns nothing at first.
After running at least once, then it returns the ssd.service

TSU

11

Well we did refer to sshd several times :slight_smile:

Still, am a bit mystified that the followed doesn’t return a result until the sshd is run at least once

systemctl -a | grep ssh

Well it should - if it is loaded, and only if it is loaded


# systemctl status sshd
sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled)
   Active: inactive (dead)

linux-bbgi:~ # systemctl start sshd
linux-bbgi:~ # systemctl status sshd
sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled)
   Active: active (running) since Sat 2014-08-23 10:04:49 NZST; 1s ago
  Process: 8986 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
 Main PID: 8989 (sshd)
   CGroup: /system.slice/sshd.service
           └─8989 /usr/sbin/sshd -D

Aug 23 10:04:49 linux-bbgi.site systemd[1]: Starting OpenSSH Daemon...
Aug 23 10:04:49 linux-bbgi.site systemd[1]: Started OpenSSH Daemon.
Aug 23 10:04:49 linux-bbgi.site sshd[8989]: Server listening on 0.0.0.0 port 22.
Aug 23 10:04:49 linux-bbgi.site sshd[8989]: Server listening on :: port 22.
linux-bbgi:~ # systemctl -a |grep ssh
sshd.service                                                                                                                                                                        loaded active   running   OpenSSH Daemon
linux-bbgi:~ # systemctl stop sshd
linux-bbgi:~ # systemctl -a |grep ssh
linux-bbgi:~ #

All as expected.

12

Somehow I expected this… :wink:

Still, am a bit mystified that the followed doesn’t return a result until the sshd is run at least once

systemctl -a | grep ssh

The above of course should have returned any “ssh” and “sshd” results, but returns nothing at first.

After running at least once, then it returns the ssd.service

Well, it wouldn’t return “ssd.service” in any case. :wink:
I suppose that was just a typo in your post though.

You are right that “systemctl -a” doesn’t show sshd.service when it is not active, i.e. after you stop it e.g. (it doesn’t matter whether it was “running” before), although it should.
“man systemctl” clearly states:

       **-a, --all
**           When listing units, show all loaded units, regardless of their state,
          including inactive units. When showing unit/job/manager properties,
           show all properties regardless whether they are set or not.

And sshd.service should be loaded in any case, if it is installed correctly. Your “systemctl status” output should indicate that it is in fact loaded.

That it is not shown when it is not active/running, seems to be caused by the fact that openSUSE’s package still includes a sysvinit script as well (/etc/init.d/sshd).
If I remove that and run “systemctl daemon-reload”, “systemctl -a” does correctly show sshd.service:

# systemctl -a |grep ssh
sshd.service
     loaded inactive dead      OpenSSH Daemon

Still, you can start/enable it even if it is not listed by “systemctl -a”.

Well, not quite.
As you can see, it is in fact loaded, so it should be shown (according to your own statement). And it is indeed shown if you remove /etc/init.d/sshd.
Seems to be a bug/shortcoming in the legacy support, if both a systemd unit and a sysvinit script are present.
I have to admit that I didn’t notice that before either, as I do have sshd.service enabled.

13

Well, not quite.
As you can see, it is in fact loaded, so it should be shown (according to your own statement).

I generally only ever use ‘systemctl status <service-name>’, so haven’t paid much attention to ‘systemctl --all’.

And it is indeed shown if you remove /etc/init.d/sshd.

Actually, I still have that file, but after ‘system reload-daemon’ I now get it correctly reported if the service is enabled but stopped

# systemctl start sshd
linux-bbgi:~ # systemctl --all|grep ssh
sshd.service                                                                                                                                                                        loaded active   running   OpenSSH Daemon
linux-bbgi:~ # systemctl stop sshd
linux-bbgi:~ # systemctl --all|grep ssh
sshd.service                                                                                                                                                                        loaded inactive dead      OpenSSH Daemon

and it is still reporting correctly after a reboot. If disable it of course, then is not reported (as expected).

Seems to be a bug/shortcoming in the legacy support, if both a systemd unit and a sysvinit script are present.
I have to admit that I didn’t notice that before either, as I do have sshd.service enabled. Yesterday, 10:10

Perhaps, but a minor one. :slight_smile:

14

Yeah. Me too/neither.

Actually, I still have that file, but after ‘system reload-daemon’ I now get it correctly reported if the service is enabled but stopped

Right. I noticed after posting that removing the file did not help at all actually. It apparently was the “systemctl daemon-reload” that made it appear.

If disable it of course, then is not reported (as expected).

Well, according to the documentation, I would expect it to be shown even if it is disabled.
But you’re right, other disabled units seem to be not shown as well.

Perhaps, but a minor one. :slight_smile:

I agree.