clean up /var/log/udev.log

I'm quite aware that we don't write this any more, but why do we penalize every boot with this? What is realistically there that isn't in "udevadm info --export-db"?

If we want a full log with timestamps etc. I'm fine with providing a disabled service which does that. This could be enabled using the standard "systemctl enable udev-monitor", or also via the kernel command line if "debug" is given. But I am really resistant about writing this extra log file all the time without a good reason.

On Sun, Jan 24, 2016 at 06:38:22PM -0000, Martin Pitt wrote:
> I'm quite aware that we don't write this any more, but why do we
> penalize every boot with this? What is realistically there that isn't in
> "udevadm info --export-db"?

Well, it's possible I may not have known about the existence of this command
;)

Two things that are relevant here:

 - there are various apport hooks that attach /var/log/udev to bug reports,
   so these are currently attaching stale data (if any); one way or the
   other this should get fixed for 16.04.
 - the --export-db output doesn't include timestamps - or even ordering
   information, which may be very important for debugging.

On Sun, Jan 24, 2016 at 06:40:24PM -0000, Martin Pitt wrote:
> If we want a full log with timestamps etc. I'm fine with providing a
> disabled service which does that. This could be enabled using the
> standard "systemctl enable udev-monitor", or also via the kernel command
> line if "debug" is given. But I am really resistant about writing this
> extra log file all the time without a good reason.

I'm not aware of any complaints about the impact on boot time of running
this job. It necessarily writes to tmpfs early in boot, which is fast and
doesn't interfere with I/O. It's copied to /var/log later in boot, once
we're past the critical path. I don't see a performance reason for not
always running this at boot, especially given the possible difficulties of
reproducing a particular boot-time failure later if the job wasn't already
enabled.

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

> - the --export-db output doesn't include timestamps - or even ordering information, which may be very important for debugging.

Ah, forgot to reply to this -- there is USEC_INITIALIZED which is the monotonic timestamp since the boot.

libmtp's apport hook is even actively wrong -- MTP devices are usually hotplugged, so attaching /var/log/udev (even if it was current) is often useless. You want the current set of devices there (the hook even asks you to plug in the devices you want to report), not the ones that was present at boot. Fix uploaded and sent to Debian.

I committed a cleanup of the file to udev.postinst (if running under systemd).

I grepped the whole archive and the only hook that explicitly attaches /var/log/udev was libmtp (which got fixed in https://launchpad.net/ubuntu/+source/libmtp/1.1.10-2ubuntu1).

This bug was fixed in the package apport - 2.19.4-0ubuntu1

---------------
apport (2.19.4-0ubuntu1) xenial; urgency=medium

  * New upstream bug fix release:
    - Fix fileutils.test_find_package_desktopfile test for symlinks and other
      unowned files in /usr/share/applications/.
    - Fix ui.test_run_crash_anonymity test case to not fail if the base64
      encoded core dump happens to contain the user name, as that's just by
      chance. - Fix test_hooks.py for unreleased gcc versions which have a
      different --version format.
    - hookutils.py, attach_hardware(): Stop attaching /var/log/udev. This was
      an upstart-ism, mostly redundant with the udev db and is not being
      written under systemd. (LP: #1537211)
  * etc/apport/crashdb.conf: Enable crash reports on Launchpad for xenial.

 -- Martin Pitt <email address hidden> Tue, 26 Jan 2016 15:37:44 +0100

This bug was fixed in the package systemd - 228-5ubuntu1

---------------
systemd (228-5ubuntu1) xenial; urgency=medium

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - Hack to support system-image read-only /etc, and modify files in
      /etc/writable/ instead.
    - Simpler udev maintainer scripts (all platforms must support udev, no
      debconf).
    - Provide shutdown fallback for upstart. (LP: #1370329)
    - Add Get-RTC-is-in-local-time-setting-from-etc-default-rc.patch: In
      Ubuntu we currently keep the setting whether the RTC is in local or UTC
      time in /etc/default/rcS "UTC=yes|no", instead of /etc/adjtime.
      (LP: #1377258)
    - Chown the "systemd" controller of user scropes to the user. This makes
      unprivileged user LXC containers work under systemd, together with
      libpam-cgfs. (LP: #1346734)
    - Build using libseccomp on powerpc and ppc64el (See Debian #800818).

    Upgrade fixes, keep until 16.04 LTS release:
    - systemd Conflicts/Replaces/Provides systemd-services.
    - Remove obsolete systemd-logind upstart job.
    - Clean up obsolete /etc/udev/rules.d/README.
    - systemd.postinst: Migrate mountall specific fstab options to standard
      util-linux "nofail" option.
    - systemctl: Don't forward telinit u to upstart. This works around
      upstart's Restart() always reexec'ing /sbin/init on Restart(), even if
      that changes to point to systemd during the upgrade. This avoids running
      systemd during a dist-upgrade. (LP: #1430479)
    - Break lvm (<< 2.02.133-1ubuntu1) and remove our dummy /etc/init.d/lvm2
      on upgrades, as it's shipped by lvm2 now.
    - Make udev break on mdadm << 3.3-2ubuntu3, as udev's init script dropped
      the "Provides: raid-mdadm".
    - Clean up /var/log/udev on upgrade (which is written under upstart, but
      not under systemd). (LP: #1537211)
    - Migrate existing s390x network configuration to new names. (LP: #1526808)

systemd (228-5) unstable; urgency=medium

  [ Martin Pitt ]
  * Drop systemd-vconsole-setup.service: It has never been installed/used in
    Debian and is not necessary for Ubuntu any more.
  * Drop halt-local.service. This has never been documented/used in Debian.
    (LP: #1532553)
  * debian/extra/initramfs-tools/scripts/init-bottom/udev: Prefer "nuke"
    again, it comes from klibc-utils. But fall back to "rm" if it does not
    exist.
  * systemd-timesyncd.service.d/disable-with-time-daemon.conf: Also don't run
    if /usr/sbin/VBoxService exists, as virtualbox-guest-utils already
    provides time synchronization with the host. (Closes: #812522)
  * Drop Michael Stapelberg from Uploaders:, he stopped maintenance long ago.
    Thanks Michael for your great work in the past!
  * Replace "sysv-rc" dependency with Conflicts: openrc, file-rc. The
    rationale from #739679 still applies, but with the moving of
    {invoke,update}-rc.d to init-system-helpers we don't actually need
    anything from sysv-rc any more other than the assumption that SysV init
    scripts are enabled in /etc/rc?.d/ for the SysV generator to work (and
    file-rc and openrc don't do that).
  * debian/tests/timedated: Verify /etc/localtim...