I know this is a long shot but: Is there a way to loop over a set of tasks in ansible and changing "remote_user" (not "become_user")?
-
@dwardoric check out https://github.com/linux-system-roles/systemd/blob/main/tasks/manage_units.yml where they so the same (probably) as what you need: use `become` with`become_user` and set `XDG_RUNTIME_DIR`
@davdr Thanks, I'll take a look.
-
@davdr Thanks, I'll take a look.
@davdr Sadly using that approach ends up with exactly the same error. So I guess I will take a stab at machinectl.
-
@davdr Sadly using that approach ends up with exactly the same error. So I guess I will take a stab at machinectl.
@dwardoric could it be because systemd lingering was not enabled for that user?
Anyway, one way I used machinectl before (from the systemd-container package) is:
$ sudo machinectl shell myuser@
This should drop you in a shell for *myuser*, where you can execute systemctl commands like you would normally expect. For example:
$ systemctl --user list-units
-
@dwardoric could it be because systemd lingering was not enabled for that user?
Anyway, one way I used machinectl before (from the systemd-container package) is:
$ sudo machinectl shell myuser@
This should drop you in a shell for *myuser*, where you can execute systemctl commands like you would normally expect. For example:
$ systemctl --user list-units
@davdr There is a step running "loginctl enable-linger"
Everything is fine when I simply connect as the user (setting "remote_user"). However that only allows one "service setup" per host. Also I try to not hack my way around ansible but so far I fear that this use case is just not existent in its scope.
I hope "become_method: machinectl" will help.
-
@davdr There is a step running "loginctl enable-linger"
Everything is fine when I simply connect as the user (setting "remote_user"). However that only allows one "service setup" per host. Also I try to not hack my way around ansible but so far I fear that this use case is just not existent in its scope.
I hope "become_method: machinectl" will help.
@dwardoric @davdr
I have some internal playbooks where I connect as the regular user, with "become: true" at the top, then "become:false" at each of the tasks that need to run systemd as user. It doesn't work for blocks, only for individual tasks. What I don't know is if it's possible to become a user different than the one you are ssh'ing as. -
@dwardoric @davdr
I have some internal playbooks where I connect as the regular user, with "become: true" at the top, then "become:false" at each of the tasks that need to run systemd as user. It doesn't work for blocks, only for individual tasks. What I don't know is if it's possible to become a user different than the one you are ssh'ing as.@davdr @badnetmask Thanks but I need to run the play multiple times for different users. I can simply split out the user creation into another play but still cannot run the user specific stuff in a loop because this doesn't seem possible AFAIK. Looping over tasks doesn't use remote_user and looping over play_include is not supported.
-
@davdr @badnetmask Thanks but I need to run the play multiple times for different users. I can simply split out the user creation into another play but still cannot run the user specific stuff in a loop because this doesn't seem possible AFAIK. Looping over tasks doesn't use remote_user and looping over play_include is not supported.
@dwardoric @badnetmask and yet this is what https://github.com/linux-system-roles/systemd does, no? Maybe your error is related to another issue?
-
@dwardoric @badnetmask and yet this is what https://github.com/linux-system-roles/systemd does, no? Maybe your error is related to another issue?
@badnetmask @davdr They use become which is not sufficient as we discussed. The root cause seems to be systemd not being able to talk to dbus because dbus will not be started when using become. I'm still investigating machinectl. The sledgehammer method would of course be doing all the symlink magic systemd does via script but I'd like to not have a "hacky, against the system" solution.
-
@badnetmask @davdr They use become which is not sufficient as we discussed. The root cause seems to be systemd not being able to talk to dbus because dbus will not be started when using become. I'm still investigating machinectl. The sledgehammer method would of course be doing all the symlink magic systemd does via script but I'd like to not have a "hacky, against the system" solution.
@dwardoric @badnetmask dbus errors are typically due to lingering not being active, or XDG_RUNTIME_DIR not being set. But you had lingering active already, you said. Welcome to the wonderful world of systemd
It can work, but I’m afraid I can’t advise any more than what I already shared.
If all else fails, maybe you should try the latest Claude/Gemini/ChatPT LLM’s to let them come up with a minimal code example that is equivalent to what you’re trying to do. -
@dwardoric @badnetmask dbus errors are typically due to lingering not being active, or XDG_RUNTIME_DIR not being set. But you had lingering active already, you said. Welcome to the wonderful world of systemd
It can work, but I’m afraid I can’t advise any more than what I already shared.
If all else fails, maybe you should try the latest Claude/Gemini/ChatPT LLM’s to let them come up with a minimal code example that is equivalent to what you’re trying to do.@badnetmask @davdr The really sad thing is that I could solve it with a couple of lines shell-script.
Maybe I should just print out a note at the end of the ansible run to do so.
-
I incentive moved this topic from Uncategorized
