On Monday, September 24, 2018 at 1:38:00 PM UTC+2, Rusty Bird wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Marcus Linsner:
> > Can I maybe still use audit=0 ? ie. another way to fix the above
> > error? because I don't want to see the audit spam on dmesg (mainly
> > due to journal being sync-ed to disk, seemingly every time).
>
> That audit spam shouldn't trigger a disk sync (because it doesn't have
> CRIT/ALERT/EMERG priority), according to the journald.conf manpage:
>
> | SyncIntervalSec=
> | The timeout before synchronizing journal files to disk. After
> | syncing, journal files are placed in the OFFLINE state. Note that
> | syncing is unconditionally done immediately after a log message of
> | priority CRIT, ALERT or EMERG has been logged. This setting hence
> | applies only to messages of the levels ERR, WARNING, NOTICE, INFO,
> | DEBUG. The default timeout is 5 minutes.
>
> If it does, might be worth filing a systemd bug.
Maybe it's a dom0 feature? patch added by qubes? (i doubt it but hey)
It doesn't seem to happen in a Fedora 28 VM, but on dom0 (Fedora 25), I can
dupe it with these steps:
1. in a terminal: dmesg --raw -w
2. in another terminal: sudo iotop
3. in a 3rd terminal: logger
every time you press Enter in [3.] you see systemd-journald making a write in
[2.] (and you see the loglevel 5 message on [1.], except in Fedora 28 but may
be my systemd .conf settings(see below)) (in [2.] "Actual DISK WRITE" is like
15KB)
Practically when audit=0 doesn't exist in xen.cfg for me(*), and I've xfce
panel plugin "Sensors plugin" set to refresh every 5 sec, then it spews 3 lines
dmesg every 5 seconds and does a disk write(actual disk write, so I assumed
sync/flush), 3 lines like these:
<5>[ 521.639294] audit: type=1100 audit(1537814876.977:451): pid=5406 uid=1000
auid=1000 ses=2 msg='op=PAM:authentication grantors=pam_localuser acct="root"
exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? res=success'
<5>[ 521.639418] audit: type=1101 audit(1537814876.977:452): pid=5406 uid=1000
auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_permit acct="root"
exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? res=success'
<15>[ 521.640091] userhelper[5406]: running '/usr/sbin/hddtemp -n -q /dev/sda'
with root privileges on behalf of 'ctor'
* it actually syncs to disk even when audit=0 does exist in /proc/cmdline
because then I still get to see the level 15 message from above, and the logger
reproduction steps still work, obviously. I've to hide the disk temperature in
Sensors plugin to actually stop the every 5 sec disk sync due to that log level
15 new dmesg line.
Since it doesn't happen in Fedora 28, and Fedora 25 in dom0's systemd is too
old, I can't report a bug. It's possibly fixed anyway.
In /etc/systemd/journald.conf I've the uncommented "#SyncIntervalSec=5m" which
means it's at its default value.
I'm not sure what level is 5, but I see these:
/* We show everything that is MORE important than this.. */
#define CONSOLE_LOGLEVEL_SILENT 0 /* Mum's the word */
#define CONSOLE_LOGLEVEL_MIN 1 /* Minimum loglevel we let people use */
#define CONSOLE_LOGLEVEL_QUIET 4 /* Shhh ..., when booted with "quiet" */
#define CONSOLE_LOGLEVEL_DEBUG 10 /* issue debug messages */
#define CONSOLE_LOGLEVEL_MOTORMOUTH 15 /* You can't shut this one up */
in
/home/user/qubes-builder/chroot-fc25/home/user/rpmbuild/BUILD/kernel-latest-4.18.9/linux-4.18.9/include/linux/printk.h
Oh wait, it's actually in linux/kern_levels.h
#define KERN_EMERG KERN_SOH "0" /* system is unusable */
#define KERN_ALERT KERN_SOH "1" /* action must be taken immediately */
#define KERN_CRIT KERN_SOH "2" /* critical conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
#define KERN_NOTICE KERN_SOH "5" /* normal but significant condition */
#define KERN_INFO KERN_SOH "6" /* informational */
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
#define KERN_DEFAULT KERN_SOH "d" /* the default kernel loglevel */
so 5 is Notice.
So you see, for me, it appears (unless I'm wrong about something and I don't
know it, but happy to stand corrected) that new dmesg lines are instantly
sync-ed to disk in dom0.
Maybe's something else I've changed, however I do remember seeing the HDD led
blink every second after a new Qubes 4.0 install just after setting Sensors to
refresh every 1 second. (that install was too new to have changed anything else
like systemd .conf files or kernel cmdline options)
Here's what I've changed systemd-wise:
[ctor@dom0 ~]$ grep -nHv '^\s*#' /etc/systemd/*.conf
/etc/systemd/coredump.conf:13:
/etc/systemd/coredump.conf:14:[Coredump]
/etc/systemd/journald.conf:13:
/etc/systemd/journald.conf:14:[Journal]
/etc/systemd/journald.conf:21:RateLimitIntervalSec=0
/etc/systemd/journald.conf:23:RateLimitBurst=5000
/etc/systemd/journald.conf:25:
/etc/systemd/journald.conf:37:ForwardToSyslog=yes
/etc/systemd/journald.conf:39:ForwardToKMsg=yes
/etc/systemd/journald.conf:41:ForwardToConsole=yes
/etc/systemd/journald.conf:43:ForwardToWall=yes
/etc/systemd/journald.conf:45:TTYPath=/dev/tty12
/etc/systemd/journald.conf:47:MaxLevelStore=debug
/etc/systemd/journald.conf:49:MaxLevelSyslog=debug
/etc/systemd/journald.conf:51:MaxLevelKMsg=debug
/etc/systemd/journald.conf:53:MaxLevelConsole=debug
/etc/systemd/journald.conf:55:MaxLevelWall=emerg
/etc/systemd/logind.conf:13:
/etc/systemd/logind.conf:14:[Login]
/etc/systemd/resolved.conf:13:
/etc/systemd/resolved.conf:14:[Resolve]
/etc/systemd/resolved.conf:16:DNS=
/etc/systemd/resolved.conf:18:FallbackDNS=
/etc/systemd/resolved.conf:21:LLMNR=no
/etc/systemd/resolved.conf:23:DNSSEC=no
/etc/systemd/resolved.conf:25:Cache=yes
/etc/systemd/resolved.conf:26:
/etc/systemd/resolved.conf:28:MulticastDNS=no
/etc/systemd/resolved.conf:29:
/etc/systemd/system.conf:13:
/etc/systemd/system.conf:14:[Manager]
/etc/systemd/system.conf:22:CrashChangeVT=yes
/etc/systemd/system.conf:24:CrashShell=yes
/etc/systemd/system.conf:26:CrashReboot=no
/etc/systemd/system.conf:27:
/etc/systemd/system.conf:31:
/etc/systemd/system.conf:41:DefaultStandardOutput=journal+console
/etc/systemd/system.conf:43:DefaultStandardError=journal+console
/etc/systemd/system.conf:44:DefaultTimeoutStartSec=90s
/etc/systemd/system.conf:46:DefaultTimeoutStopSec=90s
/etc/systemd/timesyncd.conf:13:
/etc/systemd/timesyncd.conf:14:[Time]
/etc/systemd/user.conf:12:
/etc/systemd/user.conf:13:[Manager]
And xen.cfg -wise
[4.18.9-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:2048M dom0_mem=max:4096M iommu=no-igfx
ucode=scan smt=off
kernel=vmlinuz-4.18.9-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root
rd.luks.uuid=luks-9ed952b5-2aa8-4564-b700-fb23f5c9e94b
rd.lvm.lv=qubes_dom0/root i915.alpha_support=1 rd.luks.options=discard
root_trim=yes rd.luks.allow-discards ipv6.disable=1 loglevel=15 log_buf_len=16M
printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=0
memory_corruption_check=1 fbcon=scrollback:4096k fbcon=font:ProFont6x11
net.ifnames=1 pax_sanitize_slab=full console=tty1 earlyprintk=vga
systemd.log_target=kmsg systemd.journald.forward_to_console=1
udev.children-max=1256 rd.udev.children-max=1256 rhgb sysrq_always_enabled
ramdisk=initramfs-4.18.9-1.pvops.qubes.x86_64.img
(audit=0 is removed from above, currently - I placed it back after this post)
[ctor@dom0 ~]$ sysctl -a 2>/dev/null|grep -i vm.dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 360000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 60000
vm.dirtytime_expire_seconds = 43200
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/c4f46f8a-4a93-4ca0-bd9a-4e32a572b600%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
