Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Matthew Hall]

On Thu, Nov 12, 2015 at 10:37:56AM +0100, Lennart Poettering wrote:
> Since time began eth* is where the kernel automatically picked iface
> names from. If you want to assign your own names go for some other
> namespace, or be prepared to race against the kernel, and deal with
> it.
> 
> Lennart

Again, this logic worked well when the level of dynamism was lower.

But now the level of dynamism is higher and different principles should apply.

You aren't thinking very much about how it will work for newer users.

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

[systemd-devel] Network/Block device PCI Slot map utility

[jharg93]

I've developed a script that will display useful information for all block
and network devices.  It displays the PCI slot number, SR-IOV physical device,
model/vendor, driver, and NIC port number. The script will also display the 
bay and slot number for installed Dell PCIe-SSDs.

The script requires ipmitool and biosdecode utilities.

Examples:
= sda
  Device: /sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0
  Vendor: ATA
  Model: ST3500630NS
  Driver: ata_piix
= sdb
  Device: 
/sys/devices/pci:00/:00:1a.7/usb1/1-4/1-4:1.0/host14/target14:0:0/14:0:0:0
  Vendor: Verbatim
  Model: STORE N GO 
  Driver: usb_storage
= sr0
  Device: /sys/devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0
  Vendor: Optiarc
  Model: DVD+-RW AD-5560A
  Driver: ata_piix
= eth0
  Device: /sys/devices/pci:00/:00:19.0
  Driver: e1000e
= eth1
  Device: /sys/devices/pci:00/:00:01.0/:01:00.0
  Driver: e1000e
  Slot Entry 9: ID 01:00, slot number 10
  PORT: 1
= eth2
  Device: /sys/devices/pci:00/:00:01.0/:01:00.1
  Driver: e1000e
  Slot Entry 9: ID 01:00, slot number 10
  PORT: 2


another system:
= sda
  Device: 
/sys/devices/pci:00/:00:02.2/:02:00.0/host0/target0:2:0/0:2:0:0
  Vendor: DELL   
  Model: PERC H710P 
  Driver: megaraid_sas
  :02:00.0 Label: Integrated RAID
  :02:00.0 SMBIOS Index: 4
= eno1
  Device: /sys/devices/pci:00/:00:01.0/:01:00.0
  DevPort: 0
  Driver: bnx2x
  DCM: 1001009d7F1402009d7F2101009d7F2502009d7F32010089154301008915
p1_1
  :01:00.0 Label: NIC1
  :01:00.0 ACPI Index: 1
= eno2
  Device: /sys/devices/pci:00/:00:01.0/:01:00.1
  DevPort: 0
  Driver: bnx2x
  DCM: 1001009d7F1402009d7F2101009d7F2502009d7F32010089154301008915
p2_1
  :01:00.1 Label: NIC2
  :01:00.1 ACPI Index: 2
= eno3
  Device: /sys/devices/pci:00/:00:01.0/:01:00.2
  DevPort: 0
  Driver: bnx2x
  DCM: 1001009d7F1402009d7F2101009d7F2502009d7F32010089154301008915
p3_1
  :01:00.2 Label: NIC3
  :01:00.2 ACPI Index: 3
= eno4
  Device: /sys/devices/pci:00/:00:01.0/:01:00.3
  DevPort: 0
  Driver: bnx2x
  DCM: 1001009d7F1402009d7F2101009d7F2502009d7F32010089154301008915
p4_1
  :01:00.3 Label: NIC4
  :01:00.3 ACPI Index: 4
= eno5
  Device: /sys/devices/pci:00/:00:01.0/:01:00.4
  DevPort: 0
  Driver: bnx2x
  DCM: 1001009d7F1402009d7F2101009d7F2502009d7F32010089154301008915
p1_2
  :01:00.4 Label: NIC5
  :01:00.4 ACPI Index: 5
= eno6
  Device: /sys/devices/pci:00/:00:01.0/:01:00.5
  DevPort: 0
  Driver: bnx2x
  DCM: 1001009d7F1402009d7F2101009d7F2502009d7F32010089154301008915
p2_2
  :01:00.5 Label: NIC6
  :01:00.5 ACPI Index: 6
= enp4s0
  Device: /sys/devices/pci:00/:00:03.0/:04:00.0
  DevPort: 0
  Driver: mlx4_core
  Level: 1   Slot Entry 15: ID 04:00, slot number 3
  PORT: 1
  DCM: 1001C52001C5
p1_1
p2_1
  :00:03.0 Label: SLOT 3
  :00:03.0 ACPI Index: 17
= enp4s0d1
  Device: /sys/devices/pci:00/:00:03.0/:04:00.0
  DevPort: 1
  Driver: mlx4_core
  Level: 1   Slot Entry 15: ID 04:00, slot number 3
  PORT: 2
  DCM: 1001C52001C5
p1_1
p2_1
  :00:03.0 Label: SLOT 3
  :00:03.0 ACPI Index: 17
= enp4s0f1
  Device: /sys/devices/pci:00/:00:03.0/:04:00.1
  PhysFn: /sys/devices/pci:00/:00:03.0/:04:00.0
  DevPort: 0
  Driver: mlx4_core
  Level: 1   Slot Entry 15: ID 04:00, slot number 3
  PORT: 1
  DCM: 1001C52001C5
p1_1
p2_1
  :00:03.0 Label: SLOT 3
  :00:03.0 ACPI Index: 17
= enp4s0f1d1
  Device: /sys/devices/pci:00/:00:03.0/:04:00.1
  PhysFn: /sys/devices/pci:00/:00:03.0/:04:00.0
  DevPort: 1
  Driver: mlx4_core
  Level: 1   Slot Entry 15: ID 04:00, slot number 3
  PORT: 2
  DCM: 1001C52001C5
p1_1
p2_1
  :00:03.0 Label: SLOT 3
  :00:03.0 ACPI Index: 17
= enp4s0f2
  Device: /sys/devices/pci:00/:00:03.0/:04:00.2
  PhysFn: /sys/devices/pci:00/:00:03.0/:04:00.0
  DevPort: 0
  Driver: mlx4_core
  Level: 1   Slot Entry 15: ID 04:00, slot number 3
  PORT: 1
  DCM: 1001C52001C5
p1_1
p2_1
  :00:03.0 Label: SLOT 3
  :00:03.0 ACPI Index: 17
= enp4s0f2d1
  Device: /sys/devices/pci:00/:00:03.0/:04:00.2
  PhysFn: /sys/devices/pci:00/:00:03.0/:04:00.0
  DevPort: 1
  Driver: mlx4_core
  Level: 1   Slot Entry 15: ID 04:00, slot number 3
  PORT: 2
  DCM: 1001C52001C5
p1_1
p2_1
  :00:03.0 Label: SLOT 3
  :00:03.0 ACPI Index: 17
= enp4s0f3
  Device: /sys/devices/pci:00/:00:03.0/:04:00.3
  PhysFn: /sys/devices/pci:00/:00:03.0/:04:00.0
  DevPort: 0
  Driver: mlx4_core
  Level: 1   Slot Entry 15: ID 04:00, slot number 3
  PORT: 1
  DCM: 1001C52001C5
p1_1
p2

Re: [systemd-devel] [packaging] split of systemd package

[Karel Zak]

On Thu, Nov 12, 2015 at 09:59:34AM +0100, Lennart Poettering wrote:
> The other option of course is to declare all internal APIs exported
> .so symbols, but that would mean to commit to a stable API for them
> (which is completely out of the question), or to bump the soname on
> each release (which is not an option either).

You don't have to change soname, but all you need it use symbols
versioning with package (or build) specific version for private-API.
This method uses libvirt.so where is large number of private but 
exported symbols.

 https://github.com/libvirt/libvirt/blob/master/src/Makefile.am#L2031

so something like:

 ...
 LIBSYSTEMD_227 {
 global:  
 sd_bus_default_flush_close;
 sd_bus_path_decode_many;
 sd_bus_path_encode_many;
 sd_listen_fds_with_names;
 } LIBSYSTEMD_226;
 

 LIBSYSTEMD_PRIVATE_$(VERSION) {
 global:
funcA;
funcB;
 };

where $(VERSION) is always different, then you can be sure that people
won't be able to link against the symbols and mix libsystemd with
systemd binaries from different versions.

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl suspend

[Steve Abner]

On 11/12/2015 07:56 AM, Lennart Poettering wrote:

On Wed, 11.11.15 16:13, Steve Abner (pheonix@att.net) wrote:

>I have an issue of the console not turning back on. I have a new build,
>linux 4.2, amd64, systemd, kdbus
>on a mac mini. The first try was hybrib-sleep, failed so tried suspend. From
>journalctl there seems to be
>no related errors, one:
>systemd-networkd[289]: wlan0: DHCPv4 address 192.168.1.82/24 via
>192.168.1.254
>systemd-network[289]: segfault at 6e0063 ip 7f913210409a sp
>7fff38450b98 error 4 in libc-2.22.so[7f9132083000+19a000]
>  or with audit enabled

networkd should never segfault, under no circumstances. Which version
of systemd is this? Any chance you can get us a backtrace for this
crash?
This happened on 227 and 224, but originally was using 224. I re-built 
system on first attempt to solve
monitor not switching on. As to backtrace, I am not sure how to help. I 
dont know how to intercept the
process. Please instruct this dummy (me) and I would love to provide 
assistance.

Bringing up hardware after returning from suspend is not systemd's
job, that's a job the kernel is supposed to do on its own. Please ask
the kernel guys for help.
Thankfully, Mantus's help provided me the direction I needed! Looked 
into ACPI a bit. Assumption was
that generic frame buffering, and kernel detection of devices still 
provided support for console power.
Appears I was mistaken! Configured in nouveau, and monitor now turns 
back on. But dang, that's a lot

of code :)

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

Re: [systemd-devel] about socket

[Lennart Poettering]

On Wed, 11.11.15 16:21, yan...@iscas.ac.cn (yan...@iscas.ac.cn) wrote:

> Hi guys:
> How can I find what systemd does for sockets? For example,if A and B 
> requires C,and when C has not start,the message of A and the message of B is 
> in the same queue? or else? Thank you!

Sorry, I cannot parse this.

Lennart

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

Re: [systemd-devel] systemctl suspend

[Lennart Poettering]

On Wed, 11.11.15 16:13, Steve Abner (pheonix@att.net) wrote:

> I have an issue of the console not turning back on. I have a new build,
> linux 4.2, amd64, systemd, kdbus
> on a mac mini. The first try was hybrib-sleep, failed so tried suspend. From
> journalctl there seems to be
> no related errors, one:
> systemd-networkd[289]: wlan0: DHCPv4 address 192.168.1.82/24 via
> 192.168.1.254
> systemd-network[289]: segfault at 6e0063 ip 7f913210409a sp
> 7fff38450b98 error 4 in libc-2.22.so[7f9132083000+19a000]
>  or with audit enabled

networkd should never segfault, under no circumstances. Which version
of systemd is this? Any chance you can get us a backtrace for this
crash?


> audit[269]: ANOM_ABEND auid=4294967295 uid=76 gid=76 ses=4294967295
> subj=kernel pid=269 comm="systemd-network"
> exe="/lib/systemd/systemd-networkd"
> systemd-network[269]: segfault at 6e0063 ip 7f4d2bcb909a sp
> 7ffedf852108 error 4 in libc-2.22.so[7f4d2bc38000+19a000]
> 
>  Once awaken from sleep, out journal to file, reboot. This regains console.
> Turning console monitor off/on
> has no effect. Also there is no dev/pts/ptmx as this is terminal only,
> working out bugs before adding
> display_manager. Maybe something in lunix config is not set to work with
> systemd suspend? I know of
> modules or builds not informing about dependencies, 4-5 days of builds to
> get wifi working because of it.

Bringing up hardware after returning from suspend is not systemd's
job, that's a job the kernel is supposed to do on its own. Please ask
the kernel guys for help.

Lennart

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

Re: [systemd-devel] Detect if a script runs during bootup

[Frederic Crozat]

Le jeudi 12 novembre 2015 à 11:31 +0100, Frank Steiner a écrit :
> Reindl Harald wrote
> 
> > > This is not possible as it is an opensuse system script that I
> > > cannot
> > > replace.
> > 
> > says who?
> > 
> > thats why /etc/systemd/system/ exists - override sysvinit scripts
> > and 
> > even systemd-units from packages - just name it identical and it
> > will win
> 
> Right, but it's the /etc/init.d/nfsserver script that I'm not going
> to replace as it does a lot of stuff for setting up the nfs server
> the way the SuSE folks want it...

For the record, nfsserver initscript is being replaced by a set of
systemd service files in upcoming SLE12 SP1 ;)


-- 
Frederic Crozat
Enterprise Desktop Release Manager
SUSE



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

Re: [systemd-devel] Detect if a script runs during bootup

[Colin Guthrie]

Zbigniew Jędrzejewski-Szmek wrote on 11/11/15 15:55:
> On Wed, Nov 11, 2015 at 04:39:23PM +0100, Frank Steiner wrote:
>> Isn't there an easy way to figure out if this script is running
>> inside the boot process? Some variable set or not yet set?
> You can use systemctl is-system-running (see the man page).

I guess another option would just be to write out a flag file into /run
tree when you do the first call. First call the file won't exist, all
subsequent calls it will.

That might fit better with a scripted solution than calling out to an
exec, but YMMV.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] systemctl suspend

[Steve Abner]

On 11/12/2015 01:04 AM, Mantas Mikulėnas wrote:
On Wed, Nov 11, 2015 at 11:13 PM, Steve Abner > wrote:


I have an issue of the console not turning back on. I have a new
build, linux 4.2, amd64, systemd, kdbus
on a mac mini. The first try was hybrib-sleep, failed so tried
suspend. From journalctl there

systemd *does not have* its own suspend mechanism, it uses only what 
the kernel itself provides.

snip
Run `echo mem > /sys/power/state`; if that doesn't work, then you have 
a kernel problem.
thx, not sure about "if that doesn't work", it does "kinda". That puts 
it back to sleep. Still remains a
totally black console. However, your "systemd *does not have*" statement 
leads me to believe that an
issue of possible dependency probably exists, so back to the check 
boxes, build, test for several more

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

Re: [systemd-devel] [packaging] split of systemd package

[Simon McVittie]

On 12/11/15 08:59, Lennart Poettering wrote:
> The
> other option of course is to declare all internal APIs exported .so
> symbols, but that would mean to commit to a stable API for them (which
> is completely out of the question), or to bump the soname on each
> release (which is not an option either).

Have you considered doing something similar to what recent dbus versions
do for libdbus?

* symbols starting dbus_ (except for a couple of historical accidents
  that start with dbus_internal_do_not_use_) are explicitly stable ABI

* symbols starting _dbus_ are explicitly not stable ABI, and are only
  used (outside libdbus) by dbus-daemon and other utilities in the dbus
  source package

* symbols starting dbus_ are versioned (GNU symbol-versioning)
  as LIBDBUS_1_3 (as long as the shared library is libdbus-1.so.3)

* symbols starting _dbus_ are versioned as LIBDBUS_PRIVATE_1.10.2
  which deliberately changes with each new version

This only applies to our equivalent of systemd's src/basic (the parts
that are needed by both the libdbus public API and the utilities). Our
equivalent of src/shared still ends up in a convenience library that is
statically linked into each utility that needs it.

It's a little easier for systemd to rely on this than it is for dbus to
do the same, because dbus is portable (to Windows, non-GNU Linux, and
non-Linux Unix like *BSD and Solaris), whereas systemd only targets
GNU/Linux and can assume that GNU symbol versioning is present in libc.

S
-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] [PATCH] v3 Read NIC partitions on Dell Servers

[Lennart Poettering]

On Tue, 10.11.15 14:57, jhar...@gmail.com (jhar...@gmail.com) wrote:

> From: Jordan Hargrave 
> 
> I removed the SMBIOS-specific code, this code is for partition detection only.
> 
> This patch will read NIC partition info from VPD on Dell Servers
> 
> It creates a new environment variable 'ID_NET_NAME_PARTITION'
> with the format '_'
> 
> Signed-off-by: Jordan Hargrave 

I am not sure if Kay/Tom want this patch at all or not, but if they
do:

please have a look at CODING_STYLE, and try to follow the rules. I see
quite a few places where coding style isn't followed: we don't use
S-o-b on systemd, we place opening brackets on the same line as the
functions/structs. We don't use types such as "unsigned char", we
don't invent error codes such as "-1", we don't use {} on single-line
if blocks, and so on.

Lennart

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

Re: [systemd-devel] [packaging] split of systemd package

[Martin Pitt]

Lennart Poettering [2015-11-12 11:15 +0100]:
> > Won't you need it for udevadm hwdb --update, after you add a new
> > hwdb.d/ file? Or can we now have multiple compiled dbs, one shipped by
> > the package and one built dynamically by hwdb --update?
> 
> Well, if you do add those locally. But that's not a typical usecase really.

I meant that the udev package isn't the only thing shipping hdwb.d/
files -- at least libmtp, libgphoto, and media-player-info ship some
as well, and cause the hdwb to be rebuilt on package
installation/removal.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Detect if a script runs during bootup

[Frank Steiner]

Reindl Harald wrote

>> This is not possible as it is an opensuse system script that I cannot
>> replace.
> 
> says who?
> 
> thats why /etc/systemd/system/ exists - override sysvinit scripts and 
> even systemd-units from packages - just name it identical and it will win

Right, but it's the /etc/init.d/nfsserver script that I'm not going
to replace as it does a lot of stuff for setting up the nfs server
the way the SuSE folks want it...

Zbigniew Jędrzejewski-Szmek wrote

> You can use systemctl is-system-running (see the man page).

The systemd in SLE 12 does not yet know about this option, but I'll
ask for an update. 

Thanks so far!

cu,
Frank



-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17   Phone: +49 89 2180-4049
80333 Muenchen, Germany   Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Thu, 12.11.15 10:46, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Lennart Poettering [2015-11-12  9:59 +0100]:
> > THere's no point in shipping the non-binary version of the hwdb. The
> > hwdb isn't a cache, it's a compiled version of the hwdb, and you don't
> > the sources around for this.
> 
> Won't you need it for udevadm hwdb --update, after you add a new
> hwdb.d/ file? Or can we now have multiple compiled dbs, one shipped by
> the package and one built dynamically by hwdb --update?

Well, if you do add those locally. But that's not a typical usecase really.

Lennart

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

Re: [systemd-devel] [packaging] split of systemd package

[Martin Pitt]

Lennart Poettering [2015-11-12  9:46 +0100]:
> > Another reason is to make it easy to enable/disable a particular
> > feature (e. g.  libnss-myhostname).
> 
> I don't see why one would ever disable this feature... I doubt this
> makes senseto split out really.

We have to do that because it's a shared library and needs to be
multi-arch compatible (i. e. you might have more than one architecture
installed at the same time); so this was a bad example wrt. feature
enablement indeed. libnss-mymachines and libnss-resolved might be
better ones (but we don't have a choice to not split them out anyway).

> > > systemd-networkd (maybe also with resolved?)
> > 
> > We currently keep that in the "systemd" package as splitting it out
> > now is a bit of an upgrade pain, but we discussed doing this.
> 
> As mentioned I wouldn't split this out either.

I'm reluctant to do it too. At the moment there's little reason
because we still have the iptables support disabled. Both because the
iptables vs. nftables question isn't decided yet, and also because it
would mean another set of heavy dependencies in the default install
for a relatively little used feature. libnftnl is much smaller, so
if/once we switch to that, this is much less of a concern.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [packaging] split of systemd package

[Martin Pitt]

Lennart Poettering [2015-11-12 10:01 +0100]:
> > However, the gain through the extra dependencies is nontrivial: On a
> > minimal system, installing systemd-container pulls in some 20 extra
> > packages (libldap, sasl2-modules, libkrb5, libssh, ca-certificates
> > etc.)
> 
> ldap, sasl, kerberos, libssh and the certificates? That sounds very wrong.

systemd-container depends on libcurl3-gnutls, which is the thing we
desperately want to keep out of a minimal install as it has this huge
list of dependencies.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [packaging] split of systemd package

[Martin Pitt]

Lennart Poettering [2015-11-12  9:59 +0100]:
> THere's no point in shipping the non-binary version of the hwdb. The
> hwdb isn't a cache, it's a compiled version of the hwdb, and you don't
> the sources around for this.

Won't you need it for udevadm hwdb --update, after you add a new
hwdb.d/ file? Or can we now have multiple compiled dbs, one shipped by
the package and one built dynamically by hwdb --update?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Lennart Poettering]

On Thu, 12.11.15 02:29, Matthew Hall (mh...@mhcomputing.net) wrote:

> On Thu, Nov 12, 2015 at 07:59:03AM +0200, Mantas Mikul??nas wrote:
> > I'm not sure if udev even still _allows_ renaming to eth*, but even if it
> > does, that's explicitly not supported. (For example, between the time eth0
> > appears and the "rename to eth1" rule gets processed, another eth1 might
> > also appear, and the rename would fail.) If you want custom names, use en*
> > or port* or lan* or some other prefix.
> 
> Let me try and put this another way. I have been using UNIX 24 years. I have 
> typed the characters eth0 so long that it's long since been hardcoded into my 
> fingers; trying to change it would drive me crazy and serve no beneficial 
> purpose besides confusing me when I am trying to get work done. The computer 
> is a tool to help me solve problems. It makes more sense to get the computer 
> to accomodate the users than the other way around.
> 
> Dynamically populating the "eth*" namespace with random unexpected network 
> interfaces on the fly should honestly be considered a bug not a feature. If 
> they are dynamically populated then they can be placed anywhere, so why not 
> place them under net0, net1, net2, etc.?

Since time began eth* is where the kernel automatically picked iface
names from. If you want to assign your own names go for some other
namespace, or be prepared to race against the kernel, and deal with
it.

Lennart

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

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Lennart Poettering]

On Thu, 12.11.15 00:12, Matthew Hall (mh...@mhcomputing.net) wrote:

> Hello all,
> 
> I am tearing my hair out trying to follow the directions in this page to get 
> the 
> correct interface names on Ubuntu Wily w/ systemd-udevd.
> 
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Actually the best way to give nice names to your iface is via .link
files these days. But we never documented that on that wiki page. I
have now updated the page a bit, adding a reference to this.

See the end of the systemd.link(5) man page for examples how to do
this:

http://www.freedesktop.org/software/systemd/man/systemd.link.html

> I am just trying to get my eth0 - eth3 into the desired order. The order in 
> lspci is correct:

The ethXYZ names are assigned automatically by the kernel, you will
necessarily race against the kernel if you try to assign them,
too.

Never do this, please, you can only lose with that. Pick names such as
"net0", "internet0", "dmz0", "front0", "back0", "uplink0", "foo",
"bar", "waldo", but not "eth0" of all things...

Lennart

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

Re: [systemd-devel] [packaging] split of systemd package

[Reindl Harald]

Am 12.11.2015 um 09:46 schrieb Lennart Poettering:

On Wed, 11.11.15 12:58, Martin Pitt (martin.p...@ubuntu.com) wrote:


Hello all,

in case it's useful, this is how we split them in Debian.

However, is this even a topic for upstream, apart from giving
recommendations? I. e. do you actually consider putting this kind of
split into the upstream build system à la "make
install-"?


Nope, we won't do that.


Lukáš Nykrýn [2015-11-11 11:47 +0100]:

Personally I don't think it makes sense to split the package to get a
smaller core package. Most of our binaries are just few KBs.


They are actually fairly big, 100 kB to 1.5 MB for systemd itself. I
think the main reason for that is that they all statically link
libsystemd instead of dynamically linking to libsystemd.so.0. Is there
a particular reason for that?


Yes, there is. If we'd share the common code via a proper .so then
we'd have to commit to a stable API for that, or bump the soname on
every single release. We really don't want to do either. The internal
stuff is stupposed to be internal, and not an API


that is no valid reasoning, the following postfix libs are *not* a 
stable API and *not* supported to be used from 3rd party code, hence 
they are not directly in /usr/lib64/


just because a internal .so exists don't make it to a API

postfix   /usr/lib64/postfix/libpostfix-dns.so
postfix   /usr/lib64/postfix/libpostfix-global.so
postfix   /usr/lib64/postfix/libpostfix-master.so
postfix   /usr/lib64/postfix/libpostfix-tls.so
postfix   /usr/lib64/postfix/libpostfix-util.so




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Thu, 12.11.15 09:07, Lukáš Nykrýn (lnyk...@redhat.com) wrote:

> Zbigniew Jędrzejewski-Szmek píše v Čt 12. 11. 2015 v 06:13 +:
> > I prepared a package for rawhide with [1,2] the following
> > subpackages:
> > systemd-journal-remote (remote, upload, gatewayd)
> > systemd-container (nspawn, machinectl, machined, importd, pull, var
> > -lib-machines.mount)
> > systemd-udev (udevd, udevadm, udev rules, hwdb).
> > 
> > The first two are uncontroversial (systemd-journal-remote already
> > existed
> > as systemd-journal-gateway for a long time).
> > The last is somewhat controversial: while people seem to agree about
> > the split,
> > it's not necessary clear whether udevd should be in the subpackage or
> > not.
> > I went with "yes", to see how that works out. I think this makes more
> > sense this way, but maybe not.
> 
> I would like to see the hwdb in its own package. I can imagine a use
> -case where user wants to use udev, but wants to provide its own
> smaller hwdb (or hwdb.bin).

Sorry, I strongly disagree. There's no point in having the hwdb at
all, if you want a "smaller" one. This is a usecase that doesn't
exist...

Either you want generic support for all kinds of hw that might
possibly plugged into your system, or you control exactly the hw that
will show up and don't want the database, but in that case, you'd just
use a couple of udev rules as replacement and no hwdb, and that's
it. Having a "minimal" hwdb is non-sense, really.

There's no point in splitting this up too wildly really.

Lennart

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

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Thu, 12.11.15 08:49, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello Zbigniew,
> 
> Zbigniew Jędrzejewski-Szmek [2015-11-12  6:39 +]:
> > Installed size of systemd-udev is 6.5MB, systemd-container is 3.5MB,
> > systemd is 19MB, so the gain is modest. We also lose some dependencies.
> 
> To compare with Debian: systemd: 17.5 MB, s-container 2.4 MB, udev 6.6
> MB, so this is comparable.
> 
> However, the gain through the extra dependencies is nontrivial: On a
> minimal system, installing systemd-container pulls in some 20 extra
> packages (libldap, sasl2-modules, libkrb5, libssh, ca-certificates
> etc.)

ldap, sasl, kerberos, libssh and the certificates? That sounds very wrong.

Lennart

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

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Andrei Borzenkov]

On Thu, Nov 12, 2015 at 10:29 AM, Matthew Hall  wrote:
>
> Let me try and put this another way. I have been using UNIX 24 years. I have
> typed the characters eth0 so long that it's long since been hardcoded into my
> fingers; trying to change it would drive me crazy and serve no beneficial
> purpose besides confusing me when I am trying to get work done. The computer
> is a tool to help me solve problems. It makes more sense to get the computer
> to accomodate the users than the other way around.
>

In the past 24 years I have been working with over dozen of different
operating systems (and likely the same number of different Linux
distributions). Each of them had different rules for interface naming,
these rules changing from version to version. Even your Linux
distribution has at least dozen different names for network interfaces
(have you never ever seen wlan0?)

So I do not really care a  about what name is used as long as this
name remains persistent from reboot to reboot.

> Dynamically populating the "eth*" namespace with random unexpected network
> interfaces on the fly should honestly be considered a bug not a feature. If
> they are dynamically populated then they can be placed anywhere, so why not
> place them under net0, net1, net2, etc.?


What's wrong with naming *your* interfaces net0, net1 etc then? Why
are so addicted to three letters 'e', 't', 'h'?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Wed, 11.11.15 13:38, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> > > systemd-firstboot (firstboot,sysusers?,factory stuff?)
>
> I wonder if this is worth the trouble. The binaries are currently
> fairly big, but do they bring in any external dependencies?
> Maybe we should instead link them dynamically to libsystemd.so?
> This would save some space...

This won't work. We generally try to avoid static variables, but we
have some, for example in log.c to store the log level and
target. Now, you could compile log.c into both libsystemd.so and the
main programs (which is basically what we do), and then make the main
program link against libsystemd.so (which we do not do). In such a
case you'd have two copies of log.c (and thus the static vars) in the
resulting process, and if we set the log level of one, this won't
affect the log level of the other. This is clearly problematic. The
other option of course is to declare all internal APIs exported .so
symbols, but that would mean to commit to a stable API for them (which
is completely out of the question), or to bump the soname on each
release (which is not an option either).

We hence link the internal code into all binaries, and rely on the
linker and compiler to strip as much of that as possible again.

> 
> > We don't have a separate package for that.
> > 
> > > systemd-hwdb
> > 
> > We split out the entire udev, including hwdb. This nicely reduces the
> > footprint in containers and also allows us to use udev with
> > sysvinit/upstart.
> Yeah, that makes a big impact. The only thing that is not clear is
> whether systemd-udevd should be part of this package (a), or part of
> the main package (b). You do (a), but (b) may make sense to run udevd
> without the hardware database. I don't think this is useful except in
> very rare circumstances. Someone brought up the case of an embedded
> device with a custom db... I don't think this is very convincing,
> because in such case you wouldn't ship the text hwdb at all, just
> /etc/udev/hwdb.bin.

THere's no point in shipping the non-binary version of the hwdb. The
hwdb isn't a cache, it's a compiled version of the hwdb, and you don't
the sources around for this.

Lennart

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

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Mantas Mikulėnas]

On Thu, Nov 12, 2015 at 10:52 AM, Matthew Hall 
wrote:

> On Thu, Nov 12, 2015 at 09:56:28AM +0200, Mantas Mikul??nas wrote:
> > You begin with saying that eth# is good because that's how it's been done
> > for decades ??? but then you say the exact same thing is now *bad* and
> the
> > kernel should start putting new interfaces under net#, completely
> > contradicting your earlier "trying to change it would drive me crazy".
> What
> > even?
> >
> > The kernel has been "dynamically populating the eth* namespace with
> random
> > unexpected network interfaces" since day one. It's not a systemd thing.
> > It's as you said "how UNIX has always worked".
>
> Yes, of course at first it appears to be a contradiction.
>
> Until you consider that for most of these decades, the software was
> populating
> more or less the same set of static devices once at boot, albeit in a
> potentially weird order. It was not randomly adding or removing things
> on-the-fly as some new driver comes up or down.
>
> So, we took was was an admittedly semi-random process that was working
> pretty
> well, and starting doing thinsg in a new way. Except this new way comes
> with
> some unpleasant side effects.
>
> This new way steals the old eth* namespace everybody was comfortable with,
> despite its issues, and makes it a lot more random and full of weird
> dynamic
> stuff. The need for weird dynamic stuff was unavoidable, but it seems
> unhelpful to complicate the problems with eth* by pouring more gasoline on
> it.
>
> Putting weird stuff in there by itself would not be a big deal. Except now
> you're saying that we are prohibited from giving meaning and lofical back
> to
> that namespace, merely because the software wants to reserve the right to
> randomly insert weird stuff into the middle of that namespace at any point
> for
> no really reason in terms of features or usability as far as I could
> determine.
>

I am _still_ not sure what you're talking about. The kernel's eth*
assignment policy hasn't changed for _many years_ – first device detected
gets eth0, second gets eth1, and so on. It has always been so.

The "new way" of systemd _does not_ use the eth* namespace for anything.
Just as you said, it uses alternative prefixes such as en* for the
"persistent" names.


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

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Wed, 11.11.15 14:33, Lukáš Nykrýn (lnyk...@redhat.com) wrote:

> > 
> > > systemd-machine (machined,nspawn,importd)
> > 
> > I'd call this "systemd-nspawn.rpm", really... The name of the daemon
> > is irrelevant.
> > 
> > > systemd-firstboot (firstboot,sysusers?,factory stuff?)
> > 
> > I'd really not bother with this stuff. This should be in the base,
> > and
> > it is tiny. Plese leave this in the main package.
> 
> The only reason was that it pulls in libcrypt.

Hmm? 

 $ rpm -qf /usr/lib64/libcrypt.so.1
 glibc-2.22-3.fc23.x86_64

I am sorry, but I doubt we'll ever be able to get rid of the glibc
dependency of systemd. ;-)

Lennart

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

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Matthew Hall]

On Thu, Nov 12, 2015 at 09:56:28AM +0200, Mantas Mikul??nas wrote:
> You begin with saying that eth# is good because that's how it's been done
> for decades ??? but then you say the exact same thing is now *bad* and the
> kernel should start putting new interfaces under net#, completely
> contradicting your earlier "trying to change it would drive me crazy". What
> even?
> 
> The kernel has been "dynamically populating the eth* namespace with random
> unexpected network interfaces" since day one. It's not a systemd thing.
> It's as you said "how UNIX has always worked".

Yes, of course at first it appears to be a contradiction.

Until you consider that for most of these decades, the software was populating 
more or less the same set of static devices once at boot, albeit in a 
potentially weird order. It was not randomly adding or removing things 
on-the-fly as some new driver comes up or down.

So, we took was was an admittedly semi-random process that was working pretty 
well, and starting doing thinsg in a new way. Except this new way comes with 
some unpleasant side effects.

This new way steals the old eth* namespace everybody was comfortable with, 
despite its issues, and makes it a lot more random and full of weird dynamic 
stuff. The need for weird dynamic stuff was unavoidable, but it seems 
unhelpful to complicate the problems with eth* by pouring more gasoline on it.

Putting weird stuff in there by itself would not be a big deal. Except now 
you're saying that we are prohibited from giving meaning and lofical back to 
that namespace, merely because the software wants to reserve the right to 
randomly insert weird stuff into the middle of that namespace at any point for 
no really reason in terms of features or usability as far as I could determine.

So I'm sending a contradictory email not because I am crazy but actually in 
response to a contradictory policy from upstream! :) What we are seeing here 
is a butterfly effect. A small change in the initial conditions, i.e. of the 
level of dynamism expected of eth* compared to the past, has caused an 
unexpectedly large disturbance in the usability of the environment.

It can be overcome, of course, with an override file that would more clearly 
allocate the devices... except we're being told the one classic namespace 
we're used to using for decades, is now *precisely* the one we're not supposed 
to use. And nobody provided a working example of the override file in the 
documentation... so then no new users experiencing the changes will have any 
good idea what to do to fix things.

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

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Wed, 11.11.15 16:03, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> 
> 
> On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >Why not systemd-devel?
> 
> Because these aren't development related discussion and there is a need for
> separated collaborated git repository to prevent duplication of downstream
> work etc.

We only have one ML, and I'd rather have more inter-distro threads on
this ML than more threads on whether inter-distro threads belong
here. Thanks ;-)

Lennart

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

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Wed, 11.11.15 23:09, Michael Chapman (m...@very.puzzling.org) wrote:

> On Wed, 11 Nov 2015, Lukáš Nykrýn wrote:
> >Hi,
> >
> >During systemd.conf we have discussed some recommendation for
> >downstreams, how they could split systemd to subpackages, so lets
> >continue that discussion here.
> >
> >Personally I don't think it makes sense to split the package to get a
> >smaller core package. Most of our binaries are just few KBs. Only
> >exception here is /usr/lib/udev/hwdb.d which, on fedora rawhide, has
> >about 5,2 MB (15% of the whole package).
> >
> >Other aspect would be minimizing external dependencies. I have made a
> >list of libraries and which binaries pulls them in [1] and from that
> >point of view it would make sense to put follow binaries to subpackage:
> >systemd-pull
> >systemd-journal-gatewayd
> >systemd-journal-remote
> >systemd-journal-upload
> >systemd-firstboot
> >systemd-networkd
> 
> Hi Lukáš,
> 
> It seems like you're just looking at binaries at the moment, but I think
> some care needs to be taken with config files too.
> 
> One gotcha I discovered in having networkd split out, and specifically in
> having 99-default.link in a subpackage, is that it can change the way
> predictable interface naming works, whether or not the networkd daemon is
> managing network interfaces. Udev's net_setup_link builtin consults the
> *.link files directly to determine the interface naming policy.
> 
> We have to make sure the mere presence or absence of an otherwise-unused
> subpackage on a system doesn't change the system's behaviour too
> dramatically.

The .link files belong to udev, not networkd. It's that simple.

Lennart

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

Re: [systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Wed, 11.11.15 12:58, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello all,
> 
> in case it's useful, this is how we split them in Debian.
> 
> However, is this even a topic for upstream, apart from giving
> recommendations? I. e. do you actually consider putting this kind of
> split into the upstream build system à la "make
> install-"?

Nope, we won't do that.

> Lukáš Nykrýn [2015-11-11 11:47 +0100]:
> > Personally I don't think it makes sense to split the package to get a
> > smaller core package. Most of our binaries are just few KBs.
> 
> They are actually fairly big, 100 kB to 1.5 MB for systemd itself. I
> think the main reason for that is that they all statically link
> libsystemd instead of dynamically linking to libsystemd.so.0. Is there
> a particular reason for that?

Yes, there is. If we'd share the common code via a proper .so then
we'd have to commit to a stable API for that, or bump the soname on
every single release. We really don't want to do either. The internal
stuff is stupposed to be internal, and not an API.

> Another reason is to make it easy to enable/disable a particular
> feature (e. g.  libnss-myhostname).

I don't see why one would ever disable this feature... I doubt this
makes senseto split out really.

> > systemd-networkd (maybe also with resolved?)
> 
> We currently keep that in the "systemd" package as splitting it out
> now is a bit of an upgrade pain, but we discussed doing this.

As mentioned I wouldn't split this out either.

Lennart

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

Re: [systemd-devel] [packaging] split of systemd package

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v Čt 12. 11. 2015 v 05:42 +:
> On Wed, Nov 11, 2015 at 02:33:52PM +0100, Lukáš Nykrýn wrote:
> > > > systemd-firstboot (firstboot,sysusers?,factory stuff?)
> > > 
> > > I'd really not bother with this stuff. This should be in the
> > > base,
> > > and
> > > it is tiny. Plese leave this in the main package.
> > 
> > The only reason was that it pulls in libcrypt.
> libcrypt is provided by glibc, which is always installed, so
> splitting
> this out does not lead to any savings.
> 
> Zbyszek
> 

Yep I was probably wrong here. My reasoning was, that we have some
database of used crypto functionality in packages in rhel and we don't
use firstboot there, so for me it would be nice to drop this
dependency. But this is my specific usecase and we should push our
 firstboot in upstream more.

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

Re: [systemd-devel] [packaging] split of systemd package

[Lukáš Nykrýn]

Zbigniew Jędrzejewski-Szmek píše v Čt 12. 11. 2015 v 06:13 +:
> I prepared a package for rawhide with [1,2] the following
> subpackages:
> systemd-journal-remote (remote, upload, gatewayd)
> systemd-container (nspawn, machinectl, machined, importd, pull, var
> -lib-machines.mount)
> systemd-udev (udevd, udevadm, udev rules, hwdb).
> 
> The first two are uncontroversial (systemd-journal-remote already
> existed
> as systemd-journal-gateway for a long time).
> The last is somewhat controversial: while people seem to agree about
> the split,
> it's not necessary clear whether udevd should be in the subpackage or
> not.
> I went with "yes", to see how that works out. I think this makes more
> sense this way, but maybe not.

I would like to see the hwdb in its own package. I can imagine a use
-case where user wants to use udev, but wants to provide its own
smaller hwdb (or hwdb.bin).


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