touch-packages team mailing list archive

[Rafał Cieślak <rafalcieslak256@xxxxxxxxx>]

Here are the requested logs:

Normal boot:
journal http://paste.ubuntu.com/11801096/
jobs.txt http://paste.ubuntu.com/11801103/
failed.txt http://paste.ubuntu.com/11801107/

During a normal boot, I observe no issues. The directory is created as it should, and network-manager starts successfully.
You noticed that the logs I sent previously (from recovery mode) claim that systemd-tpmfiles is not started, because it waits for local-fs, which makes perfect sense, as [usually] filesystems are not mounted in recovery mode.
However, my original problem was that I was not able to start network-manager in recovery mode. When enabling networking from the recovery menu, file systems get mounted, so systemd-tmpfiles should start afterwards. The logs I have attached to my previous comment are from a boot into recovery mode *without* networking, which is why fs are not mounted. I have repeated the procedure when booting into recovery mode *with* networking enabled from the recovery menu (in such case the /run/sendsigs.omit.d directory is still missing, even though filesystems should be mounted) - below I attach logs from such boot.

Recovery mode with networking enabled:
systemctl status -l systemd-tmpfiles-setup.service http://paste.ubuntu.com/11801094/
journalctl -b http://paste.ubuntu.com/11801088/

I hope this makes a bit more sense now.

** Changed in: systemd (Ubuntu)
       Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1467131

Title:
  systmd-tmpfiles-setup sometimes not run on boot

Status in systemd package in Ubuntu:
  New

Bug description:
  This is happening on an up-to-date 15.04,with systemd=219-7ubuntu6.
  Ocasionally, when booting up the system, network-manager service fails to start, reporting in logs that it is missing /run/sendsigs.omit.d directory.
  That file is indeed missing, although it is listed in /usr/lib/tmpiles.d/debian.conf
  The issue is reproducible when starting the system in recovery mode; in normal mode it happens occasionally (about 50%).

  Output of "journalctl -b": http://paste.ubuntu.com/11745993/
  Contents of /usr/lib/tempfiles.d/debian.conf: http://paste.ubuntu.com/11746045/

  Running "systemd-tmpfiles --create" after such unsuccesfull boot
  creates the missing directory (and some other too).

  The problem is similar to #1431110, but that bug was found to be a
  duplicate of another problem that is now fixed. Even with that fix, I
  am experiencing a correlated issue. I considered commenting on that
  bug, but marking it as non-incomplete (so that it would gain any
  attention) would require unlinking the duplicate, which wouldn't be
  right.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1467131/+subscriptions