[conspire] Failed to start

[Rick Moen]

Quoting Paul Zander (paulz at ieee.org):

> While my Debian system was starting up, I happened to look at the messages scrolling by; one caught my attention. 
> 
> Looking through /var/logs/syslog, I found a similar message:
> 
>     systemd[1]: Failed to start Create Volatile Files and Directories.
> 
> Is this something I should be concerned about?


As you know (but I'll mention this only in passing to account for why 
I'm researching this from scratch, and why I'm in no position to 
examine similar software on a system of my own), I've tended to actively
avoid systemd.  That having been said:

In looking up the initial error, the obvious first question is what
volatile files and directories.  Which logically should then both let
you do manual checking and guesstimate whether you should be worried.

Seems like a relevant Debian man page:
https://manpages.debian.org/stretch/systemd/systemd-tmpfiles.8.en.html

  [...]
  systemd-tmpfiles creates, deletes, and cleans up volatile and
  temporary files and directories, based on the configuration file format
  and location specified in tmpfiles.d(5)
  [...]

In turn, the man page for _that_ (in man chapter 5 that covers system
configuration files):
https://manpages.debian.org/stretch/systemd/tmpfiles.d.5.en.html

  NAME
  tmpfiles.d - Configuration for creation, deletion and cleaning of
  volatile and temporary files

  SYNOPSIS
  /etc/tmpfiles.d/*.conf
  /run/tmpfiles.d/*.conf
  /usr/lib/tmpfiles.d/*.conf

(So, checking those conf file contents will tell you what tmp-type 
files and directories are intended to be managed by the cited systemd
service.)

  DESCRIPTION
  systemd-tmpfiles uses the configuration files from the above directories
  to describe the creation, cleaning and removal of volatile and temporary
  files and directories which usually reside in directories such as /run
  or /tmp.

  Volatile and temporary files and directories are those located in /run
  (and its alias /var/run), /tmp, /var/tmp, the API file systems such as
  /sys or /proc, as well as some other directories below /var.



> Things seem to run normally despite the error.

Above should be a starting place in seeing if the needed tmp-type files
and places actually got created at startup.  If, indeed, those don't 
exist, then I would not trust to the system running normally.

Also, it's a really good idea to develop a basic understanding of major
directory trees on Linux systems.  /etc/fstab entries can serve as a
starting point, and skim-reading the Filesystem Hierarchy Standard (FHS) 
documentation.

(Me, I like tmp-dirs getting created by a dirt-simple startup script
that never fails.  ;->  )

 
> # systemctl status systemd-tmpfiles-setup.service
> ● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
>    Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: enabled)
>    Active: failed (Result: exit-code) since Wed 2018-08-08 09:02:48 PDT; 25min ago
>      Docs: man:tmpfiles.d(5)
>            man:systemd-tmpfiles(8)
>   Process: 498 ExecStart=/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=1
>  Main PID: 498 (code=exited, status=1/FAILURE)
> 
> Aug 08 09:02:47 PZ01 systemd[1]: Starting Create Volatile Files and Directories...
> Aug 08 09:02:47 PZ01 systemd-tmpfiles[498]: [/etc/tmpfiles.d/legacy.conf:18] Unknown group 'lock'.
> Aug 08 09:02:48 PZ01 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE
> Aug 08 09:02:48 PZ01 systemd[1]: Failed to start Create Volatile Files and Directories.
> Aug 08 09:02:48 PZ01 systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state.
> Aug 08 09:02:48 PZ01 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'.



This line looks suspiciously like it must be near to, or at, the core of
your problem:

  Aug 08 09:02:47 PZ01 systemd-tmpfiles[498]: [/etc/tmpfiles.d/legacy.conf:18] Unknown group 'lock'.

In other words, there's a line in /etc/tmpfiles.d/legacy.conf (which you
should examine) that instructs systemd at startup time to create a
directory owned by group 'lock', but systemd is refusing to do so,
because it thinks there's no such group.  Based on some searching, the 
etc/tmpfiles.d/legacy.conf line in question _might_ be:

  d /run/lock/lockdev 0775 root lock -


Do this (as the root user) to gather information:

  grep lock /etc/group

This will tell you whether a group called 'lock' exists in /etc/group.
I'm betting it will return null.  If it does, you can just create one
(again, as the root user):

  groupadd -r lock


Whatever tmp-type directory systemd is failing to create (look in
/etc/tmpfiles.d/legacy.conf to see which line references group 'lock'), 
you can & should use standard Unix tools to observe that symptom
directly.  E.g., if the diretory that was to be created is
/run/lock/lockdev, then do (as the root user):

  ls -l /run/lock

E.g., you might be able verify from the evidence of your own eyes (using
the above example) that no such directory as /run/lock/lockdev exists.


Looks like there was a bug about this in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1324184
(I'll not quote from that, because this message is long enough already,
but you might want to skim-read it.)


FYI, speaking in general terms, lock files (traditionally inside
/var/run/lock, of which the systemd-ish replacement appears to be
/run/lock, ) are files indicating that a shared device or other system
resource is in use and containing the identity of the process (PID)
using it; this allows other processes to properly coordinate access to
the shared device or other resource.

About, specifically, lockdev:
https://www.systutorials.com/docs/linux/man/8-lockdev/

  NAME

  Lockdev is a setgid binary, which provides a reliable way to put an
  exclusive lock in /var/lock to devices (e.g. ttyS0) using both FSSTND
  and SVr4 methods, so regular users don't need write access there.
  [...]