Skip to content

systemd[1]: Failed to start Create Volatile Files and Directories. - on Arch Linux having zfsonlinux as root

I just got the following entry on my boot up today:

systemd[1]: 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
The solution is given in the manpage of the tmpfiles.d.
tmpfiles.d(5) wrote:

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:

sudo su

cd /usr/lib/tmpfiles.d

cp journal-nocow.conf journal-nocow.conf.bak

rm journal-nocow.conf.bak

ln -s /dev/null journal-nocow.conf

And thats it. Fingers crossed you system will boot without errors.

Translate to de es fr it pt ja

openntpd fatal: bad privsep dir /var/lib/ntp permissions: (on arch linux)

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 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 :-).

Translate to de es fr it pt ja

"hwdb.bin does not exist" on arch linux boot up

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.

Translate to de es fr it pt ja

web - systemd und das unit files konzept

Im freien magazin, Ausgabe 11/2012 bin ich über eine kleine und nette Erläuterung zum Thema systemd gestolpert.

Unit Files Ein zentrales Konzept von systemd sind die Unit-Files, welche die Init-Skripte von anderen Systemen ersetzen und einfacher aufgebaut sind. Unit Typen Es gibt verschiedene Arten von Unit Files, nachfolgend ein paar Beispiele: Unit Files Dienste____Typen .service____Typ für normale Dienste .target____Zieltyp, dient z .B. als Ersatz für Runlevels (, aber auch für Zwischenschritte (,, …) .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 :-).

Translate to de es fr it pt ja

howto - migrate systemV to systemd - adapting grub2

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

Translate to de es fr it pt ja

howto - arch linux migrate rc.local to systemd unit (wpa_supplicant based wlan)

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

vim lib/systemd/system/wlan_wpa_supplicant.service
[Unit] 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) ConditionPathExists=/my/path/to/the/execute/script #two example targets below [Service] #we only want to execute a script by the service - fire and forget - one shot only ;-) Type=oneshot RemainAfterExit=yes KillMode=none #the following two lines define what should happen when the service is started or stopped ExecStart=/my/path/to/the/execute/script start ExecStop=/my/path/to/the/execute/script stop [Install]
Second step - write the bashscript
vim /etc/wlan_wpa_supplicant_service
#!/bin/bash case "$1" in "start") wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf sleep 3 dhcpcd -b wlan0 ;; "stop") dhcpd wlan0 --exit ;; esac exit 0
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 :-).

Links Example on Writing custom service files man systemd.service

Translate to de es fr it pt ja

Smartmontools - monitore hdd S.M.A.R.T. values via cron

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 :-D.

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

Translate to de es fr it pt ja

howto - arch linux convert rc.conf DEAMONS to systemd

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

Translate to de es fr it pt ja