Bug#872039: [Pkg-sysvinit-devel] Bug#872039: why the severity?
On 06/25/2018 03:10 AM, Cameron Norman wrote: >> > On the other hand, only a very small minority are still using > sysvinit on >> > Debian, so this I think it's ok to have the severity set to serious. >> >> According to my last data, 14% of unstable users; less on stable as those >> tend to be non-technical users. Not a "very small minority". > > Ignore him. He trolls non-systemd inits and actively roots for their > exit from Debian. +1 Discussing this topic with him is a loss of time and very toxic.
Bug#872039: why the severity?
On Fri, 12 Jan 2018 03:56:42 +0100 Adam Borowski wrote: > On Wed, Jan 10, 2018 at 08:38:39PM +0100, John Paul Adrian Glaubitz wrote: > > > Please tell me why this would be serious: any filesystem from this millenium > > > can handle unclean shutdown fine -- especially if there's a sync before > > > reboot/poweroff. > > > > That's hardly an argument. There is still very much the possibility that > > this bug causes data-loss, so the severity is definitely justified. > > Technically, yes. If your filesystem is ext2, and there's a process that > hasn't been killed, and continues to write after the final sync. > > But if you use ext2 for anything, you made the decision yourself. > Not necessarily, an admin could just have to use ext2 for internal company policy reasons. Let's not punish people for being stuck in a bad situation. /usr is already mounted ro. Can we not remount other filesystems ro like /var at the same time? > > On the other hand, only a very small minority are still using sysvinit on > > Debian, so this I think it's ok to have the severity set to serious. > > According to my last data, 14% of unstable users; less on stable as those > tend to be non-technical users. Not a "very small minority". Ignore him. He trolls non-systemd inits and actively roots for their exit from Debian. Regards, -- Cameron nemo
Bug#872039: why the severity?
On Wed, Jan 10, 2018 at 08:38:39PM +0100, John Paul Adrian Glaubitz wrote: > > Please tell me why this would be serious: any filesystem from this millenium > > can handle unclean shutdown fine -- especially if there's a sync before > > reboot/poweroff. > > That's hardly an argument. There is still very much the possibility that > this bug causes data-loss, so the severity is definitely justified. Technically, yes. If your filesystem is ext2, and there's a process that hasn't been killed, and continues to write after the final sync. But if you use ext2 for anything, you made the decision yourself. > On the other hand, only a very small minority are still using sysvinit on > Debian, so this I think it's ok to have the severity set to serious. According to my last data, 14% of unstable users; less on stable as those tend to be non-technical users. Not a "very small minority". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Bug#872039: why the severity?
> Please tell me why this would be serious: any filesystem from this millenium > can handle unclean shutdown fine -- especially if there's a sync before > reboot/poweroff. That's hardly an argument. There is still very much the possibility that this bug causes data-loss, so the severity is definitely justified. On the other hand, only a very small minority are still using sysvinit on Debian, so this I think it's ok to have the severity set to serious. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#872039: why the severity?
> Reason for Severity=serious: This leaves /var (or other > filesystems) in an unclean state, so could possibly lead to > data loss! Please tell me why this would be serious: any filesystem from this millenium can handle unclean shutdown fine -- especially if there's a sync before reboot/poweroff. For example, on my desktop, non-trivial subvolume layout leads to: [ ok ] Unmounting temporary filesystems...done. [ ok ] Deactivating swap...done. [] Unmounting weak filesystems...umount: /srv/chroots/tmp/home: target is busy. umount: /srv/chroots: target is busy. umount: /home: target is busy. failed. [ ok ] Unmounting local filesystems...done. [16396.379093] BTRFS info (device sda1): using free space tree [ ok ] Stopping the hotplug events dispatcher: systemd-udevd. [info] Will now halt. [16399.026813] kvm: exiting hardware virtualization [16399.031944] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [16399.037624] sd 2:0:0:0: [sdb] Stopping disk [16400.789927] sd 0:0:0:0: [sda] Synchronizing SCSI cache [16400.798161] sd 0:0:0:0: [sda] Stopping disk [16402.943670] ACPI: Preparing to enter system sleep state S5 [16403.045314] reboot: Power down Which I did not bother to look into for many years, yet there's never been any data loss. A sudden _unexpected_ failure (such as due to power blackout, PSU being flaky, etc) may lead to losing contents of files written seconds before the failure, but if the filesystem itself needs a fsck, please report a serious bug against the filesystem in question (yeah, they're parts of the kernel rather than individual Debian packages, but you know where to find their maintainers). An orderly shutdown that doesn't fully unmount a filesystem doesn't count as unexpected. Fixing this bug in general is not really possible, as enumerating some namespaces may be not trivial, processes might be stuck in D state due to some bug, etc. Thus, a sync is supposed to be enough. Filesystems that can't take unclean shutdown do exist (vfat, ext2), but no one seriously considers running a system from them -- and a sync with no further writes means no data loss either. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
