[systemd-devel] kernel messages not making it to journal
dmesg shows this: [ 22.947118] systemd-journald[629]: File /var/log/journal/26336922e1044e80ae4bd42e1d6b9099/user-1000.journal corrupted or uncleanly shut down, renaming and replacing. [ 22.953883] systemd-journald[629]: Creating journal file /var/log/journal/26336922e1044e80ae4bd42e1d6b9099/user-1000.journal on a btrfs file system, and copy-on-write is e But journalctl does not show it at all. Seems like it might be a bug, I expect it to be recorded in the journal, not only found in dmesg. systemd-245.4-1.fc32.x86_64 Thanks, -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd rule tracing ?
On Mo, 01.06.20 06:55, Branko (bran...@s5tehnika.net) wrote: > HI, > > I have a problem with and FTDI-based device. It keeps dissapearing and > reappearing on every 1-2s or so. Nothing in dmesg to indicate failure. > > I'm trying to make my way through systemd-udevd, but it's not easy to debug > things there ( neither is classic udev BTW). > > udevadm monitor -u shows that whole interface is being released, > unbound,rremoved and then added again. > Interestingly, it behaves the same with --kernel as with --udev options. > So it seems that flurry of re/mount requests are coming from kernel > (5.4.43), not from something in rules setup - or so it seems now. > > > NO good, obvious reason why. Kernel shows no error, system-udevd log show > nothing. > > It just repeats that add/remove cycle. > > Daemon has -D option, which changes nothing for me - I still get the same > info back. > > Is there a way to trace down which rule gets executed and why ? udevadm monitor --kernel tells you what the kernel sends to udev, udev then just reacts to that. If you already see the traffic in that output then you know it's really the kernel which is doing this. For all systemd services you can turn on debug logging by setting the env var SYSTEMD_LOG_LEVEL=debug. i.e.: systemctl edit systemd-udevd then type in: [Service] Environment=SYSTEMD_LOG_LEVEL=debug save, exit the editor and restart. > udevadm test /dev/ttyUSB0 gets me nothing of use - just a list of rule files > that were parsed, not what was actually executed. > > BTW, while slightly offtopic, is there somethign in kernel that would get me > more debug info ? > > There used to be some "generate debug info" in USB stack some time ago... Better something to ask the kernel people. if you boot with "debug" on the kernel cmdline you get a bunch more debug info from both kernelspace and userspace. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parent slices and resource control
On So, 31.05.20 14:36, Patrick Dimond (m...@ptrckd.com) wrote: > Hi, > I was reading the documentation for systemd.resource-control and came > across this sentence under accounting settings. > > "Note that turning on memory accounting for one unit will also > implicitly turn it on for all units contained in the same slice > and for all its parent slices and the units contained therein." > > What exactly is a parent slice? > > >From systemd.slice > "Slices are organized hierarchically in a tree. The name of the slice > encodes the location in the tree. The name consists of a dash-separated > series of names, which describes the path to the slice from the root > slice. The root slice is named -.slice. Example: foo-bar.slice is a > slice that is located within foo.slice, which in turn is located in the > root slice -.slice." > > Does turning on accounting in one slice or service end up turning it on > for everything? Does every slice exist under the root slice? Consider this tree: -.slice `- foo.slice | `- miau.service `- bar.slice | `- bar-quux.slice | | `- daemon.service | | `- otherdaemon.service | `- bar-uuu.slice | ` rumpel.service `- zzz.slice `- zzz-yyy.slice `- wuff.service And now you turn on memory accounting in daemon.service. This would then propagate up the three, so you get memory accounting on all its parents too: bar-quux.slice, bar.slice and -.slice. And you will get it turned on forthe units immediately in throse, i.e. also in otherdaemon.service, bar-uuu.slice, foo.slice, zzz.slice. However, it will not be turned on in: miau.service, rumpel.service, zzz-yyy.slice and wuff.service, since those are neither in the path to the root slice nor immediately inside any of those slices. Makes sense? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-udevd rule tracing ?
HI, I have a problem with and FTDI-based device. It keeps dissapearing and reappearing on every 1-2s or so. Nothing in dmesg to indicate failure. I'm trying to make my way through systemd-udevd, but it's not easy to debug things there ( neither is classic udev BTW). udevadm monitor -u shows that whole interface is being released, unbound,rremoved and then added again. Interestingly, it behaves the same with --kernel as with --udev options. So it seems that flurry of re/mount requests are coming from kernel (5.4.43), not from something in rules setup - or so it seems now. NO good, obvious reason why. Kernel shows no error, system-udevd log show nothing. It just repeats that add/remove cycle. Daemon has -D option, which changes nothing for me - I still get the same info back. Is there a way to trace down which rule gets executed and why ? udevadm test /dev/ttyUSB0 gets me nothing of use - just a list of rule files that were parsed, not what was actually executed. BTW, while slightly offtopic, is there somethign in kernel that would get me more debug info ? There used to be some "generate debug info" in USB stack some time ago... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
