Bug#876899: apt: Log to the systemd journal
On Tue, Sep 26, 2017 at 11:51:07PM +0200, Julian Andres Klode wrote:
> On Tue, Sep 26, 2017 at 02:46:55PM -0400, Jeremy Bicha wrote:
> > 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).
>
> 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.
--
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities. -- whitroth on /.
Reply to: