touch-packages team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

> - there are various apport hooks that attach /var/log/udev to bug
reports,

If it's only that, I'm happy to fix those. In fact I noticed that it was
still attached by apport's attach_hardware() hookutils, I removed that.
The other call that I see on my system is in libmtp, I just uploaded a
fix. I'm happy to do an archive grep to update the other apport hooks.

This log does not really give you that much -- if a value is wrong or a
device is missing, then you still need to boot with "debug" to get all
the "why"s, like the corresponding kernel messages or the output/error
messages of udev probes. You can maybe compare the order in which
devices are detected in a successful and a failed boot, but for this
again you need to do multiple boots and then can also just use "debug".

So I still consider it as something which is unnecessarily done at every
boot and not useful enough to be kept (I look at a lot of boot failures,
and haven't met a single case where this was useful..) So if you don't
mind, I'd rather repurpose this as

  - Search/fix remaining apport hooks which write this file
  - Clean up /var/log/udev on upgrade

** Changed in: systemd (Ubuntu Xenial)
       Status: Incomplete => In Progress

-- 
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/1537211

Title:
  clean up /var/log/udev.log

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Committed
Status in libmtp package in Debian:
  Unknown

Bug description:
  The udev package contains an upstart job, /etc/init/udevmonitor.conf,
  whose purpose is to record boot-time information about devices in a
  log file for future debugging.  There is no equivalent systemd unit
  for this job, so with the move to systemd, we now lose this useful
  debugging information.  I'm not aware of any other way under systemd
  to get a replay of the boot-time kernel events.  If there is one,
  that's fine, but otherwise there should be a systemd unit equivalent
  here that can give us this log.

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