>>> Mantas Mikulenas <grawity@xxxxxxxxx> schrieb am 28.01.2022 um 12:36 in Nachricht <CAPWNY8U-pej3_t9wMj3F=kRPQbGjCpph7sd1mFAkj65B0arkuw@xxxxxxxxxxxxxx>: > On Fri, Jan 28, 2022, 11:59 Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> > wrote: > >> >>> Mantas Mikulenas <grawity@xxxxxxxxx> schrieb am 28.01.2022 um 10:27 in >> Nachricht >> <CAPWNY8U8wQxPh2enZ-WTnaRjFoPUt8SpeFMUiqX8x+rAet9csg@xxxxxxxxxxxxxx>: >> > On Fri, Jan 28, 2022 at 10:50 AM Ulrich Windl < >> > Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote: >> > >> >> Hi! >> >> >> >> When upgrading SLES15 to SP3, a newer version of systemd was installed >> >> (246.16+suse.191.g3850086c65). >> >> Since then I see new journal messages like these that I cannot associate >> >> with a unit: >> >> >> >> Jan 27 09:29:30 h16 systemd[1]: var-tmp-AP_0xC5KDJP.mount: Succeeded. >> >> Jan 27 09:29:30 h16 systemd[22591]: var-tmp-AP_0xC5KDJP.mount: >> Succeeded. >> >> >> >> Where do these messages originate from, and couldn't they be improved? >> Or >> >> is it some debug-leftover? >> >> I do not see corresponding names in /var/tmp. >> >> >> > >> > If I understand correctly, the messages indicate that the filesystem was >> > *unmounted*, and the same program which did mounting/unmounting >> immediately >> > cleaned up the mountpoint as well. >> > >> > (systemd reacts to external mounts as those also contribute to >> > dependencies.) >> > >> > If OpenSuSE has the kernel audit subsystem enabled, try using `auditctl` >> to >> > monitor a) what process executes mount-related syscalls, b) what process >> > creates directories under /var/tmp. >> >> Thanks, >> >> probably these messages are related to mounting a virtual CD, as nearby are >> these messages: >> Jan 27 09:29:29 h16 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3 >> Jan 27 09:29:29 h16 kernel: ISO 9660 Extensions: RRIP_1991A >> Jan 27 09:29:30 h16 systemd[1]: var-tmp-AP_0xC5KDJP.mount: Succeeded. >> Jan 27 09:29:30 h16 systemd[22591]: var-tmp-AP_0xC5KDJP.mount: Succeeded. >> Jan 27 09:29:30 h16 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3 >> Jan 27 09:29:30 h16 kernel: ISO 9660 Extensions: RRIP_1991A >> Jan 27 09:29:31 h16 systemd[22591]: var-tmp-AP_0x6tWaHS.mount: Succeeded. >> Jan 27 09:29:31 h16 systemd[1]: var-tmp-AP_0x6tWaHS.mount: Succeeded. >> >> Still I wonder what this is all about (systemd finding a CD, mounting it, >> just >> to find out that no-one needs it?)... >> > > Why do you think systemd is finding and/or mounting it? As I see no other log message around that's the most likely explanation IMHO, especially as systemd interferes with everything these days. Regards, Ulrich