Re: [systemd-devel] sd-bus signal callback return value

[Daan De Meyer]

Hi,

I've opened a pull request to clarify the return values of the callbacks
and their effect: https://github.com/systemd/systemd/pull/15253. It's not
complete yet but the idea is to add answers for all your questions to the
docs.

Regards,

Daan

On Tue, 24 Mar 2020 at 21:44, Stanislav Angelovič 
wrote:

> Hi folks,
>
> Please, what is the difference in sd-bus behavior when my D-Bus signal
> callback returns a zero return value versus a positive return value?
>
> And what's the difference between those return values in D-Bus method
> callback, D-Bus async method reply callback, D-Bus property get callback,
> and D-Bus property set callback?
>
> Which shall I return in normal cases? Zero?
>
> Thanks a lot in advance for your response... Take care & stay healthy,
>
> Stanislav.
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Bizarre issue with logins and cgroups?

[Ryan]

I don't yet have a small test for this yet, so here's all the information
I've found while I get that ready:

I have a side project  that revolves around using
systemd-nspawn to run pet containers. One feature I'm trying to use it for
is booted containers, where the following happens:

- During container boot, a service is run that creates an account inside
the container corresponding to the outside user. This service depends on
multi-user.target, as well as console-getty (which is overridden to enable
autologin).
- The service inside signals the outside world when it's done that the
container is ready for login.
- Once the signal is received outside, the host uses nsenter to enter the
container namespace, then runs

  runuser -s /bin/bash -- - "$THE_USER_NAME" some-command

Here's the bizarre part: runuser just hangs forever. I went into debugging
it further, and found it was hanging waiting for a response from
systemd-logind while executing the PAM config. With verbose logging for
logind enabled, I observed the following:

  Mar 27 01:04:35 test-boot systemd[1]: Failed to start Session 47 of user
vagrant.

Looking further up:

  Mar 27 01:04:35 test-boot systemd-logind[25]: Sent message
type=method_call sender=n/a destination=org.freedesktop.systemd1
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.>
  Mar 27 01:04:35 test-boot systemd[1]: session-47.scope: Failed to add
PIDs to scope's control group: No such file or directory
  Mar 27 01:04:35 test-boot systemd[1]: session-47.scope: Failed with
result 'resources'

With verbose logging for systemd itself available, I observed the following
(this was on cgroups v1, but the same error appears with v2):

  Mar 27 20:27:36 test-boot systemd[1]: session-3.scope: Failed to set
'memory.limit_in_bytes' attribute on
'/user.slice/user-1000.slice/session-3.scope' to '-1': No such file or
directory
  Mar 27 20:27:36 test-boot systemd[1]: session-3.scope: Failed to set
'pids.max' attribute on '/user.slice/user-1000.slice/session-3.scope' to
'max': No such file or directory
  Mar 27 20:27:36 test-boot systemd[1]: session-3.scope: Couldn't move
process 73 to requested cgroup
'/user.slice/user-1000.slice/session-3.scope': No such file or directory
  Mar 27 20:27:36 test-boot systemd[1]: session-3.scope: Failed to add PIDs
to scope's control group: No such file or directory
  Mar 27 20:27:36 test-boot systemd[1]: session-3.scope: Failed with result
'resources'.

So...it seems to be getting stuck on moving processes to the new session's
scope's cgroup? Here's the weird part: if I wait around 10-15 seconds or
so, then run it again...it works. This would lead me to believe there's a
race somewhere, but I can't find anything implying that in the logs.

At this point I'm just stumped. I'm working to reproduce it with just pure
nspawn, but in the mean time, I was curious if anyone here had an idea on
where this could be coming from?

-- 
Ryan
https://refi64.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel