systemd recap++ (part 1 of 3) make it go

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Ed
Date:  
To: PLUG Discussion List
Subject: systemd recap++ (part 1 of 3) make it go
This is just to review some of the news about systemd now that Debian
will join those using systemd. systemd is Linux kernel centric and
will not be feature complete on all Debian platforms - not a deal
breaker, just be aware. These email are meant as a kickstart to
systemd (service init, sevice debug and journal) for more in depth
info I recommend: the 20 blog series "systemd for Administrators"
starting with [1] and collected at [2], the man pages, and these two
articles on LWN.net from a maintainers perspective [3][4]. It can be
helpful to see how the upstream looks at systemd.

Let's start with systemd. The news story was that a common usage
pattern was becoming easier to use, but that meant "non-standard"
deployments could be fumbled. For example, if you wanted to start the
Fedora Directory Server, known as 389-ds to people and as dirsrv to
systemd, you would install it from your distributions repository (yum
apt dnf[5] zephyr) and then start the app by calling its "unit":

systemctl start dirsrv.target

go check that 389 is working; If so, enable it to start on boot, using
the new "easier" notation:

systemctl enable dirsrv

Well that failed (be happy), because the new systemctl default is to
append ".service" to units lacking suffixes. (ie you tried to enabled
dirsrv.service which isn't even a part of 389)

There may be other services out there that have both foo.target and
foo.service, and you could get something that was just half started
(be not happy). Target units are how systemd aggregates multiple other
units, for example dirsrv.target launches the admin web site as well
as your 389-ds databases. So for dirsrv you need to do it old school:

systemctl enable dirsrv.target

You should now be able to start/stop/enable/disable services as
needed, to see a nice little Haiku about the unit, try:

systemctl status dirsrv.target

there! a nice little Haiku of systemd log info:

dirsrv.target - 389 Directory Server
Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; enabled)
Active: active since Sat 2014-03-15 12:19:04 MST; 5h 38min ago

Mar 15 12:19:04 example.com systemd[1]: Starting 389 Directory Server.
Mar 15 12:19:04 example.com systemd[1]: Reached target 389 Directory Server.

go to see more 389 goodness at http://example.com:9830
The next email will look at the simple way of customizing a unit.....

[1] http://0pointer.de/blog/projects/systemd.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
[3] http://lwn.net/Articles/584175/
[4] http://lwn.net/Articles/584176/
[5] http://dnf.baseurl.org/ - F20 users are already using it, they
just weren't told...

ps. if you realy want to disable a unit, link
/etc/systemd/system/name_of_the_damned.service to /dev/null (ln -s
/dev/null /et... ) it's official and systemd will get the hint.
---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss