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

[Lennart Poettering]

On Wed, 11.11.15 11:47, Lukáš Nykrýn (lnyk...@redhat.com) 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
> 
> So I suggest following scheme
> 
> systemd
> systemd-libs
> systemd-devel

> systemd-journal-remote (so gatewayd,remote,upload)

Makes sense.

> systemd-networkd (maybe also with resolved?)

I'd probably leave this in the main RPM, after all it doesn't take
possession of any interfaces by default, but makes sure
libsystemd-network returns useful stuff.

But if you do split it out, I'd call the package without the "d" suffix.

What's the effective size of this RPM on x86-64?

> 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.

sysusers is definitely something we should make a Fedora default, that
is used distro wide, as it makes user registration portable, and is
also what Atomic wants.

THe factory code is in systemctl and PID 1, it makes no sense to split
out, there's nothing really you could split out.

> systemd-hwdb

This makes sense to split out.

From my perspective the only things that make sense to split out is
nspawn/machinectl/machined/importd/pull into "systemd-nspawn.rpm", the
hwdb into "systemd-hwdb.rpm" and "systemd-journal-remote.rpm" for the
journal remoting things.

Lennart

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

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

[Frank Steiner]

Hi,

is there an easy way to figure out if a LSB script in /etc/init.d/
is called during bootup by systemd? I need to distinguish the first
execution during boot from subsequent calls (cron, manually etc.).

It seems that /sbin/runlevel returns "unknown" during bootup, but
I'm not sure if this reliable or not.

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] Detect if a script runs during bootup

[Tomasz Torcz]

On Wed, Nov 11, 2015 at 12:03:10PM +0100, Frank Steiner wrote:
> Hi,
> 
> is there an easy way to figure out if a LSB script in /etc/init.d/
> is called during bootup by systemd? I need to distinguish the first
> execution during boot from subsequent calls (cron, manually etc.).
> 
> It seems that /sbin/runlevel returns "unknown" during bootup, but
> I'm not sure if this reliable or not.

  I would suggest splitting the "on boot only" part into separate
unit, with RemainAfterExit=true.  The main part should require boot-only
part.
  First of all, create a proper unit and drop LSB script.
 

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

___
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

[Jóhann B . Guðmundsson]

On 11/11/2015 10:47 AM, 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.


I thought the conscious was not recommending downstream to split systemd 
into subpackages?


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

Re: [systemd-devel] "Failed to determine peer security context: Protocol not available" on kernels with disabled selinux

[Lennart Poettering]

On Tue, 10.11.15 22:53, Igor Zhbanov (izh1...@gmail.com) wrote:

> Hi!
> 
> I see lots of messages (with systemd debug enabled) on the kernel with
> selinux disabled:
> systemd[1]: Failed to determine peer security context: Protocol not available
> 
> As I understand, this happen because getsockopt() returns ENOPROTOOPT,
> and systemd
> checks for EOPNOTSUPP.

Hmm, how did you disable selinux/smack here? disabled at compile-time?
or at runtime via a kernel cmldine option like selinux=0?

> 
> /* Get the peer for socketpair() sockets */
> b->ucred_valid = getpeercred(b->input_fd, >ucred) >= 0;
> 
> /* Get the SELinux context of the peer */
> r = getpeersec(b->input_fd, >label);
> if (r < 0 && r != -EOPNOTSUPP)
> log_debug_errno(r, "Failed to determine peer security
> context: %m");

I figure we should wrap this in a mac_selinux_use() check like we do
for the other cases, otherwise we'd mistake a SMACK label for an
selinux one... That would solve the issue at hand.

Will fix.

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]

> I thought the conscious was not recommending downstream to split
> systemd 
> into subpackages?
> 

I think the previous discussion was more about if we should split core
components of systemd like systemd-logind, which still should stay in
the main package. 

And most of distributions split their packages already, so it would be
nice to have some general recommendations.

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

[Jóhann B . Guðmundsson]

On 11/11/2015 10:57 AM, Michal Sekletar wrote:

On Wed, Nov 11, 2015 at 11:52 AM, Jóhann B. Guðmundsson
 wrote:

I thought the conscious was not recommending downstream to split systemd
into subpackages?


This decision was recently (at systemd.conf) reevaluated :)



Not everybody can attend conference due to wide variety of reasons so 
making decisions there without the input of those in the community that 
could not attend is disrespectful.


Anyway what was the cause for the reevaluation in other words why did 
people change their mind in this regard?


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

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

[Lukáš Nykrýn]

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

So I suggest following scheme

systemd
systemd-libs
systemd-devel
systemd-journal-remote (so gatewayd,remote,upload)
systemd-networkd (maybe also with resolved?)
systemd-machine (machined,nspawn,importd)
systemd-firstboot (firstboot,sysusers?,factory stuff?)
systemd-hwdb


Regards

Lukas


[1] https://gist.github.com/lnykryn/bd5de7d9ed39986d5147

___
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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 11, 2015 at 12:17:59PM +0100, Tomasz Torcz wrote:
> On Wed, Nov 11, 2015 at 12:03:10PM +0100, Frank Steiner wrote:
> > Hi,
> > 
> > is there an easy way to figure out if a LSB script in /etc/init.d/
> > is called during bootup by systemd? I need to distinguish the first
> > execution during boot from subsequent calls (cron, manually etc.).
> > 
> > It seems that /sbin/runlevel returns "unknown" during bootup, but
> > I'm not sure if this reliable or not.
> 
>   I would suggest splitting the "on boot only" part into separate
> unit, with RemainAfterExit=true.  The main part should require boot-only
> part.
>   First of all, create a proper unit and drop LSB script.
+1.

There's no distinction between "boot" and "subsequnct calls":
what if boot takes a bit longer and cron calls the script during
boot?

Zbyszek
___
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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 11, 2015 at 12:58:14PM +0100, Martin Pitt 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-"?
> 
> 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?
> 
> > Other aspect would be minimizing external dependencies.
> 
> That is one important reason why we split them in Debian; e. g. the
> machined/nspawn/importd group pulls in a number of rather heavy
> dependencies. udev (including hwdb) is something which you don't need
> in containers, so we split that out too.
> 
> Another reason is to make it easy to enable/disable a particular
> feature (e. g.  libnss-myhostname).
> 
> And then of course the infamous "need to run with sysvinit/upstart",
> which other distros don't need to be concerned about :-)
> 
> > So I suggest following scheme
> 
> FTR, this isn't too far away what we already do in Debian/Ubuntu:
> 
> > systemd
> 
> check
> 
> > systemd-libs
> > systemd-devel
> 
> They are called a bit differently for distro policy, upgrade safety,
> consistency, and multi-arch support reasons; we need separate binary
> packages for every lib*.so. But in spirit, "check".
Yeah, we have systemd-libs and systemd-devel for a long time now.
This follows general Fedora conventions.

> > systemd-journal-remote (so gatewayd,remote,upload)
> 
> Check, we have exactly this package name.
> 
> > 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.
> 
> > systemd-machine (machined,nspawn,importd)
> 
> We call that package "systemd-container", but it has exactly those, so
> "check".
I think we (Fedora) should follow this, for inter-distro consistency.


> > 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...

> 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.

Zbyszek

PS. I prepared a split of the package on the place, but compling the
rpm on my puny notebook would take too long so I didn't really test it
yet. I'll send it out today for comments.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers

[Lennart Poettering]

On Tue, 10.11.15 11:12, Jordan Hargrave (jhar...@gmail.com) wrote:

>  The patch will also decode SMBIOS slot number for NIC, and store in the 
>  variable
>  ID_NET_NAME_SMBIOS_SLOT.  Systemd does not have a method for naming
>  ports on a multi-port card plugged into a slot.
> >>>
> >>> Again, I don't think systemd should carry an SMBIOS parser.
> >>>
> >>> Sorry,
> >>> Kay
> >>
> >> From a customer usability standpoint, having the slot numbers as part
> >> of systemd would be a very useful feature.
> >
> > Sure, but I think Kay's point was that the needed info should be
> > exposed from the kernel in a sysattr, not be parsed from udev. Any
> > reason this cannot be done that way?
> 
> The pci kernel maintainer was reluctant to put it in the kernel and
> said systemd should parse it.  So a bit of circular argument here.
> I agree, it would be better for it to be a kernel sysfs attr.

There's really no point in placing SMBIOS parsers to userspace *and*
kernelspace. There's one in the kernel already, and it is already used
to attach metadata to network devices. Hence, please, extend that
existing parser and add what you need there, and we can then hook up
whatever you parse out of that with udev.

The kernel will always be better in making sense of SMBIOS, hence it's
really the place this should be done.

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 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:

Why not systemd-devel?


Because these aren't development related discussion


this list was multiple times statet also as users-list by Lennart 
himself, just use Google to find that statement in the archive



and there is a need for separated collaborated git
repository to prevent duplication of downstream work etc.


why?



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] Detect if a script runs during bootup

[Frank Steiner]

Tomasz Torcz wrote

> I would suggest splitting the "on boot only" part into separate
> unit, with RemainAfterExit=true.  The main part should require boot-only
> part.
> First of all, create a proper unit and drop LSB script.

This is not possible as it is an opensuse system script that I cannot
replace.

Zbigniew Jędrzejewski-Szmek wrote

> There's no distinction between "boot" and "subsequnct calls":
> what if boot takes a bit longer and cron calls the script during
> boot?

That wouldn't matter. The LSB script is called several times with
different parameters. It always sources another script. In this
script I need to perform an action only at the first time this
script is sourced during the boot process. Thus having a flag 
letting me know that I'm inside the boot sequence would be enough 
to have an unique situation for performing this special action.

If I was able to work with systemd unit files, I could perfectly
do what I want, but I'm stuck with this LSB file.

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?

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

[Jóhann B . Guðmundsson]

On 11/11/2015 01:12 PM, Michael Biebl wrote:

2015-11-11 12:58 GMT+01:00 Martin Pitt :

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-"?

I brought this issue up during my talk and recommended that we
(downstream distros) might collaborate on this so where possible we
have more consistency across distros.

Since systemd-devel is rather low-volume these days it seemed ok to
have these discussions here.
If Lennart would like to see it elsewhere, that's fine of course. But
I actually value his feedback on this matter.




Arguable there should be a neutral ground somewhere ( 
systemd-cross-distro list of some sort ) where distribution can 
collaborate on matters like this since there are other things that need 
to be discussed and need to be sorted out other than just splitting 
systemd into separated components.


Unit files for various daemon and services, naming of component which 
can directly affect names of type units themselves, deprecation of 
environmental files in units ( not sure how or if they are used in 
Debian but in Fedora there exist /etc/sysconfig/foo files which have 
become obsoleted for daemon and service with the introduction of systemd 
) cross distro collaboration of integration of wide variety of systemd 
components ( timer units, networkd etc ) so fourth and so on.


Hopefully the outcome of broader discussion like that would result in 
mutual proposal where each participant distribution could present to 
their distribution for distro wide acceptance and integration.


JBG
___
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

[Zbigniew Jędrzejewski-Szmek]

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).

Zbyszek
___
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

[Jóhann B . Guðmundsson]

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.


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

Re: [systemd-devel] Pruning journal on systemd 216

[Petr Pisar]

On 2015-11-10, Zbigniew Jędrzejewski-Szmek  wrote:
> On Tue, Nov 10, 2015 at 09:23:50AM -0600, Ian Pilcher wrote:
>> Running Fedora 21 with systemd 216, and just discovered that journal
>> files are taking up 1.8G.  I see references to "journalctl
>> --vacuum-time" on the interwebs, but that option doesn't seem to be
>> present in my version.
>> 
>> So how should I go about cleaning out older journal data?
> You can
> a) simply remove files by hand
>(find /var/log/journal/ -type f -mtime +DAYS -delete)
> b) set SystemMaxUse= or MaxRetentinoSec= in /etc/systemd/journald.conf
>and 'systemctl kill --signal=SIGUSR2 systemd-journald' to execute
>the new limit.
>
Thanks for the details. The default settings is 10 % or 15 % of file
system space.

-- Petr

___
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

[Michael Chapman]

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.


- Michael___
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

[Richard Maw]

On Wed, Nov 11, 2015 at 12:58:14PM +0100, Martin Pitt wrote:
> 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?

This came up at the conference, I left with the impression that it was because
there were global variables determining the log levels, and that sharing that
would cause problems.

I think it came up in the questions section of Lennart's initial talk.
___
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

[Colin Guthrie]

Zbigniew Jędrzejewski-Szmek wrote on 11/11/15 13:38:
>>> > > systemd-machine (machined,nspawn,importd)
>> > 
>> > We call that package "systemd-container", but it has exactly those, so
>> > "check".
> I think we (Fedora) should follow this, for inter-distro consistency.


I prefer that name to systemd-nspawn. As Lennart's original comment on
the systemd-machine package name suggestion was "the name of the daemon
doesn't matter", I'd argue that the name of the binary also doesn't
matter too much! After all, the "nspawn" itself doesn't mean anything
unless you know what nspawn is, and if you know what it is, then you
know what a container is, so the name systemd-container makes sense there.

So +1 from me for that name as a general recommendation.

Col


-- 

Colin Guthrie
colin(at)mageia.org
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] about socket

[David Timothy Strauss]

The wording of your questions isn't clear to me. Do you mean that A and B
are socket-activated services, each requiring C? And when you say "the
message of A and the message of B," do you mean packets going to the
sockets for A and B?

If so, a packet going to A or B will also start C. The requests to start
services are processed FIFO by a single thread, so it's effectively one
queue.
___
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

[Jóhann B . Guðmundsson]

On 11/11/2015 03:39 PM, Frank Steiner wrote:

If I was able to work with systemd unit files, I could perfectly
do what I want, but I'm stuck with this LSB file.

Why are you stuck with that lsb file and what exactly does it do?
( Paste the content of it )

JBG
___
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

[Reindl Harald]

Am 11.11.2015 um 16:39 schrieb Frank Steiner:

Tomasz Torcz wrote


I would suggest splitting the "on boot only" part into separate
unit, with RemainAfterExit=true.  The main part should require boot-only
part.
First of all, create a proper unit and drop LSB script.


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


[root@srv-rhsoft:~]$ ls /etc/rc.d/init.d/vmware

-rwxr-xr-x 1 root root 14K 2015-11-01 21:01 /etc/rc.d/init.d/vmware
[root@srv-rhsoft:~]$ systemctl status vmware
● vmware.service - VMware Workstation Service
   Loaded: loaded (/etc/systemd/system/vmware.service; enabled; vendor 
preset: disabled)

   Active: active (exited) since Mi 2015-11-11 10:32:47 CET; 6h ago
 Main PID: 985 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/vmware.service



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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 11, 2015 at 03:43:51PM +, Jóhann B. Guðmundsson wrote:
> 
> 
> On 11/11/2015 01:12 PM, Michael Biebl wrote:
> >2015-11-11 12:58 GMT+01:00 Martin Pitt :
> >>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-"?
> >I brought this issue up during my talk and recommended that we
> >(downstream distros) might collaborate on this so where possible we
> >have more consistency across distros.
> >
> >Since systemd-devel is rather low-volume these days it seemed ok to
> >have these discussions here.
> >If Lennart would like to see it elsewhere, that's fine of course. But
> >I actually value his feedback on this matter.
>
> Arguable there should be a neutral ground somewhere (
> systemd-cross-distro list of some sort ) where distribution can
> collaborate on matters like this since there are other things that
> need to be discussed and need to be sorted out other than just
> splitting systemd into separated components.

Why not systemd-devel?

Zbyszek

> Unit files for various daemon and services, naming of component
> which can directly affect names of type units themselves,
> deprecation of environmental files in units ( not sure how or if
> they are used in Debian but in Fedora there exist /etc/sysconfig/foo
> files which have become obsoleted for daemon and service with the
> introduction of systemd ) cross distro collaboration of integration
> of wide variety of systemd components ( timer units, networkd etc )
> so fourth and so on.
> 
> Hopefully the outcome of broader discussion like that would result
> in mutual proposal where each participant distribution could present
> to their distribution for distro wide acceptance and integration.
___
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

[Michal Sekletar]

On Wed, Nov 11, 2015 at 11:52 AM, Jóhann B. Guðmundsson
 wrote:
>
> I thought the conscious was not recommending downstream to split systemd
> into subpackages?
>

This decision was recently (at systemd.conf) reevaluated :)

Michal
___
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

[Michael Biebl]

2015-11-11 12:58 GMT+01:00 Martin Pitt :
> 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-"?

I brought this issue up during my talk and recommended that we
(downstream distros) might collaborate on this so where possible we
have more consistency across distros.

Since systemd-devel is rather low-volume these days it seemed ok to
have these discussions here.
If Lennart would like to see it elsewhere, that's fine of course. But
I actually value his feedback on this matter.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
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

[Jóhann B . Guðmundsson]

On 11/11/2015 11:58 AM, Martin Pitt wrote:

However, is this even a topic for upstream,


I would argue not.

I would argue that this is a downstream collaboration matter in which a) 
the split should be the same regardless of distribution and the sub 
components should be split in same manner across all distribution so it 
does not matter if you are running Arch/Debian/Ubuntu/Fedora etc. the 
documentation and required actions are the same for the consumer.


JBG
___
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]

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-"?

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?

> Other aspect would be minimizing external dependencies.

That is one important reason why we split them in Debian; e. g. the
machined/nspawn/importd group pulls in a number of rather heavy
dependencies. udev (including hwdb) is something which you don't need
in containers, so we split that out too.

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

And then of course the infamous "need to run with sysvinit/upstart",
which other distros don't need to be concerned about :-)

> So I suggest following scheme

FTR, this isn't too far away what we already do in Debian/Ubuntu:

> systemd

check

> systemd-libs
> systemd-devel

They are called a bit differently for distro policy, upgrade safety,
consistency, and multi-arch support reasons; we need separate binary
packages for every lib*.so. But in spirit, "check".

> systemd-journal-remote (so gatewayd,remote,upload)

Check, we have exactly this package name.

> 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.

> systemd-machine (machined,nspawn,importd)

We call that package "systemd-container", but it has exactly those, so
"check".

> systemd-firstboot (firstboot,sysusers?,factory stuff?)

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.

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

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

[Matthew Hall]

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/

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

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V 
(rev 31)
08:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection 
(rev 03)
0a:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection 
(rev 01)
0a:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection 
(rev 01)

Here is what I have tried. I am trying to understand what I missed. It really 
shouldn't have to be this difficult. So I must be missing something.

1) First I tried making an override file:

/etc/udev/rules.d/70-net-names.rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
KERNELS==":00:1f.6", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
KERNELS==":08:00.0", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
KERNELS==":0a:00.0", NAME="eth2"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
KERNELS==":0a:00.1", NAME="eth3"

2) Then I tried masking off the PCI-based renamer file as well.

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

3) After that I tried net.ifnames=0 to see if that was getting in the way.

This produced a different wrong order, which did not match the lspci order, 
did not match the default PCI naming order (obviously enough) and did not 
match the udev rules.

During all of these I also kept checking journalctl -u systemd-udevd and 
/var/log, but I did not get any useful output there either.

What do I need to do to get this right?

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

Re: [systemd-devel] DHCPC Events?

[J Decker]

Should I have not said specifically Arch linux?
Is it something that can't be done?
It is something that should be so obvious it doesn't merit an answer?



On Fri, Nov 6, 2015 at 1:56 PM, J Decker  wrote:
> I have Arch Linux setup as my router.
> It's on a connection that can change the IP that I'm given, when that
> happens I need to rerun firewall rules and rebuild my ipv6 tunnel.
> How do I run some script or something when the address changes (or
> when it's initially given in the case of boot?)
>
> Also there seems to be no way to specify default ipv6 route for next
> hop... ie 'ip -6 route replace ::/0 dev he-ipv6'
> It's been a couple months I've been limping along so I forget; I
> vaguely remember that this should have been setup in the configuration
> scripts; but it didn't work unless I did it this way.  The iniital
> method I think was 'add' instead of 'replace' which no longer works (I
> think something changed in the kernel that affected that; but I don't
> know).
___
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 12:12:55AM -0500, Matthew Hall wrote:
> /etc/udev/rules.d/70-net-names.rules:
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
> KERNELS==":00:1f.6", NAME="eth0"
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
> KERNELS==":08:00.0", NAME="eth1"
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
> KERNELS==":0a:00.0", NAME="eth2"
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci", 
> KERNELS==":0a:00.1", NAME="eth3"

For future users who hits this, I think I finally found the bug.

You have to use the "SUBSYSTEMS" filter not the "SUBSYSTEM" filter. I am by 
far not an expert on udev and the rules are extremely confusing. Is there a 
better way to write this ruleset?

The process for adding an account on the FDO wiki is extremely confusing for 
any non-expert users:

http://wiki.freedesktop.org/sitewranglers/wiki/401/

There is no way anybody that isn't a crypto geek will know how to do that. It 
would be good if you could enable a CAPTCHA or web-based flow of some kind in 
a way which will not cause a flood of spammers so mere mortals can actually 
fix bugs in the pages.

I requested access... is there somebody here who could expedite it so I could 
get this fixed ASAP?

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

Re: [systemd-devel] systemctl suspend

[Mantas Mikulėnas]

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 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
> 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]
>

That's an unrelated bug in networkd.


>  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


/dev/pts/ptmx *is* about terminals; it has nothing to do with graphics nor
display managers. But its primary location is just */dev/ptmx* – not all
systems have it under /dev/pts/.


> 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.
>   Thanx


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

Run `echo mem > /sys/power/state`; if that doesn't work, then you have a
kernel problem.

-- 
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

[Zbigniew Jędrzejewski-Szmek]

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

___
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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 11, 2015 at 12:58:14PM +0100, Martin Pitt 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-"?
> 
> 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?
> 
> > Other aspect would be minimizing external dependencies.
> 
> That is one important reason why we split them in Debian; e. g. the
> machined/nspawn/importd group pulls in a number of rather heavy
> dependencies. udev (including hwdb) is something which you don't need
> in containers, so we split that out too.
> 
> Another reason is to make it easy to enable/disable a particular
> feature (e. g.  libnss-myhostname).
> 
> And then of course the infamous "need to run with sysvinit/upstart",
> which other distros don't need to be concerned about :-)
> 
> > So I suggest following scheme
> 
> FTR, this isn't too far away what we already do in Debian/Ubuntu:
> 
> > systemd
> 
> check
> 
> > systemd-libs
> > systemd-devel
> 
> They are called a bit differently for distro policy, upgrade safety,
> consistency, and multi-arch support reasons; we need separate binary
> packages for every lib*.so. But in spirit, "check".
> 
> > systemd-journal-remote (so gatewayd,remote,upload)
> 
> Check, we have exactly this package name.
> 
> > 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.
> 
> > systemd-machine (machined,nspawn,importd)
> 
> We call that package "systemd-container", but it has exactly those, so
> "check".
> 
> > systemd-firstboot (firstboot,sysusers?,factory stuff?)
> 
> 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, after removing a bunch of stuff, hwdb stuff becomes even more
pronounced.

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.

[1] http://in.waw.pl/git/fedora-systemd/
[2] https://copr.fedoraproject.org/coprs/zbyszek/systemd/build/138959/
___
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 7:40 AM, Matthew Hall  wrote:

> On Thu, Nov 12, 2015 at 12:12:55AM -0500, Matthew Hall wrote:
> > /etc/udev/rules.d/70-net-names.rules:
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":00:1f.6", NAME="eth0"
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":08:00.0", NAME="eth1"
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":0a:00.0", NAME="eth2"
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":0a:00.1", NAME="eth3"
>

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.


> For future users who hits this, I think I finally found the bug.
>
> You have to use the "SUBSYSTEMS" filter not the "SUBSYSTEM" filter. I am by
> far not an expert on udev and the rules are extremely confusing. Is there a
> better way to write this ruleset?


The way they work is simple though – they directly compare the values you'd
see in `udevadm monitor --env` or `udevadm info /sys/class/net/eth0`. If it
says "SUBSYSTEM=net", then you can match it using SUBSYSTEM=="net", that's
it.

But I guess the more important thing to know is that the network interface
is _not the same thing_ as the raw PCI device; it's shown as a sub-device
in /sys. (A single PCI device could easily expose multiple network
interfaces, for example.) Compare the output of `udevadm
info /sys/devices/pci:00/:00:1c.0/:01:00.0` vs `udevadm
info /sys/devices/pci:00/:00:1c.0/:01:00.0/net/eth0`.

That's why you use "SUBSYSTEMS=" and "KERNELS=" – you're checking
information of the _parent_ device. That said, some of the matches are IMHO
a bit redundant, and you'd be fine with:

ACTION=="add", SUBSYSTEM=="net", KERNELS==":0a:00.1", NAME="em1"

-- 
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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 12, 2015 at 06:13:32AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Nov 11, 2015 at 12:58:14PM +0100, Martin Pitt 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-"?
> > 
> > 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?
> > 
> > > Other aspect would be minimizing external dependencies.
> > 
> > That is one important reason why we split them in Debian; e. g. the
> > machined/nspawn/importd group pulls in a number of rather heavy
> > dependencies. udev (including hwdb) is something which you don't need
> > in containers, so we split that out too.
> > 
> > Another reason is to make it easy to enable/disable a particular
> > feature (e. g.  libnss-myhostname).
> > 
> > And then of course the infamous "need to run with sysvinit/upstart",
> > which other distros don't need to be concerned about :-)
> > 
> > > So I suggest following scheme
> > 
> > FTR, this isn't too far away what we already do in Debian/Ubuntu:
> > 
> > > systemd
> > 
> > check
> > 
> > > systemd-libs
> > > systemd-devel
> > 
> > They are called a bit differently for distro policy, upgrade safety,
> > consistency, and multi-arch support reasons; we need separate binary
> > packages for every lib*.so. But in spirit, "check".
> > 
> > > systemd-journal-remote (so gatewayd,remote,upload)
> > 
> > Check, we have exactly this package name.
> > 
> > > 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.
> > 
> > > systemd-machine (machined,nspawn,importd)
> > 
> > We call that package "systemd-container", but it has exactly those, so
> > "check".
> > 
> > > systemd-firstboot (firstboot,sysusers?,factory stuff?)
> > 
> > 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, after removing a bunch of stuff, hwdb stuff becomes even more
> pronounced.
> 
> 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.
> 
> [1] http://in.waw.pl/git/fedora-systemd/
> [2] https://copr.fedoraproject.org/coprs/zbyszek/systemd/build/138959/

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.

Zbyszek

___
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 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.?

It makes no sense to put them into the middle of a namespace that has decades 
of what had previously been pretty clear easy-to-follow traditions behind it.

It took several hours even to find wrong examples how to rename an interface 
using a PCI ID because the page didn't bother to explain the options it listed 
with any kind of examples. No new users are going to have much hope of making 
sense of any of the behavior of this. Of course, provided they even manage to 
follow the cryptic instructions to registed to update the wiki page if they do 
figure it out.

> they directly compare the values you'd see in `udevadm monitor --env` or 
> `udevadm info /sys/class/net/eth0`.

Thanks for these. It should help a lot in the future.

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

[Martin Pitt]

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.) and will take an extra 18.3 MB space. s-journal-remote by itself
is an extra 16.7 MB; but there's of course a lot of overlap with
s-container, installing both together are +19.3 MB.

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

[Matthew Hall]

On Thu, Nov 12, 2015 at 12:40:04AM -0500, Matthew Hall wrote:
> The process for adding an account on the FDO wiki is extremely confusing for 
> any non-expert users:
> 
> http://wiki.freedesktop.org/sitewranglers/wiki/401/
> 
> There is no way anybody that isn't a crypto geek will know how to do that. It 
> would be good if you could enable a CAPTCHA or web-based flow of some kind in 
> a way which will not cause a flood of spammers so mere mortals can actually 
> fix bugs in the pages.

Even better yet, the process rejects your email that contains a conventional 
PGP signed message instead of a one-line clearsigned PW hash. This is 1) not 
mentioned in the wiki page regarding the authentication, 2) so hostile to new 
users that essentially nobody would be capable of fixing it.

Matthew.
___
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 9:29 AM, Matthew Hall  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.?
>
> It makes no sense to put them into the middle of a namespace that has
> decades
> of what had previously been pretty clear easy-to-follow traditions behind
> it.
>

...Really not sure what you're complaining about, here.

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".

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

Re: [systemd-devel] about Authorization

[Martin Pitt]

Hello yankun,

yan...@iscas.ac.cn [2015-11-12  9:25 +0800]:
> Hey  guys:
>I try install systemd(219) in linux-mint17 .the deb package is from 
> Ubuntu15.04.except for I can not auto-mount  my U disk and  can configure the 
> network parametric.But when I use root to login, there is no problem.

These sound related to udisks and NetworkManager, not systemd itself.
This sounds like there's a problem with your policykit setup. But
without further details/logs (error messages, output of udisksctl
mount -d /dev/...) it's rather impossible to diagnose.

Also, this ML isn't the right forum for this.

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

[Jóhann B . Guðmundsson]

On 11/11/2015 04:04 PM, Reindl Harald wrote:



Am 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:

Why not systemd-devel?


Because these aren't development related discussion


this list was multiple times statet also as users-list by Lennart 
himself, just use Google to find that statement in the archive


I dont see to what relevance this being user list or development list is 
here.


These are discussion about integration of the building block of the OS 
in downstream distribution which upstream should only be involved with 
for guidance.
( upstream should never be maintaining their own component in downstream 
distribution for obvious reasons ).



and there is a need for separated collaborated git
repository to prevent duplication of downstream work etc.


why?


To coordinate and oversee and collectively share work done between 
distribution integrating the relevant components in their distribution.


Basically the same thing we ( we as in major distribution + few I 
personally never heard of ) did in 2011 with the exception that now 
Debian and Ubuntu have joined the party and we would have a shared git 
repository to use instead of everyone having one either on an individual 
level or distribution level.


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

[systemd-devel] systemctl suspend

[Steve Abner]

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
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.

  Thanx

___
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

[Jóhann B . Guðmundsson]

On 11/11/2015 08:28 PM, Michael Biebl wrote:

2015-11-11 21:21 GMT+01:00 Jóhann B. Guðmundsson :
[snip]

To coordinate and oversee and collectively share work done between
distribution integrating the relevant components in their distribution.

And now you started an unrelated meta-discussion. Please do that in a
separate thread and don't hijack this one.


Please discuss this downstream since downstream packaging is an 
downstream matter.


JBG
___
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 11.11.2015 um 21:21 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 04:04 PM, Reindl Harald wrote:



Am 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:

Why not systemd-devel?


Because these aren't development related discussion


this list was multiple times statet also as users-list by Lennart
himself, just use Google to find that statement in the archive


I dont see to what relevance this being user list or development list is
here


interesting - so what did you try to tell the world with "because these 
aren't development related discussion"?


you are just pissed off because you where not present at the conference 
and nobody asked you before talk aboput something - that's it - period





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

[Reindl Harald]

Am 11.11.2015 um 22:38 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 08:38 PM, Reindl Harald wrote:



Am 11.11.2015 um 21:21 schrieb Jóhann B. Guðmundsson:

Because these aren't development related discussion


this list was multiple times statet also as users-list by Lennart
himself, just use Google to find that statement in the archive


I dont see to what relevance this being user list or development list is
here


interesting - so what did you try to tell the world with "because
these aren't development related discussion"?


Last time I checked downstream distributions packaging problems is not
upstream development discussions.


what did you not understnd in that tis list is *not only for usptream 
development*?


and frankly if that "go away, you are downstream" attitude would get 
down a little bit *anybody* would benefit



you are just pissed off because you where not present at the
conference and nobody asked you before talk aboput something - that's
it - period


I have you know I chose rather to pay for a ticket to be shared with
individuals that could not afford it rather then participate in a
conference where the community was being charge for reflecting on itself.


oh my god



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

[Reindl Harald]

Am 11.11.2015 um 22:30 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 08:28 PM, Michael Biebl wrote:

2015-11-11 21:21 GMT+01:00 Jóhann B. Guðmundsson :
[snip]

To coordinate and oversee and collectively share work done between
distribution integrating the relevant components in their distribution.

And now you started an unrelated meta-discussion. Please do that in a
separate thread and don't hijack this one.


Please discuss this downstream since downstream packaging is an
downstream matter


and *you* decide that?

get the facts - without any downstream upstream would be meaningless and 
that's a matter of respect not only facts




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

[Jóhann B . Guðmundsson]

On 11/11/2015 08:38 PM, Reindl Harald wrote:



Am 11.11.2015 um 21:21 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 04:04 PM, Reindl Harald wrote:



Am 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:

Why not systemd-devel?


Because these aren't development related discussion


this list was multiple times statet also as users-list by Lennart
himself, just use Google to find that statement in the archive


I dont see to what relevance this being user list or development list is
here


interesting - so what did you try to tell the world with "because 
these aren't development related discussion"?


Last time I checked downstream distributions packaging problems is not 
upstream development discussions.




you are just pissed off because you where not present at the 
conference and nobody asked you before talk aboput something - that's 
it - period


I have you know I chose rather to pay for a ticket to be shared with 
individuals that could not afford it rather then participate in a 
conference where the community was being charge for reflecting on itself.


It's an ethical thing feel free to contact Nils if you need confirmation 
of that.


JBG
___
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

[poma]

On 11.11.2015 12:58, Martin Pitt 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-"?
> 
> 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?
> 
>> Other aspect would be minimizing external dependencies.
> 
> That is one important reason why we split them in Debian; e. g. the
> machined/nspawn/importd group pulls in a number of rather heavy
> dependencies. udev (including hwdb) is something which you don't need
> in containers, so we split that out too.
> 
> Another reason is to make it easy to enable/disable a particular
> feature (e. g.  libnss-myhostname).
> 
> And then of course the infamous "need to run with sysvinit/upstart",
> which other distros don't need to be concerned about :-)
> 
>> So I suggest following scheme
> 
> FTR, this isn't too far away what we already do in Debian/Ubuntu:
> 
>> systemd
> 
> check
> 
>> systemd-libs
>> systemd-devel
> 
> They are called a bit differently for distro policy, upgrade safety,
> consistency, and multi-arch support reasons; we need separate binary
> packages for every lib*.so. But in spirit, "check".
> 
>> systemd-journal-remote (so gatewayd,remote,upload)
> 
> Check, we have exactly this package name.
> 

"systemd-check"
+1


>> 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.
> 
>> systemd-machine (machined,nspawn,importd)
> 
> We call that package "systemd-container", but it has exactly those, so
> "check".
> 
>> systemd-firstboot (firstboot,sysusers?,factory stuff?)
> 
> 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.
> 
> Martin
> 

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

[systemd-devel] about socket

[yan...@iscas.ac.cn]

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!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel