Sorry for the badly formatted emails, I'll use a different provider
thatactually allows sending plain-text emails next time. I could only
noticeafter it was sent.
Yes, I meant it in terms of foreground vs background. For example, not
specifying --scope just pushes it into a service, while with scope, whilethe
process executed is inside the scope unit, the systemd-run process isconnected
to the terminal (without the use of -t) and running in the foreground of the
shell. I am not sure why things are different. I alsonotice the difference is
that in case of --scope, the service manager isnot really the parent process,
and it's just that systemd-run creates a transient scope and places the process
inside it, which is ok, but not surewhy it is different than running it as a
service, or even running the processin the scope unit as a child of the service
manager. I guess I don't reallyunderstand the purpose of scope units properly,
which is why this might be confusing (and this probably relates to how tmux
could have properly moved itself out of the session scope by creating a new one
transparently makinga bus call to systemd). I would appreciate a little
explanation on whatI'm getting wrong and how it is supposed to work.
5. Feb 2018 19:29 by lenn...@poettering.net:
> On Fr, 02.02.18 19:00, worz (> w...@tuta.io> ) wrote:
>
>> Hello, I was wondering why systemd-run --scope needs to be
>> synchronous, it would be nice if someone could explain what happens
>> under the hood, and what prevents it from just putting the process
>> in the scope, and maybe just call the Abandon() method on the slice
>> object's org.freedesktop.systemd1.Scope interface, when for example
>> it is used in combination with --user, the scope is under
>> user@1000.service, so it should be cleaned up as soon as the service
>> manager goes away? Note that there's not a specific usecase to cover
>> here, I am just interested in knowing why it isn't the other way.
>
> Hmm, I am not sure what you precisely mean by "synchronous" in this
> context?
>
> Is this about the bus calls being issued synchronously? We do that so
> that at the time the user-specified command is executed we know for
> sure that the resource limits and other things are in effect on it. If
> we'd asynchronously register the scope and would already execute the
> user's command, then these resource limits would only be applied
> asynchronously, i.e. at some later point too, which is generally not
> what is intended.
>
> Or are you using the word "synchronous" in the context of foreground
> vs. background? I.e. you want your process to be forked into the
> background? That's actually done by default by systemd-run when you
> don't use "--scope", where the executed process is moved into into the
> background as a service.
>
>
> Note that "systemd-run --scope" is little more than an
> execve()-wrapper: if you want the whole thing to be running as a
> shell managed background process, then suffix the line in "&" like you
> would normally do too, when you don't use "systemd-run"...
>
> But then again, I am not sure what you actually are looking for so
> maybe my answers above completely miss the point...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
