The Fedora GNOME 3.0 Live CD is made of awesome. Not just because it showcases the awesomeness that is GNOME 3, but also because it's built on an awesome systemd-based OS. Double awesome!
So, get it, play with it. It's the future of computing: GNOME and systemd and Linux. Triple awesome!
And did I mention that F15 is going the awesomest OS release ever?
Nope, there's no April 1st joke in here. It's really honestly just ... awesome!
Citizens! GNOMErs! Only two days are left and the GUADEC/Desktop Summit CFP is over (end date is Friday). Submit your presentation proposal now, or it is too late. Read the CFP.
Oh, and regarding the need for a KDE identity account: due to limited manpower we decided to reuse existing infrastucture instead of setting up a completely new one. We do acknowledge that this is not ideal and we'd like to ask for your understanding. (Creating a KDE identity account is unrestricted, and you can easily create one even if you never had anything to do with KDE in your life.)
Note that we are looking for both lightning talks and full-length presentations. If you are interested in doing a lightning talk (and we can only encourage you to), please use the same form to make your submission.
I'd like to remind everybody that only one week is left until the Desktop Summit (aka GUADEC 2011) Call for Participation ends. We want your talk proposals, and that quickly, before it's too late!
Berlin in summer is fantastic. You wouldn't want to miss that, would you?
So, read the CFP again, and then submit something.
The CFP ends next friday. So hurry!
Thank you,
Lennart
It has been a while since the last installment of my systemd for Administrators series, but now with the release of Fedora 15 based on systemd looming, here's a new episode:
In systemd, there are three levels of turning off a service (or other unit). Let's have a look which those are:
You can stop a service. That simply terminates the running instance of the service and does little else. If due to some form of activation (such as manual activation, socket activation, bus activation, activation by system boot or activation by hardware plug) the service is requested again afterwards it will be started. Stopping a service is hence a very simple, temporary and superficial operation. Here's an example how to do this for the NTP service:
$ systemctl stop ntpd.service
This is roughly equivalent to the following traditional command which is available on most SysV inspired systems:
$ service ntpd stop
In fact, on Fedora 15, if you execute the latter command it will be transparently converted to the former.
You can disable a service. This unhooks a service from its activation triggers. That means, that depending on your service it will no longer be activated on boot, by socket or bus activation or by hardware plug (or any other trigger that applies to it). However, you can still start it manually if you wish. If there is already a started instance disabling a service will not have the effect of stopping it. Here's an example how to disable a service:
$ systemctl disable ntpd.service
On traditional Fedora systems, this is roughly equivalent to the following command:
$ chkconfig ntpd off
And here too, on Fedora 15, the latter command will be transparently converted to the former, if necessary.
Often you want to combine stopping and disabling a service, to get rid of the current instance and make sure it is not started again (except when manually triggered):
$ systemctl disable ntpd.service $ systemctl stop ntpd.service
Commands like this are for example used during package deinstallation of systemd services on Fedora.
Disabling a service is a permanent change; until you undo it it will be kept, even across reboots.
You can mask a service. This is like disabling a service, but on steroids. It not only makes sure that service is not started automatically anymore, but even ensures that a service cannot even be started manually anymore. This is a bit of a hidden feature in systemd, since it is not commonly useful and might be confusing the user. But here's how you do it:
$ ln -s /dev/null /etc/systemd/system/ntpd.service $ systemctl daemon-reload
By symlinking a service file to /dev/null you tell systemd to never start the service in question and completely block its execution. Unit files stored in /etc/systemd/system override those from /lib/systemd/system that carry the same name. The former directory is administrator territory, the latter terroritory of your package manager. By installing your symlink in /etc/systemd/system/ntpd.service you hence make sure that systemd will never read the upstream shipped service file /lib/systemd/system/ntpd.service.
systemd will recognize units symlinked to /dev/null and show them as masked. If you try to start such a service manually (via systemctl start for example) this will fail with an error.
A similar trick on SysV systems does not (officially) exist. However, there are a few unofficial hacks, such as editing the init script and placing an exit 0 at the top, or removing its execution bit. However, these solutions have various drawbacks, for example they interfere with the package manager.
Masking a service is a permanent change, much like disabling a service.
Now that we learned how to turn off services on three levels, there's only one question left: how do we turn them on again? Well, it's quite symmetric. use systemctl start to undo systemctl stop. Use systemctl enable to undo systemctl disable and use rm to undo ln.
And that's all for now. Thank you for your attention!
In case you haven't noticed yet: the Call For Participation for the Desktop Summit 2011 (aka GUADEC 2011, aka Akademy 2011) in Berlin, Germany is open since yesterday. Submissions will be accepted until March 25th, so make sure to submit your proposals quickly.
If you have already watched my presentation on systemd I gave at linux.conf.au 2011 then this video of my talk on the same topic which I have gave at FOSDEM 2011 in Brussels, Belgium will probably not be all new to you, but the questions from the audience (and hopefully my responses) might answer a question or two you might still have. So do watch it:
Hmm, seems p.g.o strips the video from the blog post. So either read the original blog story or watch it directly on YouTube.
Oh, and FOSDEM rocked, like every year!
I won't spare you the video of my talk about systemd at linux.conf.au 2011 in Brisbane, Australia last week:
Hmm, seems p.g.o strips the video from the blog post. So either read the original blog story or watch it directly on blip.tv.
LCA was fantastic and especially impressive given the circumstances of the recent floodings in Queensland. Really good conference, and congratulations to the organizers!
The FOSDEM organizers just published a brief interview with yours truly regarding the presentation about systemd I will be giving there on Sat. Feb. 5th, 3pm. If you come to Brussels make sure to drop by! And even if you don't have a look on the interview!
If you don't make it to Brussels, there are two more stops in my little systemd World Tour in the next weeks: today (Wed. Jan. 26th, 2:30pm) I will be speaking at linux.conf.au in Brisbane, Australia. And on Fri. Feb. 11th, 1:20pm I'll be speaking at the Red Hat Developer Conference in Brno, Czech Republic.
Chorin Abbey Church, Brandenburg, Germany. Yes, indeed, that's a crane.
Here's the fourth installment of my ongoing series about systemd for administrators.
Killing a system daemon is easy, right? Or is it?
Sure, as long as your daemon persists only of a single process this might actually be somewhat true. You type killall rsyslogd and the syslog daemon is gone. However it is a bit dirty to do it like that given that this will kill all processes which happen to be called like this, including those an unlucky user might have named that way by accident. A slightly more correct version would be to read the .pid file, i.e. kill `cat /var/run/syslogd.pid`. That already gets us much further, but still, is this really what we want?
More often than not it actually isn't. Consider a service like Apache, or crond, or atd, which as part of their usual operation spawn child processes. Arbitrary, user configurable child processes, such as cron or at jobs, or CGI scripts, even full application servers. If you kill the main apache/crond/atd process this might or might not pull down the child processes too, and it's up to those processes whether they want to stay around or go down as well. Basically that means that terminating Apache might very well cause its CGI scripts to stay around, reassigned to be children of init, and difficult to track down.
systemd to the rescue: With systemctl kill you can easily send a signal to all processes of a service. Example:
# systemctl kill crond.service
This will ensure that SIGTERM is delivered to all processes of the crond service, not just the main process. Of course, you can also send a different signal if you wish. For example, if you are bad-ass you might want to go for SIGKILL right-away:
# systemctl kill -s SIGKILL crond.service
And there you go, the service will be brutally slaughtered in its entirety, regardless how many times it forked, whether it tried to escape supervision by double forking or fork bombing.
Sometimes all you need is to send a specific signal to the main process of a service, maybe because you want to trigger a reload via SIGHUP. Instead of going via the PID file, here's an easier way to do this:
# systemctl kill -s HUP --kill-who=main crond.service
So again, what is so new and fancy about killing services in systemd? Well, for the first time on Linux we can actually properly do that. Previous solutions were always depending on the daemons to actually cooperate to bring down everything they spawned if they themselves terminate. However, usually if you want to use SIGTERM or SIGKILL you are doing that because they actually do not cooperate properly with you.
How does this relate to systemctl stop? kill goes directly and sends a signal to every process in the group, however stop goes through the official configured way to shut down a service, i.e. invokes the stop command configured with ExecStop= in the service file. Usually stop should be sufficient. kill is the tougher version, for cases where you either don't want the official shutdown command of a service to run, or when the service is hosed and hung in other ways.
(It's up to you BTW to specify signal names with or without the SIG prefix on the -s switch. Both works.)
It's a bit surprising that we have come so far on Linux without even being able to properly kill services. systemd for the first time enables you to do this properly.