Re: [systemd-devel] Why is systemd-run --scope synchronous?

2018-02-06 Thread Simon McVittie 
On Tue, 06 Feb 2018 at 13:09:26 +0100, worz wrote:
> I am not sure why things are different. I also
> notice the difference is that in case of --scope, the service manager is
> not 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 sure
> why it is different than running it as a service, or even running the process
> in the scope unit as a child of the service manager.

If I understand correctly, that's exactly the purpose of scope units:
they allow processes that are not a child of the service manager to be
made visible to the service manager as a unit.

For instance, when Flatpak is run on a system with `systemd --user`,
it puts each instance of a Flatpak app in a scope, even though those
processes need to be children of the Flatpak process so they can inherit
various fds and environment variables from it.

(One notable example of a fd that might be inherited by child processes
is "the controlling terminal".)

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

[systemd-devel] Why is systemd-run --scope synchronous?

2018-02-06 Thread worz 
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

Re: [systemd-devel] Why is systemd-run --scope synchronous?

2018-02-05 Thread Jérémy Rosen 

I would understand the question as :

"why is the foreground/background concept linked to the concept of scope ?"

for most people --scope means "run in the background" which is only a 
side effect of what that command really does.


Maybe there is a need of some doc clarification, or get non-scope runs 
also be foreground and leave backgrounding to the shell...


Anyway, the first step is to understand why there is this difference of 
behaviour in the first place...



On 05/02/2018 14:59, Lennart Poettering wrote:

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



--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why is systemd-run --scope synchronous?

2018-02-05 Thread Lennart Poettering 
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

[systemd-devel] Why is systemd-run --scope synchronous?

2018-02-02 Thread worz 
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.
--Jonathon Kowalski___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel