I just got the following entry on my boot up today:
systemd: Failed to start Create Volatile Files and Directories.
After a while of searching using my favorit searchengine, I (as usual
) found the most fitting solution in the bbs.archlinux.org
The solution is given in the manpage of the tmpfiles.d.
If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/tmpfiles.d/ bearing the same filename.
So all you have to do is:
cp journal-nocow.conf journal-nocow.conf.bak
ln -s /dev/null journal-nocow.conf
And thats it. Fingers crossed you system will boot without errors.
I was wondering why my system clock was "so damn wrong". A quick check with
systemctl status openntpd.service showed me "Active: inactive (dead) since ...". An other "journalctl -xfn" on the command line and "fatal: bad privsep dir /var/lib/ntp permissions: 40755" was marked red.
Searching on the web was, well, some kind of helpful. An old (asian?) entry was the highest in the ranking. After that, I searched on the official repository on github.com and found this patch (full patch view).
After that, it was an easy one to get openntpd back on track.
chown -R root /var/lib/ntp and to be on the save side
chmod -R 700 /var/lib/ntp followed by
systemctl restart openntpd.service and my clock was back on track .
So I'm having this problem on three machines. I've also done the advice "udevadm hwdb --update" but the error still exists on the next boot.
Good thing about it, all is still working. My machines have a "hwdb.bin" file in "/etc/udev/hwdb.bin". I found a bug report on the arch linux bug report list as well as one on the systemd bug report list but no solution.
I will update this entry when I've found a solution or if the error disappears on one of the upcomming updates.
Im freien magazin, Ausgabe 11/2012 bin ich über eine kleine und nette Erläuterung zum Thema systemd gestolpert.
Ein zentrales Konzept von systemd sind die Unit-Files, welche die Init-Skripte von anderen Systemen ersetzen und einfacher aufgebaut sind.
Es gibt verschiedene Arten von Unit Files, nachfolgend ein paar Beispiele:
.service____Typ für normale Dienste
.target____Zieltyp, dient z .B. als Ersatz für Runlevels (graphical.target), aber auch für Zwischenschritte (network.target, local-fs.target, …)
.mount____Typ für Mountpoints, meist automatisch durch systemd-fstab-generator erzeugt
.socket____Typ für Socket Activation von Diensten
Auf der Seite vom freien magazin gibt es auch Gegenüberstellungen von systemd skripte zu systeminitV skripten. Bei mir kam ein kleiner "ahh" Effekt .
Since i'm on it to migrate my fifth machine from systemV to systemd (with an delay of over one week per machine) and i've searched now the third time a the solution for the following step, i want to provide my results here.
I am using the archlinux migration howto (german) and i always struggle with the part "add >>init=/bin/systemd<< to the kernel line of your boot loader".
The debian wiki provides a description for this task when you are using grub2.
# $EDITOR /etc/default/grub
GRUBCMDLINELINUX_DEFAULT="quiet init=/lib/systemd/systemd" <--- Change this line
or (for arch linux)
grub-mkconfig -o /boot/grub/grub.cfg
So, you have migrated your arch linux to systemd and your beloved rc.local is not executed anymore? Time to jump into the systemd by writing your own unit. You have two options. One would be to write a unit that simple executes the rc.local. The second option would be to split up your rc.local into logical parts and write one unit per logical part (like "setup [w]lan, mount filesystems, start service xyz").
I want to provide you a way to implement the second solution. I can tell you, after you have written your first systemd unit, the concept of systemd won't be that big alien in you mind. I still have a tear drop in my eyes when i think back to my "only two files to configure my system"-systemV times, but thats nothing for this blog entry .
So lets go and write a systemd unit to start up your wlan interface by using wpa_supplicant and dhcpd.
We have to split this task into two steps. First we create the systemd service which determines when and how our real script should be handled. The second step includes writing of the script that contains the "real work".
First step - writing the systemd service
Description="something usefull in here"
#the service file is a wrapper. the real action is done in the on the following line (should be set with +x)
#two example targets below
#we only want to execute a script by the service - fire and forget - one shot only
#the following two lines define what should happen when the service is started or stopped
Second step - write the bashscript
case "$1" in
wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf
dhcpcd -b wlan0
dhcpd wlan0 --exit
Now, we only have to enable this service.
sudo systemctl enable wlan_wpa_supplicant.service
And thats it, try a reboot and enjoy your first systemd service
Example on github.com
Writing custom service files
A teammate at work asked me the question "how do you monitor your smart values from each device" and i could not answer him, since i do not monitor any smart values.
A quick research and now i am able to present him a good answer on Monday - even with some time to evaluate it .
Smartmontools is the tool you have to choose. On arch, it is done with pacman.
pacman -S smartmontools
A quick look on the official wiki and the arch wiki, i roughly created the following smartd.conf.
/dev/ -H -l error -l selftest -f -n standby,q -m [email protected]
The file can be found at "/etc/smartd.conf". Do not forget to remove/comment out the first "DEVICESCAN". The file is well documented, so it is an easy one (hopefully ).
All you have to do is to add the smartd to you autostart (e.g. rc.conf). If you are using systemd, the following line is doing the job.
sudo systemctl enable smartd.service
So you have a lot of deamons inside you rc.conf file and want/have to convert to systemd?
For Example your rc.conf contains the following DEAMONS.
DEAMONS=(crond sshd ntpd acpid network)
Use systemctl enable $foo.service like in the following way.
systemctl enable dhcpdeth0.service cronie.service acpid.service ntpd.service sshd.service