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