[arch-general] Systemd Questions / Problem

[Tom Gundersen]

Hi Eric,

On Sun, Nov 13, 2011 at 4:54 PM, Eric Griffith <egriffith92 at gmail.com> wrote:
> Hey everyone, I've been reading up on Systemd lately, trying it out in
> a VM just to see how the setup and everything and I've run into 1
> problem, along with a few questions about it.

For anyone interested in systemd, I can strongly recommend starting
with "man systemd" and the related manpages (found here:
<http://0pointer.de/public/systemd-man/>), and Lennart's blog stories
about the subject (found here: <http://0pointer.de/blog/projects/>,
look for "systemd for Administrators, Part *").

The amount of documentation can be a bit daunting, so feel free to ask
as well :-)

> The main question I have about it related to its "On Demand Loading"
> of daemons. What exactly does this mean in a desktop or server
> environment? Such as, if my desktop is just sitting there, no
> configuration done beyond just installing openssh, and I'm at my
> laptop and I tell it ssh root at desktop. Will systemd automatically spot
> the incoming ssh connection, since its watching the ssh socket, and
> start sshd, and then stop it again when I close the connection? Or
> would I still need to issue "systemctl enable sshd.service" so that
> sshd is permanently enabled after a reboot?

Assuming you use systemd-arch-units from [community], you can do either.

If you have a server where you expect a lot of simultaneous incoming
ssh connections, it probably makes sense (in order to save resources)
to use the old fashioned service, i.e. "systemctl enable
sshd.service", which will then be started on boot.

However, if you only expect the occasional connection (which I take it
is your case), you probably want to use the socket activated service.
You enable this by doing "systemctl enable sshd.socket" and systemd
will then listen for incoming ssh connections on the next reboot and
start one sshd instance for each incoming connection.

Regarding shutting down the socket activated instance: this is not
systemd's business, but in the case of sshd the instance will shut
itself down when you disconnect.

To learn more about how systemd treats sshd in particular and other
inetd-style services in general you could have a look at:
<http://0pointer.de/blog/projects/inetd.html>.

> Related to the above; whats the difference between 'enabled' and
> 'started' / 'active.' following a reboot?

'enabled' means that the service should be started if the conditions
for starting it are satisfied (e.g. some other service, or ultimately
by graphical.target (or multi-user.target) Requires or Wants it, or
someone accessed a socket it was listening to, or it was started in
one of the many other ways it could be started). To turn it on its
head, if a service is 'disabled' it will never be started by systemd.

If a service is 'active' it means the daemon is running (or something
to that effect, depending on what kind of service you have).

To learn more about the different levels of activation you could have
a look at: <http://0pointer.de/blog/projects/three-levels-of-off>
(good info on this is also found in "man systemd").

> The reason I ask is because
> after I got systemd setup in the VM, and enabled network.service, i
> rebooted. When I got back into the VM, i tried to ping google, and it
> wouldn't go through. I checked the status of network.service, it said
> it was enabled, but "started (inactive),"  So i'm confused. If its
> enabled, and started...why was it inactive?

This means that the service was started, but then it exited (cleanly).
This is almost certainly a bug in network.service. Are all your
packages up-to-date? I know there was a problem like this with a past
version of network.service. Please open a bug report against
systemd-arch-units, and attach the output of "systemctl show
network.service" and "systemctl status network.service".

Until this is fixed, I can recommend using NetworkManager, as that
comes with systemd support out of the box, and works very well.

> If we assume for a second
> that systemd temporarily killed the network because nothing was being
> done with it, then why didnt systemd restart it when it caught
> activity on the network from me issuing the ping command?

systemd does not kill / shutdown services due to inactivity. The
assumption is that inactive services will do no harm, just rest
peacefully in ram, and it would take more resources to kill them than
to do nothing. What you are seeing is almost certainly a bug in the
network service ("git blame" tells us that yours truly is mostly
responsible for any malfunction). A service can be configured to shut
itself down if all the services that wants/requires it are shut down,
but that would not apply in this case.

> The problem I'm having is after sym-linking
> /etc/systemd/system/default.target to
> /lib/systemd/system/graphical.target, when I reboot I get dropped into
> a rescue shell saying:
>
> "Failed to issue method call: Unit graphical.target is masked."
>
> Anyone able to translate that?

This that graphical.target is masked means that graphical.target is a
symlink to /dev/null, or that it is an empty file. Sounds weird...
Have a look at the file to see that it is correct, and that the
symlink was created correctly. As to the word "masked" have a look at
the link I posted above
(http://0pointer.de/blog/projects/three-levels-of-off).

Cheers,

Tom