Hi Eric, On Sun, Nov 13, 2011 at 4:54 PM, Eric Griffith <egriffith92@xxxxxxxxx> 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@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
