Tip regarding the "systemd[1]: Failed to start Journal Service" error

gay · 2013-01-22 04:32:39

Just a tip regarding the well-known

systemd[1]: Failed to start Journal Service

error (which I ran into last weekend) to maybe save one or two among you a couple of hours of your time:

The error is described here https://bbs.archlinux.org/viewtopic.php?id=151012 as well as in several other threads in other language boards / in other forums etc. It is usually (as in the linked thread) 'solved' by reinstalling the system - good old Windows magic, also useful when dealing with systemd.

The Problem with this error is that you do not get into your system. Instead, systemd will print you the mentioned "Failed to start Journal Service" error message a couple of million times. There are also no logs that you could retrieve (when booting from a livesystem) and that would give you any helpful hints, since journal is systemd's logging service, old-style system logs are not kept, and the dmesg log doesn't survive the reboot with default settings.

As pointed out in the above mentioned thread, you will see a few more instructive error messages when adding 'emergency' to the kernel line in the bootloader config.
Now there may be plenty of reasons why the systemd journal service might not work. The most common and most annoying, however, appears to be this one:
In this case you will see that the problem actually lies in

systemd[1]: Cannot open /etc/machine-id: No such file or directory

Now, 'man machine-id' reveals that "the /etc/machine-id file contains the unique machine id of the local system that is set during installation. (...) The machine ID is usually generated from a random source (...)". It is obviously perfectly justified to refuse to boot the system because an absolutely insignificant random number is missing. As far as systemd is concerned anyway.

Usually, it seems, the /etc/machine-id is set by /usr/bin/systemd-machine-id-setup during installation or system upgrade. It is not documented anywhere that this is a rather important step and that you should better check if this was or was not actually done before rebooting. Obviously (but for no apparent reasons) systemd fails to run this (or to run this successfully) sometimes.
Also to be recommended: Always retain (back up) your old kernel and initramfs and edit your bootloader config appropriately to be able to boot with your old kernel again ... just to have one or two options left to get back into the system in case of running into an unpleasant surprise from the side of systemd or other packages.

The solution is, obviously, to create this file /etc/machine-id ... You probably want to do that from a livesystem (if you want to try it from the emergency shell, you would need to remount / (i.e. root) as rw and hope that systemd will not punish you for that) by just running the program that was designed for creating this file manually: /usr/bin/systemd-machine-id-setup
http://permalink.gmane.org/gmane.comp.s … devel/7528 states that it might also work with merely creating the file 'touch /etc/machine-id'. Though I didn't try that since I had enough fun with systemd for one week and didn't want to break my system again just to see if that works.

Sevis · 2014-09-01 09:04:27

Sorry to post here as this is pretty old, I just ran into this problem, I'd just like to inform other persons that the method proposed by the author indeed works, and I believe this is the easy way to fix this
# touch /etc/machine-id
when chrooted into the arch root from a live cd

hokasch · 2014-09-01 13:42:52

This has been fixed in systemd 216-2, currently in testing. In case you are still hitting this, don't just "touch" the file, run what has been added in 216-2:

uuidgen | { read; echo "${REPLY//-}">/etc/machine-id; }

Last edited by hokasch (2014-09-01 15:16:43)

Leonid.I · 2014-09-01 18:13:14

hokasch wrote:

This has been fixed in systemd 216-2, currently in testing. In case you are still hitting this, don't just "touch" the file, run what has been added in 216-2:
uuidgen | { read; echo "${REPLY//-}">/etc/machine-id; }

Hmm, machine-id appears to be just a random md5sum-like string... So, just run md5sum(1) on any file. I wonder, why it has to be preserved in /etc instead of living in /run?

hokasch · 2014-09-01 18:20:49

I doubt the actual value is of importance at the moment, and even an empty file seems to work. I'd still just run what the packaging script would do regardless.
No idea what exactly systemd is doing with it, you would need to look up their docs.

ackalker · 2014-12-21 19:26:53

Sorry for necrobumping this.
Generating the machine-id in a consistent way is very important when working with KVM and containers, where the machine-id can be set for the VM or container. See `man systemd-machine-id-setup`.
Again, _don't_ just put some random UUID in there, especially not in the systemd package install script, this makes provisioning Arch Linux containers a PITA.

Last edited by ackalker (2014-12-21 19:30:26)

Jristz · 2014-12-22 03:48:36

ackalker wrote:

Sorry for necrobumping this.
Generating the machine-id in a consistent way is very important when working with KVM and containers, where the machine-id can be set for the VM or container. See `man systemd-machine-id-setup`.
Again, _don't_ just put some random UUID in there, especially not in the systemd package install script, this makes provisioning Arch Linux containers a PITA.

If you thing that the way that arch is handlynbg the machine-id is wrong or can be improved, then file a bug.

Anyway, I thing if reinstalling systemd package or if systemd have a command to reinitialize the machine-id file.

falconindy · 2014-12-22 14:37:19

Jristz wrote:

ackalker wrote:
Sorry for necrobumping this.
Generating the machine-id in a consistent way is very important when working with KVM and containers, where the machine-id can be set for the VM or container. See `man systemd-machine-id-setup`.
Again, _don't_ just put some random UUID in there, especially not in the systemd package install script, this makes provisioning Arch Linux containers a PITA.
If you thing that the way that arch is handlynbg the machine-id is wrong or can be improved, then file a bug.

He already did.

Jristz wrote:

Anyway, I thing if reinstalling systemd package or if systemd have a command to reinitialize the machine-id file.

Like so many of your posts, I had to read this a half dozen times before it made any sense. I think you're hinting at the utility that ackalker already pointed out in the post you're replying to. And, if you read the install scriptlet, you wouldn't need to think about whether or not reinstalling would be an option. You would know that it isn't.

Arch Linux

#1 2013-01-22 04:32:39

Tip regarding the "systemd[1]: Failed to start Journal Service" error

#2 2014-09-01 09:04:27

Re: Tip regarding the "systemd[1]: Failed to start Journal Service" error

#3 2014-09-01 13:42:52

Re: Tip regarding the "systemd[1]: Failed to start Journal Service" error

#4 2014-09-01 18:13:14

Re: Tip regarding the "systemd[1]: Failed to start Journal Service" error

#5 2014-09-01 18:20:49

Re: Tip regarding the "systemd[1]: Failed to start Journal Service" error

#6 2014-12-21 19:26:53

Re: Tip regarding the "systemd[1]: Failed to start Journal Service" error

#7 2014-12-22 03:48:36

Re: Tip regarding the "systemd[1]: Failed to start Journal Service" error

#8 2014-12-22 14:37:19

Re: Tip regarding the "systemd[1]: Failed to start Journal Service" error

Board footer