Ubuntu 17.10 has switched from the unmaintained gnome-system-log app
to gnome-logs by default. While gnome-system-log is a traditional log
viewer, gnome-logs only displays logs from systemd. apt was identified
as a particular part of the system that doesn't use systemd logging
and so this is a regression compared to previous Ubuntu releases.

I expect Debian will need to maintain the ability to emit traditional
logs without using systemd's journal. It makes sense to me for apt on
Ubuntu to use systemd logging by default, but I think it makes sense
on Debian too. At least on Ubuntu, it would make sense to *only* log
to the systemd journal (systemd can be configured to create
traditional logs for users that want that).

Thanks,
Jeremy Bicha

So, not discussing about usefulness or not but practical aspects:

- chroots would also log in the machine journal, which is wrong
- same for some other weird temporary chroot thingies
- term.log might contain sensitive data that should not be
  easily available (I think)
- dpkg.log and update-alternatives.log are more detailed step-by-step
  logs.

Maybe someone on debian-devel has some more opinion, but I'm not sure
if it is worthwhile pursuing this.

I don't believe a log that tends to be useful after a system crash should be
kept only in a place that explicitely disables protection normally granted
by a filesystem in case of such crashes:
* rsyslog fsyncs every message it believes important, performance be damned
* journald asks for the logs to be marked nocow (and chastises the user if
  you try to unmark them)

(I don't know much about systemd, but I do know btrfs, thus the rest is
btrfs-specific.)

Btrfs offers a flag, FS_NOCOW_FL, that basically says "I don't care about
safety of data in this file, please sacrifice all consistency features for a
minor performance gain".  This reduces crash safety to ext4 level on
single-device, and below md level on RAID.  It might be ok to use this for
files that want just an unmanaged area of a disk, such as databases or VM
images, that do their own journaling[1].  As far as I know, journald's
journal files have no journal.
FS_NOCOW_FL disables:
* out-of-place writes (a partial write can corrupt existing data in the file)
* checksumming
* btrfs-specific backup tools (they rely on enumeration of modified blocks,
  nocow doesn't bump a block's generation)
* DUP/RAID recovery

Thus, I believe that apt logging to journald rather than to traditional logs
would lead to data loss on crashes, which is a not insignificant part of
reason why we have these logs in the first place.


Meow!

[1]. You suffer from write reordering and torn writes, but that's no
different from a physical disk.