[systemd-devel] Antw: [EXT] Re: systemd killing processes on monitor wakeup?

[Ulrich Windl]

>>> Raman Gupta  schrieb am 29.01.2022 um 04:28 in 
>>> Nachricht
:
>> 
>> Try to set the systemd user instance's log level to 'debug'; I'm guessing
>> it's not that systemd kills processes directly but that something triggers
>> a 'systemctl stop' of the session .scope that they were in.
> 
> 
> Here are the logs at debug level with some annotations inline:
> 
> **
> 
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Application
> 'plasmashell' crashing...
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Attempting to start
> /usr/libexec/drkonqi

[...]

This may not answer your question at all, but I think the real culprit is 
modern technology like display port, that allows the OS to detect when a 
monitor connects or disconnects.
I had real trouble with Windows 10 after using a new monitor and a KVM-switch: 
Every time I switched the KVM between two computers, Windows reset the graphics 
resolution to some "standard" (like 800x600), also moving all the windows on 
the desktop to the upper left corner. Besides that KVM switching is slower than 
ever. Back in the times of PS/2 and analog VGA connector I could switch twice 
within a second without a problem.

So for your problem I guess the application cannot really handle the monitor 
hotplug event.

Regards,
Ulrich

[systemd-devel] Antw: Re: [EXT] Re: Q: "systemd[1]: var-tmp-AP_0x6tWaHS.mount: Succeeded."

[Ulrich Windl]

>>> Mantas Mikulenas  schrieb am 28.01.2022 um 12:36 in
Nachricht
:
> On Fri, Jan 28, 2022, 11:59 Ulrich Windl 
> wrote:
> 
>> >>> Mantas Mikulenas  schrieb am 28.01.2022 um 10:27 in
>> Nachricht
>> :
>> > On Fri, Jan 28, 2022 at 10:50 AM Ulrich Windl <
>> > ulrich.wi...@rz.uni-regensburg.de> 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

Re: [systemd-devel] Where to put unix sockets while SELinux enforces on init_t?

[Daniel Farina]

On Sun, Jan 30, 2022 at 3:01 AM Mantas Mikulėnas  wrote:
>
> On Sun, Jan 30, 2022 at 12:47 AM Daniel Farina  wrote:
>>
>> I am using SELinux enforced AlmaLinux, and am wondering where the customary 
>> place to put a ListenStream directive that is opening a unix socket should 
>> be.
>>
>> Old-school customarily, /tmp suffices, but SELinux blocks that: "init_t" is 
>> not allowed to create the socket there.
>>
>> Looking through definitions, /var/run/systemd is a place that systemd can 
>> create unix socket files, and indeed my prototype using this works, but I'm 
>> not sure if this is where they "belong."
>>
>> Does anyone have an opinion on this?
>
>
> I'm not familiar with SELinux defaults, but the standard location for sockets 
> has long been [/var]/run (with /run being the preferred spelling on Linux 
> nowadays), and currently systemd has already been creating lots of sockets 
> under /run in general – on my system I see /run/rpcbind.sock, 
> /run/dmeventd-client, /run/avahi-daemon/socket, all of them created by pid1 
> through .socket units (see `systemctl list-sockets`) and not by the actual 
> daemons themselves. This makes me assume that on distros with SELinux, the 
> default policy would just allow systemd to do that.

You were absolutely right. I knew about this directory and its
customary use, but for some reason didn't think to try it out (I'm not
yet an adept at reading the cumulative effect of SELinux policies)

My particular application is the multi-processor adapted way to run
PGBouncer 
(https://www.2ndquadrant.com/en/blog/running-multiple-pgbouncer-instances-with-systemd/).
The packages even make a pgbouncer user-owned directory in
/run/pgbouncer. Doing something like
"ListenStream=/run/pgbouncer/.s.PGSQL.%i" works.

Thanks,
Daniel

Re: [systemd-devel] Udevd and dev file creation

[Greg KH]

On Sun, Jan 30, 2022 at 05:14:49PM +0530, Nishant Nayan wrote:
> I have started reading about udevd.
> I was trying to find out if there is a way to play with udev without
> plugging in/out any devices.
> Is there a way to trigger a uevent without plugging in devices?

Yes, look at the man page for udevadm.  It lets you trigger any uevent
for the devices in your system that you want.

But again, remember for almost everything, udev does not create /dev/
nodes, that is done by the kernel itself.

good luck!

greg k-h

Re: [systemd-devel] Udevd and dev file creation

[Nishant Nayan]

I have started reading about udevd.
I was trying to find out if there is a way to play with udev without
plugging in/out any devices.
Is there a way to trigger a uevent without plugging in devices?


Regards
Nishant Nayan

On Sun, 30 Jan 2022, 17:13 Nishant Nayan, 
wrote:

> Oops.
> Thanks for pointing that out, I just pressed the reply button, didn't
> notice it.
> Resending now.
>
>
> Regards
> Nishant Nayan
>
> On Sun, 30 Jan 2022, 17:12 Greg KH,  wrote:
>
>> On Sun, Jan 30, 2022 at 05:07:52PM +0530, Nishant Nayan wrote:
>>
>> 
>>
>> For some reason you sent this only to me, which is a bit rude to
>> everyone else on the mailing list.  I'll be glad to respond if you
>> resend it to everyone.
>>
>> thanks,
>>
>> greg k-h
>>
>

Re: [systemd-devel] Where to put unix sockets while SELinux enforces on init_t?

[Mantas Mikulėnas]

On Sun, Jan 30, 2022 at 12:47 AM Daniel Farina  wrote:

> I am using SELinux enforced AlmaLinux, and am wondering where the
> customary place to put a ListenStream directive that is opening a unix
> socket should be.
>
> Old-school customarily, /tmp suffices, but SELinux blocks that: "init_t"
> is not allowed to create the socket there.
>
> Looking through definitions, /var/run/systemd is a place that systemd can
> create unix socket files, and indeed my prototype using this works, but I'm
> not sure if this is where they "belong."
>
> Does anyone have an opinion on this?
>

I'm not familiar with SELinux defaults, but the standard location for
sockets has long been [/var]/run (with /run being the preferred spelling on
Linux nowadays), and currently systemd has already been creating lots of
sockets under /run in general – on my system I see /run/rpcbind.sock,
/run/dmeventd-client, /run/avahi-daemon/socket, all of them created by pid1
through .socket units (see `systemctl list-sockets`) and not by the actual
daemons themselves. This makes me assume that on distros with SELinux, the
default policy would just allow systemd to do that.

-- 
Mantas Mikulėnas

Re: [systemd-devel] systemd killing processes on monitor wakeup?

[Mantas Mikulėnas]

On Sat, Jan 29, 2022 at 5:29 AM Raman Gupta  wrote:

> Try to set the systemd user instance's log level to 'debug'; I'm guessing
>> it's not that systemd kills processes directly but that something triggers
>> a 'systemctl stop' of the session .scope that they were in.
>
>
> Here are the logs at debug level with some annotations inline:
>
> **
>
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Application
> 'plasmashell' crashing...
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Attempting to start
> /usr/libexec/drkonqi
>
> *https://bugs.kde.org/show_bug.cgi?id=396359
> , could be related to
> subsequent events but I'm pretty sure I've seen this same problem even when
> Plasma doesn't crash>*
>
> Jan 28 21:57:34 edison systemd[2551]: Got message type=signal
> sender=org.freedesktop.DBus destination=n/a path=/org/freedesktop/DBus
> interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4294967295
> reply_cookie=0 signature=sss error-name=n/a error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: D-Bus
> name org.kde.plasmashell now not owned by anyone.
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Changed
> running -> stop-sigterm
> Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a
> destination=n/a
> path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged
> cookie=10389 reply_cookie=0 signature=sa{sv}as error-name=n/a
> error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a
> destination=n/a
> path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged
> cookie=10390 reply_cookie=0 signature=sa{sv}as error-name=n/a
> error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3326812
> (idea.sh).
> Jan 28 21:57:34 edison systemd[2551]: Child 3326812 (idea.sh) died
> (code=killed, status=15/TERM)
>
> * died. Not sure why killsnoop.py seems to think that systemd is the process
> that sends the SIGTERM -- it's still unclear to me where IDEA is receiving
> the SIGTERM from>*
>

Processes get SIGCHLD for all children that exit -- it's not suppressed
just because the same process sent a SIGTERM recently.


>
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3326812 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Child 3114994 (kio_http_cache_) died
> (code=killed, status=15/TERM)
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3114994 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Child 3328167 (adb) died
> (code=killed, status=15/TERM)
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3328167 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3328167
> (n/a).
>
> **
>

Honestly this just sounds like systemd killing "leftover" processes within
the plasma-plasmashell cgroup, after the "main" process of that service has
exited. That's not a bug; that's standard behavior for systemd services.

For special cases like desktop environments, I think this means the
.service should have KillMode=process (as long as that's still supported,
anyway), *or* Plasma should be improved to no longer spawn apps directly
but to put them in new systemd units (like gnome-shell does).

-- 
Mantas Mikulėnas