Re: [systemd-devel] systemd-networkd bring interface up without link

[Andrei Borzenkov]

07.05.2019 4:22, Matt Zagrabelny пишет:
> Greetings,
> 
> I'm using Debian Buster with systemd 241-3.
> 
> I have a computer (server) that is running isc-dhcpd and I have a hardwired
> interface with static addressing on the computer:
> 
> $ cat /etc/systemd/network/eth-router.network
> [Match]
> MACAddress=00:01:c0:1e:25:dd
> 
> [Network]
> Address=172.20.20.1/24
> 
> $ ip a
> [...]
> 2: enp4s0:  mtu 1500 qdisc mq state DOWN
> group default qlen 1000
> link/ether 00:01:c0:1e:25:dd brd ff:ff:ff:ff:ff:ff
> [...]
> 
> When I connect another computer (laptop) to the server via an ethernet
> cable, the interface is brought up:
> 
> $ ip a
> [...]
> 2: enp4s0:  mtu 1500 qdisc mq state UP
> group default qlen 1000
> link/ether 00:01:c0:1e:25:dd brd ff:ff:ff:ff:ff:ff
> inet 172.20.20.1/24 brd 172.20.20.255 scope global enp4s0
>valid_lft forever preferred_lft forever
> inet6 fe80::201:c0ff:fe1e:25dd/64 scope link
>valid_lft forever preferred_lft forever
> 
> However isc-dhcpd is unhappy about trying to answer lease requests from an
> interface that doesn't have addressing - as isc-dhcpd has already started
> from boot and the interface is brought up when a client plugs into the
> ethernet cable:
> 
> Apr 25 18:14:48 zion dhcpd[651]: No subnet declaration for enp4s0 (no IPv4
> addresses).
> Apr 25 18:14:48 zion dhcpd[651]: ** Ignoring requests on enp4s0.  If this
> is not what
> Apr 25 18:14:48 zion dhcpd[651]:you want, please write a subnet
> declaration
> Apr 25 18:14:48 zion dhcpd[651]:in your dhcpd.conf file for the network
> segment
> Apr 25 18:14:48 zion dhcpd[651]:to which interface enp4s0 is attached.
> **
> Apr 25 18:14:48 zion dhcpd[651]:
> 
> If I restart isc-dhcpd after the enp4s0 has an address, then my client
> computer (laptop) is able to request and get an address:
> 
> May 06 19:46:12 zion dhcpd[3654]: Server starting service.
> May 06 19:46:14 zion isc-dhcp-server[3641]: Starting ISC DHCPv4 server:
> dhcpd.
> May 06 19:46:14 zion systemd[1]: Started LSB: DHCP server.
> May 06 19:46:16 zion dhcpd[3654]: DHCPDISCOVER from c4:65:16:04:24:92 via
> enp4s0
> May 06 19:46:17 zion dhcpd[3654]: DHCPOFFER on 172.20.20.181 to
> c4:65:16:04:24:92 (tombstone) via enp4s0
> May 06 19:46:17 zion dhcpd[3654]: DHCPREQUEST for 172.20.20.181
> (172.20.20.1) from c4:65:16:04:24:92 (tombstone) via enp4s0
> May 06 19:46:17 zion dhcpd[3654]: DHCPACK on 172.20.20.181 to
> c4:65:16:04:24:92 (tombstone) via enp4s0
> 
> What is the proper way to handle this issue?
> 

I guess ISC DHCP support community would be better place to answer this.

> I also use the same isc-dhcpd to serve addresses out of a wifi interface,
> so I don't think I could have the service start up after a *.network file
> is activated - if that is the right terminology.
> 
> Is there a way to have systemd-network assign addressing to an interface
> without the link being up?
> 

man systemd.network

   ConfigureWithoutCarrier=
   A boolean. Allows networkd to configure a specific link even
if it has no
   carrier. Defaults to false.

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

Re: [systemd-devel] EFI loader partition unknown

[Chris Murphy]

On Mon, May 6, 2019 at 10:26 AM Chris Murphy  wrote:

> Looks like it wants to mount root, but it's already mounted and hence
> busy. Btrfs lets you do that, ext4 and XFS don't, they need to be bind
> mounted instead. Just a guess.

Nope, that's not correct. I can mount /dev/vda2 on /mnt just fine.

/dev/vda2 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[snip]
/dev/vda2 on /mnt type xfs (rw,relatime,seclabel,attr2,inode64,noquota)



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

[systemd-devel] systemd-networkd bring interface up without link

[Matt Zagrabelny]

Greetings,

I'm using Debian Buster with systemd 241-3.

I have a computer (server) that is running isc-dhcpd and I have a hardwired
interface with static addressing on the computer:

$ cat /etc/systemd/network/eth-router.network
[Match]
MACAddress=00:01:c0:1e:25:dd

[Network]
Address=172.20.20.1/24

$ ip a
[...]
2: enp4s0:  mtu 1500 qdisc mq state DOWN
group default qlen 1000
link/ether 00:01:c0:1e:25:dd brd ff:ff:ff:ff:ff:ff
[...]

When I connect another computer (laptop) to the server via an ethernet
cable, the interface is brought up:

$ ip a
[...]
2: enp4s0:  mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 00:01:c0:1e:25:dd brd ff:ff:ff:ff:ff:ff
inet 172.20.20.1/24 brd 172.20.20.255 scope global enp4s0
   valid_lft forever preferred_lft forever
inet6 fe80::201:c0ff:fe1e:25dd/64 scope link
   valid_lft forever preferred_lft forever

However isc-dhcpd is unhappy about trying to answer lease requests from an
interface that doesn't have addressing - as isc-dhcpd has already started
from boot and the interface is brought up when a client plugs into the
ethernet cable:

Apr 25 18:14:48 zion dhcpd[651]: No subnet declaration for enp4s0 (no IPv4
addresses).
Apr 25 18:14:48 zion dhcpd[651]: ** Ignoring requests on enp4s0.  If this
is not what
Apr 25 18:14:48 zion dhcpd[651]:you want, please write a subnet
declaration
Apr 25 18:14:48 zion dhcpd[651]:in your dhcpd.conf file for the network
segment
Apr 25 18:14:48 zion dhcpd[651]:to which interface enp4s0 is attached.
**
Apr 25 18:14:48 zion dhcpd[651]:

If I restart isc-dhcpd after the enp4s0 has an address, then my client
computer (laptop) is able to request and get an address:

May 06 19:46:12 zion dhcpd[3654]: Server starting service.
May 06 19:46:14 zion isc-dhcp-server[3641]: Starting ISC DHCPv4 server:
dhcpd.
May 06 19:46:14 zion systemd[1]: Started LSB: DHCP server.
May 06 19:46:16 zion dhcpd[3654]: DHCPDISCOVER from c4:65:16:04:24:92 via
enp4s0
May 06 19:46:17 zion dhcpd[3654]: DHCPOFFER on 172.20.20.181 to
c4:65:16:04:24:92 (tombstone) via enp4s0
May 06 19:46:17 zion dhcpd[3654]: DHCPREQUEST for 172.20.20.181
(172.20.20.1) from c4:65:16:04:24:92 (tombstone) via enp4s0
May 06 19:46:17 zion dhcpd[3654]: DHCPACK on 172.20.20.181 to
c4:65:16:04:24:92 (tombstone) via enp4s0

What is the proper way to handle this issue?

I also use the same isc-dhcpd to serve addresses out of a wifi interface,
so I don't think I could have the service start up after a *.network file
is activated - if that is the right terminology.

Is there a way to have systemd-network assign addressing to an interface
without the link being up?

Thanks for any help!

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

Re: [systemd-devel] EFI loader partition unknown

[Chris Murphy]

Waiting for device (parent + 2 partitions) to appear...
Found writable 'root' partition (UUID
87d5a92987174be9ad216482074d1409) of type xfs without verity on
partition #2 (/dev/vda2)
Found writable 'esp' partition (UUID b5aa8c29b4ab4021b2b22326860bda97)
of type vfat on partition #1 (/dev/vda1)
[Detaching after fork from child process 8612]
Successfully forked off '(sd-dissect)' as PID 8612.
Mounting xfs on /tmp/dissect-h21Wp5 (MS_RDONLY|MS_NODEV "")...
Failed to mount /dev/vda2 (type xfs) on /tmp/dissect-h21Wp5
(MS_RDONLY|MS_NODEV ""): Device or resource busy
Failed to mount dissected image: Device or resource busy
Failed to read /etc/hostname: No such file or directory
/etc/machine-id file is empty.
(sd-dissect) failed with exit status 1.
Failed to acquire image metadata: Protocol error
[Inferior 1 (process 8608) exited with code 01]
(gdb) quit


Looks like it wants to mount root, but it's already mounted and hence
busy. Btrfs lets you do that, ext4 and XFS don't, they need to be bind
mounted instead. Just a guess.

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

Re: [systemd-devel] unable to fully halt system

[Matt Zagrabelny]

On Wed, May 1, 2019 at 11:02 PM Mantas Mikulėnas  wrote:

> On Thu, May 2, 2019, 04:19 Matt Zagrabelny  wrote:
>
>> Greetings,
>>
>> I'm hitting an issue and I'm not quite sure the best place to debug it.
>>
>> I've got a fresh install of Debian Buster, systemd 241-3.
>>
>> and when I run "sudo halt", I'm expecting the system to power off, but it
>> hangs at:
>>
>> [ OK ] Reached target Final Step.
>>Starting Halt...
>> [...] Failed to remount '/' read-only: Device or resource busy
>>
>> and the system just hangs there. The root filesystem is btrfs.
>>
>> Any ideas how best to get the system to power off the whole way?
>>
>
> Use `sudo poweroff` instead. Running `halt` will indeed only halt the
> system.
>

Thanks for the help, Dave and Mantas. It is appreciated.

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

Re: [systemd-devel] EFI loader partition unknown

[Lennart Poettering]

On So, 05.05.19 17:02, Chris Murphy (li...@colorremedies.com) wrote:

> > > blkid reports:
> > > /dev/vda1: SEC_TYPE="msdos" UUID="927C-932C" TYPE="vfat"
> > > PARTLABEL="EFI System Partition"
> > > PARTUUID="0e3a48c0-3f1b-4ca7-99f4-32fd1d831cdc"
> > >
> > > gdisk reports:
> > > Partition number (1-3): 1
> > > Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
> > > Partition unique GUID: 0E3A48C0-3F1B-4CA7-99F4-32FD1D831CDC
> > > First sector: 2048 (at 1024.0 KiB)
> > > Last sector: 411647 (at 201.0 MiB)
> > > Partition size: 409600 sectors (200.0 MiB)
> > > Attribute flags: 
> > > Partition name: 'EFI System Partition'
> > >
> >
> > What does '/usr/lib/systemd/systemd-dissect /dev/vda' say?
>
>
> [chris@localhost ~]$ sudo /usr/lib/systemd/systemd-dissect /dev/vda
> Found writable 'root' partition (UUID
> 87d5a92987174be9ad216482074d1409) of type xfs without verity on
> partition #2 (/dev/vda2)
> Found writable 'esp' partition (UUID b5aa8c29b4ab4021b2b22326860bda97)
> of type vfat on partition #1 (/dev/vda1)
> Failed to acquire image metadata: Protocol error

There's something in your partition table that throws the dissector
off. Next step would be to debug this with gdb, i.e. run:

sudo SYSTEMD_LOG_LEVEL=debug gdb ---args /usr/lib/systemd/systemd-dissect 
/dev/vda

after installing debug symbols, then step through this, and figure out
where this issue happens.

Or in other words: this is a bug, and needs to be tracked down like a
bug hence...


Lennart

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

Re: [systemd-devel] Systemd service and structured logging

[Lennart Poettering]

On Fr, 03.05.19 11:09, Thomas Güttler (guettl...@thomas-guettler.de) wrote:

> I have a systemd service which is of type "simple".
>
> I want my service to log key-value pairs.
>
> Is there a way to use structured logs with systemd?

Depend on your programming language.

In C, sd_journal_send()/sd_journal_sendv() is the API of choice.

https://www.freedesktop.org/software/systemd/man/sd_journal_print.html

That said, there are other C APIs that speak the same protocol. For
example, glib's logging logic will magically use systemd's native
logging protocol if it is available.

If you use a different programming language, there are bindings for
the same protocol for various languages around (including python).

> It would be great of systemd could read the string as json.

JSON is complex to index properly. systemd supports a simpler
"environment-variable-like" format instead. For details see link
above.

Lennart

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

Re: [systemd-devel] Systemd service and structured logging

[Vincent Dahmen]

Hi there,
I wrote my first response not to the list, so sry for the double.

> On the other hand, JSON parsing might be a useful addition to journald, as
> apparently "@cee: {}" is a quite common syslog format.
JSON is meant to be parsed by an application and I am not sure if
logging (specially for humans) is the way to go here...

> I would suggest implementing support for multiple logging backends – don't
> call journald APIs directly and don't print out JSON directly, but have
> abstract functions such as log_info(text, **kvpairs) or something such.
> That's what many programs already do for file/syslog/journal backends.
> (Possibly just use the `logging` module in python?)
I would highly suggest to use that module.
There is even a ready to go logger[0] for journald available.

Best
Vincent

[0] 
https://stackoverflow.com/questions/34588421/how-to-log-to-journald-systemd-via-python


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] Systemd service and structured logging

[Mantas Mikulėnas]

On Mon, May 6, 2019 at 10:09 AM Thomas Güttler 
wrote:

> Am 03.05.19 um 13:29 schrieb Jérémy ROSEN:
> > if you want the whole power of structured logs, you need to use the
> journald API
>

On the other hand, JSON parsing might be a useful addition to journald, as
apparently "@cee: {}" is a quite common syslog format.


> > I am not sure in what language your program is written, but if you are
> using C, it's pretty trivial to do
> > (and i'm pretty sure most bindings are trivial to use too)
>
>
> Yes, this would work.
>
>
> Solution 1:
>   My service (written Python) uses the journald API.
>   Disadvantage: My script can't be run under a different environment
> (without journald)
>
>
I would suggest implementing support for multiple logging backends – don't
call journald APIs directly and don't print out JSON directly, but have
abstract functions such as log_info(text, **kvpairs) or something such.
That's what many programs already do for file/syslog/journal backends.
(Possibly just use the `logging` module in python?)

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

Re: [systemd-devel] Systemd service and structured logging

[Jérémy ROSEN]

you can have both your app and the wrapper launched by a shell, and have
systemd monitor the shell...

Le lun. 6 mai 2019 à 09:09, Thomas Güttler  a
écrit :

> Am 03.05.19 um 13:29 schrieb Jérémy ROSEN:
> > if you want the whole power of structured logs, you need to use the
> journald API
> > I am not sure in what language your program is written, but if you are
> using C, it's pretty trivial to do
> > (and i'm pretty sure most bindings are trivial to use too)
>
>
> Yes, this would work.
>
>
> Solution 1:
>   My service (written Python) uses the journald API.
>   Disadvantage: My script can't be run under a different environment
> (without journald)
>
>
>
> Solution 2:
>   I let my service write json to stdout and a wrapper collects these lines
> and the wrapper uses the journald API.
>   Disadvantage: Systemd is monitoring the wrapper, not the real service.
> Signal handling for stopping and restarting
>   is not direct from systemd to service.
>
>
> The perfect solution is not found yet.
>
> Regards,
>Thomas Güttler
>
>
> --
> Thomas Guettler http://www.thomas-guettler.de/
> I am looking for feedback:
> https://github.com/guettli/programming-guidelines
>


-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

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

Re: [systemd-devel] Systemd service and structured logging

[Thomas Güttler]

Am 03.05.19 um 13:29 schrieb Jérémy ROSEN:

if you want the whole power of structured logs, you need to use the journald API
I am not sure in what language your program is written, but if you are using C, 
it's pretty trivial to do
(and i'm pretty sure most bindings are trivial to use too)



Yes, this would work.


Solution 1:
 My service (written Python) uses the journald API.
 Disadvantage: My script can't be run under a different environment (without 
journald)



Solution 2:
 I let my service write json to stdout and a wrapper collects these lines and 
the wrapper uses the journald API.
 Disadvantage: Systemd is monitoring the wrapper, not the real service. Signal 
handling for stopping and restarting
 is not direct from systemd to service.


The perfect solution is not found yet.

Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel