Re: [systemd-devel] Two questions about logind and seats

[nerdopolis]

On Monday, July 31, 2017 9:41:46 AM EDT Lennart Poettering wrote:
> On Sa, 29.07.17 00:34, nerdopolis (bluescreen_aven...@verizon.net) wrote:
> 
> > Hi
> > 
> > I hope this is the right place to ask this. I have two questions about 
> > logind
> > and seats. 
> > 
> > First, when I attach a 2nd graphics card to seat1, it seems CanMultisession 
> > is
> > set to 0. Is there a way to change that? or is that only supported on 
> > seat0, 
> > that supports the TTYs?
> 
> Yes, this is only supported where VTs are supported, and that is only seat0.
Thanks, It's currently a kernel limitation I assume? I guess I'll worry about 
multiple sessions on non seat0 seats when it _is_ supported.
> 
> > Second, with systemd-run, and maybe a custom '-p PAMName=somepamfile' (if 
> > that
> > is required), is there a way to spawn a process on seat1 if it exits?
> > For seat0 sessions, they for instance can be started by specifying
> 
> > -pTTYPath=/dev/ttyX -pStandardOutput=tty -pStandardError=tty
> > --pStandardInput=tty
> 
> Other seats don't have VTs, hence you cannot run anything on any such
> VTs...
Thanks, I will try to figure out how to get around Weston looking for a TTY
when being run on not-seat0.
> 
> To make use of these other seats you need some kind of terminal
> emulator that knows how to draw to DRM directly, and then you can
> connect your service to that.
> 
> > to systemd-run, which I know only seat0 supports ttys...
> > I try to do weston --seat=seat1 and it says that seat1 does not match the 
> > session-seat.
> > Is there a way to start a process with under a specific session-seat?
> 
> Well, I don't know weston that well, but presumably you are invoking
> it from a session that is attached to seat0, and it doesn't like that
> you try to run it on a different seat then, which makes a ton of sense
> to complain about. Contact the weston folks for help on this.
> 
Thanks I figured this one out, I didn't know I could change the session-seat by
exporting XDG_SEAT before calling systemd-run, I wasn't aware that
pam-systemd.so would _read_ the variable too.
> Lennart
> 
> 
Thanks for the assistance!

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

Re: [systemd-devel] systemd/hostnamed: setting the hostname and using it in the DHCP Discover

[Andrey Yurovsky]

On Mon, Jul 31, 2017 at 9:27 AM, J Decker  wrote:
> There's an option under [dhcp] section
> https://www.freedesktop.org/software/systemd/man/systemd.network.html
>
> SendHostname=
> When true (the default), the machine's hostname will be sent to the DHCP
> server.
>
> UseHostname=
> When true (the default), the hostname received from the DHCP server will be
> set as the transient hostname of the system
>
> Hostname=
> Use this value for the hostname which is sent to the DHCP server, instead of
> machine's hostname.
>
>
> would think if you set your name there it won't matter what /etc/hostname
> is?

Yeah, that's the workaround I'm currently using and it does work (set
the desired string in Hostname=, leave the rest as defaults), however
what Lennart suggested is more thorough as the actual hostname will be
set to what I need and I won't be swapping or editing my .network
files. In my case the hostname is partially based on the MAC of this
fixed Ethernet interface so it's a safe bet to use udev to trigger
settings things up.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd/hostnamed: setting the hostname and using it in the DHCP Discover

[J Decker]

On Mon, Jul 31, 2017 at 7:38 AM, Andrey Yurovsky  wrote:

> On Mon, Jul 31, 2017 at 7:24 AM, Lennart Poettering
>  wrote:
> > On Fr, 28.07.17 12:08, Andrey Yurovsky (yurov...@gmail.com) wrote:
> >
> >> I have an embedded target where the hostname is expected to be a
> >> string derived in part from the MAC address of an Ethernet interface.
> >> I've been looking at how to properly set the system's hostname and
> >> also have systemd-networkd use it in the DHCP request it sends out,
> >> however there seems to be an order of operations issue.
> >>
> >> 1. in systemd/core/main.c the /etc/hostname contents are
> unconditionally read
> >> 2. I can add a service that uses the special network-pre.target to
> >> override /etc/hostname with my generated string and I see that while
> >> the initial string is pickedup by systemd, the new hostname will in
> >> fact be used
> >> 3. I then have a .network file specifying DHCP on that Ethernet
> interface
> >>
> >> But then on initial boot I see that the DHCP Discover coming out has
> >> option 12 set to the original hostname that systemd picked up in
> >> main.c, even though the network-pre.target caused my unit to run. I
> >> can then reboot the system and this time main.c picks up the "new"
> >> hostname and option 12 is indeed set to this.
> >>
> >> One workaround I found was to have my unit write the Hostname= option
> >> to the .network file but that seems like the wrong approach.
> >>
> >> Is there a correct way to replace or otherwise set the hostname and
> >> have systemd use it from the beginning and ensure that the DHCP client
> >> specifies it in option 12?
> >
> > Hmm, I am not sure I follow. Do you want the hostname to be "sticky"?
> > i.e. if you boot up once, and your special hostname is not initialized
> > yet, you initialize from whatever the MAC address is, and then store
> > it to /etc/hostname, and from that point on and for all future boots
> > it's supposed to stay fixed? Or do you want it to be fully
> > dynamic: as soon as an ethernet device shows up, set the hostname,
> > and when no device has shown up the hostname should remain
> > uninitialized, and on subsequent boot everything starts from fresh,
> > with no previous data?
>
> Sorry, what I mean is the hostname is "sticky" but is always the same
> (there's just the one built-in Ethernet interface, nothing is
> dynamic), the trick is I always want that generated hostname used and
> I never want to see a DHCP Discover go out with a default hostname
> that isn't this generated string (it's a bit off but is meant to
> maintain expected behavior from this device).
>
>
There's an option under [dhcp] section
https://www.freedesktop.org/software/systemd/man/systemd.network.html

SendHostname=
When true (the default), the machine's hostname will be sent to the DHCP
server.

UseHostname=
When true (the default), the hostname received from the DHCP server will be
set as the transient hostname of the system

Hostname=
Use this value for the hostname which is sent to the DHCP server, instead
of machine's hostname.


would think if you set your name there it won't matter what /etc/hostname
is?

>
> > Under the assumption you want the latter: just drop /etc/hostname, so
> > that no static hostname is managed by systemd/hostnamed. In this case
> > the system will boot up with the fallback hostname (which is
> > "localhost" unless your distro overrides that at compile time). Then,
> > add a udev rule that is run when an interface shows up, and that
> > changes the hostname as necessary, maybe by invoking the
> > /usr/bin/hostname binary.
>
> I didn't think of that, thank you! That makes a lot of sense.
>
> > The DHCP client in networkd will query the hostname the instant it
> > starts setting up the DHCP session. It will use whatever is set at
> > that point in time. Hence, if you set the hostname from the udev rule
> > things should be properly race-free as networkd will only take
> > possession of any interface after the udev rule ran, and hence will
> > necessarily initialize its DHCP client at a point in time the hostname
> > is set to what you want it to be set to.
>
> Got it. Thank you for taking the time to answer my weird question, I
> really appreciate it.
> ___
> 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

Re: [systemd-devel] sd-bus example code for SetLinkDNS()

[Lennart Poettering]

On Di, 25.07.17 13:29, Tilman Baumann (til...@baumann.name) wrote:

> Little follow-up question. What would you say is best practice for a vpn
> client?
> 
> - Add commandline option --update-systemd-resolved or so
> - Autodetect existence of the interface and just do it? (How?)

Just issue the bus commands, and if you get a service not found error back
use the traditional way. If resolved is around it should be used, and
it it isn't then it shouldn't be used... I think making the user
configure resolved usage at two places is just intransparent and makes
things harder for the user.

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] systemd-234 automount fails

[Lennart Poettering]

On Do, 27.07.17 12:27, Vlad (vo...@vovan.nl) wrote:

> Hello,
> 
> Autogenerated from fstab mount unit fails, the relevant fstab entry:
> UUID=xx   /mnt/data  btrfs  
> noatime,autodefrag,discard,subvol=data,nofail,noauto,x-systemd.automount  
>  
> 0 0
> 
> >From log
> Jul 27 12:09:15 xxx systemd[1]: mnt-data.automount: Got automount
> request for /mnt/data, triggered by 2045 (ls)
> Jul 27 12:09:15 xxx systemd[1]: Mounting /mnt/data...
> Jul 27 12:09:15 xxx systemd[1]: mnt-data.mount: Mount process exited,
> code=exited status=32
> Jul 27 12:09:15 xxx systemd[1]: Failed to mount /mnt/data.
> Jul 27 12:09:15 xxx systemd[1]: mnt-data.mount: Unit entered failed state.
> 
> 
> Works fine with systemd versions < 234.


Hmm, /bin/mount returns 32, which means "mount failure" according to
its documentation...

If you issue "mount UUID= /mnt/data
btrfsnoatime,autodefrag,discard,subvol=data,nofail,noauto," on the
shell, does it work then?

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] systemd/hostnamed: setting the hostname and using it in the DHCP Discover

[Andrey Yurovsky]

On Mon, Jul 31, 2017 at 7:24 AM, Lennart Poettering
 wrote:
> On Fr, 28.07.17 12:08, Andrey Yurovsky (yurov...@gmail.com) wrote:
>
>> I have an embedded target where the hostname is expected to be a
>> string derived in part from the MAC address of an Ethernet interface.
>> I've been looking at how to properly set the system's hostname and
>> also have systemd-networkd use it in the DHCP request it sends out,
>> however there seems to be an order of operations issue.
>>
>> 1. in systemd/core/main.c the /etc/hostname contents are unconditionally read
>> 2. I can add a service that uses the special network-pre.target to
>> override /etc/hostname with my generated string and I see that while
>> the initial string is pickedup by systemd, the new hostname will in
>> fact be used
>> 3. I then have a .network file specifying DHCP on that Ethernet interface
>>
>> But then on initial boot I see that the DHCP Discover coming out has
>> option 12 set to the original hostname that systemd picked up in
>> main.c, even though the network-pre.target caused my unit to run. I
>> can then reboot the system and this time main.c picks up the "new"
>> hostname and option 12 is indeed set to this.
>>
>> One workaround I found was to have my unit write the Hostname= option
>> to the .network file but that seems like the wrong approach.
>>
>> Is there a correct way to replace or otherwise set the hostname and
>> have systemd use it from the beginning and ensure that the DHCP client
>> specifies it in option 12?
>
> Hmm, I am not sure I follow. Do you want the hostname to be "sticky"?
> i.e. if you boot up once, and your special hostname is not initialized
> yet, you initialize from whatever the MAC address is, and then store
> it to /etc/hostname, and from that point on and for all future boots
> it's supposed to stay fixed? Or do you want it to be fully
> dynamic: as soon as an ethernet device shows up, set the hostname,
> and when no device has shown up the hostname should remain
> uninitialized, and on subsequent boot everything starts from fresh,
> with no previous data?

Sorry, what I mean is the hostname is "sticky" but is always the same
(there's just the one built-in Ethernet interface, nothing is
dynamic), the trick is I always want that generated hostname used and
I never want to see a DHCP Discover go out with a default hostname
that isn't this generated string (it's a bit off but is meant to
maintain expected behavior from this device).

> Under the assumption you want the latter: just drop /etc/hostname, so
> that no static hostname is managed by systemd/hostnamed. In this case
> the system will boot up with the fallback hostname (which is
> "localhost" unless your distro overrides that at compile time). Then,
> add a udev rule that is run when an interface shows up, and that
> changes the hostname as necessary, maybe by invoking the
> /usr/bin/hostname binary.

I didn't think of that, thank you! That makes a lot of sense.

> The DHCP client in networkd will query the hostname the instant it
> starts setting up the DHCP session. It will use whatever is set at
> that point in time. Hence, if you set the hostname from the udev rule
> things should be properly race-free as networkd will only take
> possession of any interface after the udev rule ran, and hence will
> necessarily initialize its DHCP client at a point in time the hostname
> is set to what you want it to be set to.

Got it. Thank you for taking the time to answer my weird question, I
really appreciate it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd/hostnamed: setting the hostname and using it in the DHCP Discover

[Lennart Poettering]

On Fr, 28.07.17 12:08, Andrey Yurovsky (yurov...@gmail.com) wrote:

> I have an embedded target where the hostname is expected to be a
> string derived in part from the MAC address of an Ethernet interface.
> I've been looking at how to properly set the system's hostname and
> also have systemd-networkd use it in the DHCP request it sends out,
> however there seems to be an order of operations issue.
> 
> 1. in systemd/core/main.c the /etc/hostname contents are unconditionally read
> 2. I can add a service that uses the special network-pre.target to
> override /etc/hostname with my generated string and I see that while
> the initial string is pickedup by systemd, the new hostname will in
> fact be used
> 3. I then have a .network file specifying DHCP on that Ethernet interface
> 
> But then on initial boot I see that the DHCP Discover coming out has
> option 12 set to the original hostname that systemd picked up in
> main.c, even though the network-pre.target caused my unit to run. I
> can then reboot the system and this time main.c picks up the "new"
> hostname and option 12 is indeed set to this.
> 
> One workaround I found was to have my unit write the Hostname= option
> to the .network file but that seems like the wrong approach.
> 
> Is there a correct way to replace or otherwise set the hostname and
> have systemd use it from the beginning and ensure that the DHCP client
> specifies it in option 12?

Hmm, I am not sure I follow. Do you want the hostname to be "sticky"?
i.e. if you boot up once, and your special hostname is not initialized
yet, you initialize from whatever the MAC address is, and then store
it to /etc/hostname, and from that point on and for all future boots
it's supposed to stay fixed? Or do you want it to be fully
dynamic: as soon as an ethernet device shows up, set the hostname,
and when no device has shown up the hostname should remain
uninitialized, and on subsequent boot everything starts from fresh,
with no previous data?

Under the assumption you want the latter: just drop /etc/hostname, so
that no static hostname is managed by systemd/hostnamed. In this case
the system will boot up with the fallback hostname (which is
"localhost" unless your distro overrides that at compile time). Then,
add a udev rule that is run when an interface shows up, and that
changes the hostname as necessary, maybe by invoking the
/usr/bin/hostname binary.

The DHCP client in networkd will query the hostname the instant it
starts setting up the DHCP session. It will use whatever is set at
that point in time. Hence, if you set the hostname from the udev rule
things should be properly race-free as networkd will only take
possession of any interface after the udev rule ran, and hence will
necessarily initialize its DHCP client at a point in time the hostname
is set to what you want it to be set to.

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] Requirements for successful mounting of RootImage?

[Lennart Poettering]

On So, 30.07.17 13:58, Topi Miettinen (toiwo...@gmail.com) wrote:

> Hey,
> 
> I have this test.service unit:
> [Unit]
> 
> [Install]
> WantedBy=multi-user.target
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/ls -lR
> RootImage=/fs
> MountAPIVFS=no

Any reason you turn this off? This is likely to break sooner or later,
so it would make a ton of sense to test things first with it left on,
before checking anything else.

> 
> The file /fs has a MBR partition table:
> Disk /dev/loop0: 1.1 MiB, 1192960 bytes, 2330 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x3990f3e6
> 
> Device   Boot Start   End Sectors  Size Id Type
> /dev/loop0p1 *   34  23292296  1.1M 83 Linux

That should work. See if "systemd-nspawn -i" can get a shell in it. If
so, RootImage= should work too, it uses the same code.

Also, consider invoking /usr/lib/systemd/systemd-dissect on the image
file, it will tell you whether it can make sense of the image, and how
it would mount it.

> In the only partition a squashfs file system containing:
> bin
> bin/ls
> boot
> dev
> etc
> etc/group
> etc/nsswitch.conf
> etc/passwd
> home
> lib
> lib64
> lib64/ld-linux-x86-64.so.2
> lib/libc.so.6
> lib/libdl.so.2
> lib/libpcre.so.3
> lib/libpthread.so.0
> lib/libselinux.so.1
> media
> opt
> proc
> root
> run
> sbin
> srv
> sys
> tmp
> usr
> usr/bin
> usr/lib
> usr/lib64
> usr/lib/x86_64-linux-gnu
> usr/sbin
> var
> var/tmp
> 
> However, starting the service fails with abort:
> Jul 30 13:25:42 machine systemd[1]: Starting test.service...
> Jul 30 13:25:42 machine kernel:  loop0: p1
> Jul 30 13:25:42 machine systemd[1]: test.service: Main process exited,
> code=killed, status=6/ABRT
> Jul 30 13:25:42 machine systemd[1]: Failed to start test.service.
> Jul 30 13:25:42 machine systemd[1]: test.service: Unit entered failed state.
> Jul 30 13:25:42 machine systemd[1]: test.service: Failed with result
> 'signal'.
> 
> It looks like systemd successfully mounts the file system, but then
> suddenly aborts before even looking inside the file system:
> 
> 2761  mount("/dev/loop1p1", "/run/systemd/unit-root", "squashfs",
> MS_NODEV, NULL 
> 2761  <... mount resumed> ) = 0
> 2761  rt_sigprocmask(SIG_UNBLOCK, [ABRT],  
> 2761  <... rt_sigprocmask resumed> NULL, 8) = 0
> 2761  rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
> 2761  getpid( 
> 2761  <... getpid resumed> )= 2761
> 2761  gettid( 
> 2761  <... gettid resumed> )= 2761
> 2761  tgkill(2761, 2761, SIGABRT 
> 2761  <... tgkill resumed> )= 0
> 2761  rt_sigprocmask(SIG_SETMASK, [],  
> 2761  <... rt_sigprocmask resumed> NULL, 8) = 0
> 2761  --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2761,
> si_uid=0} ---
> 2761  +++ killed by SIGABRT +++
> 
> The file system can be mounted by hand with losetup and mount, and
> /bin/ls can be run from chroot. So I think everything should be OK but
> RootImage still does not work and the error messages are useless.
> Perhaps I miss some RootImage requirements? What exactly they are?

They are documented briefly in "systemd-nspawn's" --image= setting.

That said, if systemd actually mounted something, then the image is
fine. Most likely something is simply borked in the namespacing code,
and that is kind hard to debug, because logging is already turned off
at that point. It should be relatively easy to patch that in
temporarily though, i.e. find apply_mount_namespace() in
src/core/execute.c and place a log_open() before the setup_namespace()
invocation, and check if this improves logging for you.

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] Requirements for successful mounting of RootImage?

[Lennart Poettering]

On So, 30.07.17 13:58, Topi Miettinen (toiwo...@gmail.com) wrote:

> Hey,
> 
> I have this test.service unit:
> [Unit]
> 
> [Install]
> WantedBy=multi-user.target
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/ls -lR
> RootImage=/fs
> MountAPIVFS=no

btw, just to mention that, if you want to quickly test something like
this, you can also use:

# systemd-run -p RootImage=/fs /bin/ls -lR

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] Two questions about logind and seats

[Lennart Poettering]

On Sa, 29.07.17 00:34, nerdopolis (bluescreen_aven...@verizon.net) wrote:

> Hi
> 
> I hope this is the right place to ask this. I have two questions about logind
> and seats. 
> 
> First, when I attach a 2nd graphics card to seat1, it seems CanMultisession is
> set to 0. Is there a way to change that? or is that only supported on seat0, 
> that supports the TTYs?

Yes, this is only supported where VTs are supported, and that is only seat0.

> Second, with systemd-run, and maybe a custom '-p PAMName=somepamfile' (if that
> is required), is there a way to spawn a process on seat1 if it exits?
> For seat0 sessions, they for instance can be started by specifying

> -pTTYPath=/dev/ttyX -pStandardOutput=tty -pStandardError=tty
> --pStandardInput=tty

Other seats don't have VTs, hence you cannot run anything on any such
VTs...

To make use of these other seats you need some kind of terminal
emulator that knows how to draw to DRM directly, and then you can
connect your service to that.

> to systemd-run, which I know only seat0 supports ttys...
> I try to do weston --seat=seat1 and it says that seat1 does not match the 
> session-seat.
> Is there a way to start a process with under a specific session-seat?

Well, I don't know weston that well, but presumably you are invoking
it from a session that is attached to seat0, and it doesn't like that
you try to run it on a different seat then, which makes a ton of sense
to complain about. Contact the weston folks for help on this.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev rules: how to get return result after run command

[Guoqing Jiang]

Hello,

Sorry if this is not the right place to raise the question.

I can get return result after run with PROGRAM call, then $result holds
the returned string, but with PROGRAM, I have to use the absolute path
of command.

And sometimes, the command may located in different path for different
distros, so it could cause portable issue. I guess "RUN{builtin}" could be
used to avoid the issue, however I can't figure out how to get the return
value of "RUN{builtin}".

Any advises would be very helpful.

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