Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Fri, May 19, 2017 at 1:46 PM, Chris Murphy wrote: > FYI the file system folks are discussing this. It is not just a > problem with XFS it can affect ext4 too. And it's far from clear the > fs folks have a solution that won't cause worse problems. OK so this is what I

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

FYI the file system folks are discussing this. It is not just a problem with XFS it can affect ext4 too. And it's far from clear the fs folks have a solution that won't cause worse problems. http://www.spinics.net/lists/linux-fsdevel/msg111058.html Chris Murphy

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 20:20, Chris Murphy (li...@colorremedies.com) wrote: > 4. Systemd for not enforcing limited kill exemption to those running > from initramfs, i.e. ignore kill exemption if the program is running > other than initramfs. Well, we are not the police, and we do kill everything by

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 19:30, Chris Murphy (li...@colorremedies.com) wrote: > >> Remember, all of this is because there *is* software that does the wrong > >> thing, and it *is* possible for software to hang and be unkillable. It > >> would > >> be good for systemd to do the right thing even in the

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, Apr 10, 2017 at 4:44 AM, Lennart Poettering wrote: > On Mon, 10.04.17 19:07, Michael Chapman (m...@very.puzzling.org) wrote: > >> > So no, "freeze" is not an option. That sounds like a recipe to make >> > shutdown hang. We need a sync() that actually does what is

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, Apr 10, 2017 at 3:04 AM, Lennart Poettering wrote: > This is specifically the case that happened for Plymouth: the binary > probably got updated, hence the process in memory references a deleted > file, which blocks the read-only remounting, in which case we can't

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

Am Mon, 10 Apr 2017 13:54:27 +0200 schrieb Lennart Poettering : > On Mon, 10.04.17 13:43, Kai Krakow (hurikha...@gmail.com) wrote: > > > Am Mon, 10 Apr 2017 11:04:45 +0200 > > schrieb Lennart Poettering : > > > [...] > > > > > > Yeah, we do

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 13:43, Kai Krakow (hurikha...@gmail.com) wrote: > Am Mon, 10 Apr 2017 11:04:45 +0200 > schrieb Lennart Poettering : > > > > Remember, all of this is because there *is* software that does the > > > wrong thing, and it *is* possible for software to hang and

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

Am Mon, 10 Apr 2017 11:04:45 +0200 schrieb Lennart Poettering : > > Remember, all of this is because there *is* software that does the > > wrong thing, and it *is* possible for software to hang and be > > unkillable. It would be good for systemd to do the right thing even

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 19:07, Michael Chapman (m...@very.puzzling.org) wrote: > > So no, "freeze" is not an option. That sounds like a recipe to make > > shutdown hang. We need a sync() that actually does what is documented > > and sync the file system properly. > > sync() is never going to work the

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10 Apr 2017, Lennart Poettering wrote: On Mon, 10.04.17 19:38, Michael Chapman (m...@very.puzzling.org) wrote: On Mon, 10 Apr 2017, Lennart Poettering wrote: On Mon, 10.04.17 18:45, Michael Chapman (m...@very.puzzling.org) wrote: On Mon, 10 Apr 2017, Lennart Poettering wrote: On

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 19:38, Michael Chapman (m...@very.puzzling.org) wrote: > On Mon, 10 Apr 2017, Lennart Poettering wrote: > > On Mon, 10.04.17 18:45, Michael Chapman (m...@very.puzzling.org) wrote: > > > > > On Mon, 10 Apr 2017, Lennart Poettering wrote: > > > > On Sun, 09.04.17 10:11, Michael

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10 Apr 2017, Lennart Poettering wrote: On Mon, 10.04.17 17:21, Michael Chapman (m...@very.puzzling.org) wrote: Or, I think, when pivoting back to the shutdown-initramfs. (Though then you also need the shutdown-initramfs to run `fsfreeze`, I guess?) No, I don't think it should be done

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10 Apr 2017, Lennart Poettering wrote: On Mon, 10.04.17 18:45, Michael Chapman (m...@very.puzzling.org) wrote: On Mon, 10 Apr 2017, Lennart Poettering wrote: On Sun, 09.04.17 10:11, Michael Chapman (m...@very.puzzling.org) wrote: Don't forget, they've provided an interface for

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 18:45, Michael Chapman (m...@very.puzzling.org) wrote: > On Mon, 10 Apr 2017, Lennart Poettering wrote: > > On Sun, 09.04.17 10:11, Michael Chapman (m...@very.puzzling.org) wrote: > > > > > Don't forget, they've provided an interface for software to use if it > > > needs > > >

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 17:21, Michael Chapman (m...@very.puzzling.org) wrote: > > Or, I think, when pivoting back to the shutdown-initramfs. (Though then you > > also need the shutdown-initramfs to run `fsfreeze`, I guess?) > > No, I don't think it should be done then. If a filesystem is still in use,

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10 Apr 2017, Lennart Poettering wrote: On Mon, 10.04.17 16:14, Michael Chapman (m...@very.puzzling.org) wrote: On Mon, 10 Apr 2017, Chris Murphy wrote: On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering wrote: That said, are you sure FIFREEZE is really what

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10 Apr 2017, Lennart Poettering wrote: On Sun, 09.04.17 10:11, Michael Chapman (m...@very.puzzling.org) wrote: Don't forget, they've provided an interface for software to use if it needs more than the guarantees provided by sync. Informally speaking, the FIFREEZE ioctl is intended to

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 16:14, Michael Chapman (m...@very.puzzling.org) wrote: > On Mon, 10 Apr 2017, Chris Murphy wrote: > > On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering > > wrote: > > > > > That said, are you sure FIFREEZE is really what we want there? it > > > appears

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sun, 09.04.17 10:11, Michael Chapman (m...@very.puzzling.org) wrote: > Don't forget, they've provided an interface for software to use if it needs > more than the guarantees provided by sync. Informally speaking, the FIFREEZE > ioctl is intended to place a filesystem into a "fully consistent"

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sun, 09.04.17 22:37, Chris Murphy (li...@colorremedies.com) wrote: > Oh god - that's the opposite direction to go in. There's not even > pretend crash safety with those file systems. If they're dirty, you > must use an fsck to get them back to consistency. Even if the toy fs > support found in

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10 Apr 2017, Mantas Mikulėnas wrote: On Mon, Apr 10, 2017 at 9:14 AM, Michael Chapman wrote: On Mon, 10 Apr 2017, Chris Murphy wrote: On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering wrote: That said, are you sure FIFREEZE is

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, Apr 10, 2017 at 9:14 AM, Michael Chapman wrote: > On Mon, 10 Apr 2017, Chris Murphy wrote: > >> On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering >> wrote: >> >> That said, are you sure FIFREEZE is really what we want there? it >>>

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10 Apr 2017, Chris Murphy wrote: On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering wrote: That said, are you sure FIFREEZE is really what we want there? it appears to also pause any further writes to disk (until FITHAW is called). So, I am still puzzled why

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sun, Apr 9, 2017 at 2:17 PM, Lennart Poettering wrote: > On Sun, 09.04.17 10:11, Michael Chapman (m...@very.puzzling.org) wrote: > > > Don't forget, they've provided an interface for software to use if it > needs > > more than the guarantees provided by sync.

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sun, Apr 09, 2017 at 10:37:36PM -0600, Chris Murphy wrote: > On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering > wrote: > > > That said, are you sure FIFREEZE is really what we want there? it > > appears to also pause any further writes to disk (until FITHAW is > >

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering wrote: > That said, are you sure FIFREEZE is really what we want there? it > appears to also pause any further writes to disk (until FITHAW is > called). > So, I am still puzzled why the file system people think that

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sat, 8 Apr 2017, Chris Murphy wrote: > On Tue, Apr 4, 2017 at 11:55 AM, Andrei Borzenkov wrote: > > grub2 is not limited to 640KiB. Actually it will actively avoid using > > low memory. It switches to protected mode as the very first thing and > > can use up to 4GiB (and

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sun, 09.04.17 10:11, Michael Chapman (m...@very.puzzling.org) wrote: > Don't forget, they've provided an interface for software to use if it needs > more than the guarantees provided by sync. Informally speaking, the FIFREEZE > ioctl is intended to place a filesystem into a "fully consistent"

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Sun, 9 Apr 2017, Chris Murphy wrote: On Tue, Apr 4, 2017 at 11:55 AM, Andrei Borzenkov wrote: 03.04.2017 07:56, Chris Murphy пишет: On Thu, Mar 30, 2017 at 6:07 AM, Michael Chapman wrote: I am not a filesystem developer (IANAFD?), but I'm

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Tue, Apr 4, 2017 at 11:55 AM, Andrei Borzenkov wrote: > 03.04.2017 07:56, Chris Murphy пишет: >> On Thu, Mar 30, 2017 at 6:07 AM, Michael Chapman >> wrote: >> >>> I am not a filesystem developer (IANAFD?), but I'm pretty sure they're going >>> to

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Thu, Mar 30, 2017 at 6:07 AM, Michael Chapman wrote: > I am not a filesystem developer (IANAFD?), but I'm pretty sure they're going > to say "the metadata _is_ synced, it's in the journal". And it's hard to > argue that. After all, the filesystem will be perfectly

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Thu, 30 Mar 2017, Lennart Poettering wrote: [...] I am sorry, but XFS is really broken here. All init systems since time began kinda did the same thing when shutting down: a) try to unmount all fs that can be unmounted b) for the remaining ones, try to remount ro (the root fs usually

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Wed, 22.03.17 11:05, Chris Murphy (li...@colorremedies.com) wrote: > > Result code of "remount ro" is not evaluated or logged. systemd does > > > > (void) mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, options); > > > > where "options" are those from /proc/self/mountinfo sans ro|rw. > > > >

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 27.03.17 22:27, Mantas Mikulėnas (graw...@gmail.com) wrote: > On Mon, Mar 27, 2017 at 10:20 PM, Chris Murphy > wrote: > > > Ok so the dirty file system problem always happens with all pk offline > > updates on Fedora using either ext4 or XFS with any layout; and

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Thu, Mar 30, 2017 at 1:24 PM, Lennart Poettering wrote: > Or to say this differently: if they expect us to invoke some magic > per-filesystem ioctl() before reboot(), then that's nonsense. No init > system calls that, and I am strongly against such hacks. They should >

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Tue, 28.03.17 11:31, Chris Murphy (li...@colorremedies.com) wrote: > OK but it's obviously possible for a developer to run a process from > root fs, and mark it kill exempt. That's the problem under discussion, > the developer is doing the wrong thing, and it's allowed. And it's > been going

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Tue, Mar 28, 2017 at 8:31 PM, Chris Murphy wrote: > On Tue, Mar 28, 2017 at 10:41 AM, Mantas Mikulėnas > wrote: > > So the same applies to plymouth, IMO -- it should only mark itself > exempt if > > it runs from the initramfs and knows that it

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Tue, Mar 28, 2017 at 10:41 AM, Mantas Mikulėnas wrote: > On Tue, Mar 28, 2017 at 5:01 PM, Chris Murphy > wrote: >> >> On Mon, Mar 27, 2017 at 1:27 PM, Mantas Mikulėnas >> wrote: >> > On Mon, Mar 27, 2017 at 10:20 PM, Chris Murphy

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Tue, Mar 28, 2017 at 5:01 PM, Chris Murphy wrote: > On Mon, Mar 27, 2017 at 1:27 PM, Mantas Mikulėnas > wrote: > > On Mon, Mar 27, 2017 at 10:20 PM, Chris Murphy > > wrote: > >> > >> Ok so the dirty file system problem

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, Mar 27, 2017 at 1:27 PM, Mantas Mikulėnas wrote: > On Mon, Mar 27, 2017 at 10:20 PM, Chris Murphy > wrote: >> >> Ok so the dirty file system problem always happens with all pk offline >> updates on Fedora using either ext4 or XFS with any

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

Ok so the dirty file system problem always happens with all pk offline updates on Fedora using either ext4 or XFS with any layout; and it's easy to reproduce. 1. Clean install any version of Fedora, defaults. 2. Once Gnome Software gives notification of updates, Restart & Install 3. System

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, Mar 27, 2017 at 10:20 PM, Chris Murphy wrote: > Ok so the dirty file system problem always happens with all pk offline > updates on Fedora using either ext4 or XFS with any layout; and it's > easy to reproduce. > > 1. Clean install any version of Fedora,

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Tue, Mar 21, 2017 at 9:48 PM, Andrei Borzenkov wrote: > 22.03.2017 00:10, Chris Murphy пишет: >> OK so I had the idea to uninstall plymouth, since that's estensibly >> what's holding up the remount read-only. But it's not true. >> >> Sending SIGTERM to remaining

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

22.03.2017 00:10, Chris Murphy пишет: > OK so I had the idea to uninstall plymouth, since that's estensibly > what's holding up the remount read-only. But it's not true. > > Sending SIGTERM to remaining processes... > Sending SIGKILL to remaining processes... > Unmounting file systems. >

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

OK so I had the idea to uninstall plymouth, since that's estensibly what's holding up the remount read-only. But it's not true. Sending SIGTERM to remaining processes... Sending SIGKILL to remaining processes... Unmounting file systems. Remounting '/tmp' read-only with options 'seclabel'.

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Tue, Mar 21, 2017 at 12:04 AM, Chris Murphy wrote: > > c. Only XFS is left in a dirty state following the reboot. Ext4 and Btrfs > are OK. This is incorrect. This problem affects ext4 as well, it's just that on ext4, while the fs is left in a dirty state, the

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

Thanks for the reply. On Mon, Mar 20, 2017, 11:05 PM Mantas Mikulėnas wrote: > First thought: Even without the exit code or anything, it's going to be > -EBUSY like 99.999% of the time. Not much else can fail during umount. > > And ”Filesystem is busy" would perfectly fit the

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

First thought: Even without the exit code or anything, it's going to be -EBUSY like 99.999% of the time. Not much else can fail during umount. And ”Filesystem is busy" would perfectly fit the earlier error message which you overlooked: "Process 304 (plymouthd) has been marked to be excluded from

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

Any thoughts on this? I've followed these instructions: https://freedesktop.org/wiki/Software/systemd/Debugging/ Shutdown Completes Eventually However, no additional information is being logged that gives any answer to why there are three remount ro attempts, and why they aren't succeeding.

[systemd-devel] more verbose debug info than systemd.log_level=debug?

I've got a Fedora 22, 23, 24, 25 bug where systemd offline updates of kernel results in an unbootable system when on XFS only (/boot is a directory), the system boots to a grub menu. The details of that are in this bug's comment: https://bugzilla.redhat.com/show_bug.cgi?id=1227736#c39 The gist