[systemd-devel] stacked automounts

[Olaf Hering]

Is there a way to have stacked automounts?
In this example only /d is mounted when /d/l/1/ is accessed:

LABEL=d/d xfs noatime,x-systemd.automount,x-systemd.idle-timeout=22 
1 2
/d/i/1.iso /d/l/1 iso9660 ro,loop,x-systemd.automount,x-systemd.idle-timeout=11 
0 0

In the logs I see:
Set up automount d-l-1.automount.
Unset automount d-l-1.automount.

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] what is the best way to connect to another user's service (when root)?

[Lennart Poettering]

On Do, 23.11.17 22:56, Jeff Solomon (jsolomon8...@gmail.com) wrote:

> Hi,
> 
> More questions about the systemd user service.
> 
> Inside a script running as root, I want to control another user's service.
> 
> I have found two ways to do this:
> 
> systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid=
> systemctl --user ...
> 
> or:
> 
> su -l  -c "XDG_RUNTIME_DIR=/run/user/ systemctl --user
> ..."
> 
> Both work.
> 
> If there a better way to do this?
> 
> My distros aren't recent enough to include "machinectl shell" but is that
> the recommended way now?
> 
> machinectl --uid= shell /bin/systemctl --user ...
> 
> Perhaps there is not enough demand to justify it, but I would love if the
> systemctl command itself had a way to specify that it should communicate
> with a different user's service rather than system service or the calling
> user's service. Something like:
> 
> systemctl --uid= --user ..
> 
> would be awesome.

Hmm, sorry, but this is something we'll are unlikely to support in any
special way. Making privileged code a client of unpriveled user code
like this makes me feel very uncomfortable. Privileged code really
should not transition and block on unprivileged user code likes
this. Philosophically it has this feeling of being the wrong way
round: the unpriv code should ask the priv code what it should do, it
shouldn't be the priv code that asks the unpriv code, in any blocking
way... I mean, the unpriv code can ultimately do whatever it wants,
and priv code should not block on that for good. It's simply the wrong
way round to design such a system, if you follow what i mean.

Usually most usecase like that are better solved by making things
asynchronous notifier based, and make the unpriv code just react to
notifications, instead of synchronous call-ins...

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] what is the best way to connect to another user's service (when root)?

[Jeff Solomon]

On the one hand, I understand your point. On the other hand, there are
three other ways of doing this:

systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid=
systemctl --user ...
su -l  -c "XDG_RUNTIME_DIR=/run/user/ systemctl --user"
machinectl --uid= shell /bin/systemctl --user ...

(I'm assuming the last way actually works. Does it?)

So I thought that my suggestion was an even cleaner way to accomplish the
same thing. I get that you don't want priv code to depend on unpriv code
but systemctl is a command line tool. It's up to the user if they want to
run it that way.






On Fri, Nov 24, 2017 at 5:05 AM, Lennart Poettering 
wrote:

> On Do, 23.11.17 22:56, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
> > Hi,
> >
> > More questions about the systemd user service.
> >
> > Inside a script running as root, I want to control another user's
> service.
> >
> > I have found two ways to do this:
> >
> > systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid=
> > systemctl --user ...
> >
> > or:
> >
> > su -l  -c "XDG_RUNTIME_DIR=/run/user/ systemctl
> --user
> > ..."
> >
> > Both work.
> >
> > If there a better way to do this?
> >
> > My distros aren't recent enough to include "machinectl shell" but is that
> > the recommended way now?
> >
> > machinectl --uid= shell /bin/systemctl --user ...
> >
> > Perhaps there is not enough demand to justify it, but I would love if the
> > systemctl command itself had a way to specify that it should communicate
> > with a different user's service rather than system service or the calling
> > user's service. Something like:
> >
> > systemctl --uid= --user ..
> >
> > would be awesome.
>
> Hmm, sorry, but this is something we'll are unlikely to support in any
> special way. Making privileged code a client of unpriveled user code
> like this makes me feel very uncomfortable. Privileged code really
> should not transition and block on unprivileged user code likes
> this. Philosophically it has this feeling of being the wrong way
> round: the unpriv code should ask the priv code what it should do, it
> shouldn't be the priv code that asks the unpriv code, in any blocking
> way... I mean, the unpriv code can ultimately do whatever it wants,
> and priv code should not block on that for good. It's simply the wrong
> way round to design such a system, if you follow what i mean.
>
> Usually most usecase like that are better solved by making things
> asynchronous notifier based, and make the unpriv code just react to
> notifications, instead of synchronous call-ins...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Question about service dependency handling in systemd-228

[Bao Nguyen]

Hello everyone,

I would like to have a question regarding to the building dependency and
cycle dependency handling on systemd-228. In my system, I have some socket
and service files, it has a cycle on socket target, when I run on
system-228, systemd-228 throws

[   40.358582] systemd[1]: Set hostname to .
[   41.154231] systemd[1]: nss-lookup.target: Dependency
Before=nss-lookup.target dropped
[   41.297229] systemd[1]: sockets.target: Found ordering cycle on
sockets.target/start
[   41.297236] systemd[1]: sockets.target: Found dependency on
asi-My-5101.socket/start
[   41.297239] systemd[1]: sockets.target: Found dependency on
My-sshd.target/start
[   41.297241] systemd[1]: sockets.target: Found dependency on
My-syncd.service/start
[   41.297244] systemd[1]: sockets.target: Found dependency on
My-nfs-client.service/start
[   41.297246] systemd[1]: sockets.target: Found dependency on
My-handling.service/start
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5101
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5010
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5111
[ SKIP ] Ordering cycle found, skipping asi-vsftpd-MyIO_2.socket
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5110
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5002
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5100
[ SKIP ] Ordering cycle found, skipping Remo...ell Facilities Activation
Socket
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5011
[ SKIP ] Ordering cycle found, skipping My sshd target


It said that there is an ordering on the sockets.target, then break the
cycle and SKIP randomly starting other service => the system cannot start.
However I did not meet the same issue on systemd-210 with the same my
services and sockets. Systemd-210 does not break and skip, and my system
can start well.

My question is if there are any significant different about building tree
dependency and handling cycle dependency between systemd-210 and
systemd-228 that can lead to my current situation? I have checked the
change log, source code but not found any useful info

And what does the message "nss-lookup.target: Dependency
Before=nss-lookup.target dropped" mean? I do not see it in systemd-210.

Many thanks for your support,
Best regards,
Naru
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel