[systemd-devel] [PATCH] hwdb: add sdio identifiers for Broadcom WLAN cards

[Arend van Spriel]

This patch adds the sdio identifiers known to be supported by
the brcmfmac open-source driver.

Cc: Marcel Holtmann 
Signed-off-by: Arend van Spriel 
---
 hwdb/sdio.ids | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/hwdb/sdio.ids b/hwdb/sdio.ids
index 8a4c713..d617297 100644
--- a/hwdb/sdio.ids
+++ b/hwdb/sdio.ids
@@ -34,6 +34,16 @@
5347  GDM72xx WiMAX
 02d0  Broadcom Corp.
044b  Nintendo Wii WLAN daughter card
+   a887  BCM43143 WLAN card
+   4324  BCM43241 WLAN card
+   4329  BCM4329 WLAN card
+   4330  BCM4330 WLAN card
+   4334  BCM4334 WLAN card
+   a94c  BCM43340 WLAN card
+   a94d  BCM43341 WLAN card
+   4335  BCM4335/BCM4339 WLAN card
+   a962  BCM43362 WLAN card
+   4354  BCM4354 WLAN card
 02db  SyChip Inc.
0002  Pegasus WLAN SDIO Card (6060SD)
 02df  Marvell Technology Group Ltd.
-- 
1.9.1

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

Re: [systemd-devel] [PATCH] hwdb: add sdio identifiers for Broadcom WLAN cards

[Vasiliy Tolstov]

2015-02-25 13:02 GMT+03:00 Arend van Spriel :
> This patch adds the sdio identifiers known to be supported by
> the brcmfmac open-source driver.


What about BCM43228 ?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-216 breaks combined ReadOnlyDirectories / ReadWriteDirectories

[Reindl Harald]

Am 28.01.2015 um 02:48 schrieb Lennart Poettering:

On Tue, 20.01.15 13:48, Reindl Harald (h.rei...@thelounge.net) wrote:


after upgrade to Fedora 21 with new systemd namespaces like below no longer
works which breaks *all my systemd-units*

why?

ReadOnlyDirectories=/var/lib
ReadWriteDirectories=/var/lib/mysql


I cannot reproduce this issue with systemd upstream. This appears to
work fine. Any chance you can try to reproduce this with current
upstream?

Do you have any other namespace-related settings in the unit file that
triggers this? Like ProtectSystem= or so? Can you paste the entire
unit file?


here is a sample unit and some tests
https://bugzilla.redhat.com/show_bug.cgi?id=1184016#c29

systemd-213-4.fc21 was the last build without that issue
see sample below, /var/lib/test/subfolder is owned by the user

in general i try to use as much as possible features to restrict 
services to their absolute minimum need

_

[root@rawhide ~]# cat /etc/systemd/system/test.service
[Unit]
Description=Test-Service

[Service]
Type=oneshot
User=nobody
Group=nobody
#PermissionsStartOnly=true
#ExecStartPre=/usr/bin/touch /var/lib/test/subfolder/test.txt
ExecStart=/usr/bin/touch /var/lib/test/subfolder/test.txt

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib/test
ReadWriteDirectories=/var/lib/test/subfolder
_

[root@rawhide ~]# stat /var/lib/test/
  File: '/var/lib/test/'
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 811h/2065d  Inode: 130889  Links: 3
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2015-02-23 16:41:32.523299826 +0100
Modify: 2015-02-23 16:41:38.617223191 +0100
Change: 2015-02-24 16:17:18.969601190 +0100
 Birth: -

[root@rawhide ~]# stat /var/lib/test/subfolder
  File: '/var/lib/test/subfolder'
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 811h/2065d  Inode: 130912  Links: 2
Access: (0755/drwxr-xr-x)  Uid: (   99/  nobody)   Gid: (   99/  nobody)
Access: 2015-02-24 16:17:19.021782540 +0100
Modify: 2015-02-24 15:01:51.760650707 +0100
Change: 2015-02-24 16:17:19.021782540 +0100
 Birth: -




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] [PATCH] hwdb: add sdio identifiers for Broadcom WLAN cards

[Arend van Spriel]

On 02/25/15 12:29, Vasiliy Tolstov wrote:

2015-02-25 13:02 GMT+03:00 Arend van Spriel:

This patch adds the sdio identifiers known to be supported by
the brcmfmac open-source driver.



What about BCM43228 ?


That's a PCIe device.

Regards,
Arend

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

Re: [systemd-devel] [RFC] core, login: wording

[Daniele Medri]

I disagree on your opinion, waiting for additional and more competent
comments...

D.
Il 25/feb/2015 05:56 "Zbigniew Jędrzejewski-Szmek"  ha
scritto:

> On Fri, Feb 20, 2015 at 11:01:18AM +0100, Daniele Medri wrote:
> > ---
> >  src/core/org.freedesktop.systemd1.policy.in.in | 6 +++---
> >  src/login/org.freedesktop.login1.policy.in | 8 
> >  2 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/core/org.freedesktop.systemd1.policy.in.in b/src/core/
> org.freedesktop.systemd1.policy.in.in
> > index cc39a9e..11a27de 100644
> > --- a/src/core/org.freedesktop.systemd1.policy.in.in
> > +++ b/src/core/org.freedesktop.systemd1.policy.in.in
> > @@ -39,7 +39,7 @@
> >
> >  
> >  <_description>Manage system service or unit
> files
> > -<_message>Authentication is required to manage system
> service or unit files.
> > +<_message>Authentication is required to handle system
> service or unit files. Doesn't seem to be an improvment.
>
> sage>
> >  
> >  auth_admin
> >  auth_admin
> > @@ -48,8 +48,8 @@
> >  
> >
> >  
> > -<_description>Set or unset system and service manager
> environment variables
> > +<_description>Configure system and service manager
> environment variables
> This is less specific than the original. I'd say that it is worse.
>
> > -<_message>Authentication is required to set or unset
> system and service manager environment variables.
> > +<_message>Authentication is required to handle system
> and service manager environment variables.
> This one too. "handle" could mean anything. "set or unset" is maybe not
> pretty, but
> at least very clear.
>
> >  
> >  auth_admin
> >  auth_admin
> > diff --git a/src/login/org.freedesktop.login1.policy.in b/src/login/
> org.freedesktop.login1.policy.in
> > index 35bb390..906fea2 100644
> > --- a/src/login/org.freedesktop.login1.policy.in
> > +++ b/src/login/org.freedesktop.login1.policy.in
> > @@ -271,8 +271,8 @@
> >  
> >
> >  
> > -<_description>Manager active sessions, users and
> seats
> > +<_description>Active sessions, users and seats
> management
> I think this was just a typo, extra "r", and the original wording is OK.
> This was actually already fixed in git.
>
> > -<_message>Authentication is required for managing
> active sessions, users and seats.
> > +<_message>Authentication is required to handle active
> sessions, users and seats.
> >  
> >  auth_admin_keep
> >  auth_admin_keep
> > @@ -281,8 +281,8 @@
> >  
> >
> >  
> > -<_description>Lock or unlock active
> sessions
> > -<_message>Authentication is required for locking or
> unlocking active sessions.
> > +<_description>Active sessions management
> > +<_message>Authentication is required to handle active
> sessions.
> Less specific.
>
> But we should say "to lock or unlock". I'll fix that.
>
> All in all, I think there's nothing to fix here.
>
> Zbyszek
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] machinectl create container via dbus

[Lennart Poettering]

On Wed, 25.02.15 02:22, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:

Heya,

> Hello =). I'm try to think about creating containers with
> systemd-nspawn and machinectl from dbus. Does it possibe?

We provide a small daemon "systemd-importd" that can import tar, raw
or dkr containers and place them in /var/lib/machines, doing gpg
verification, decompression, sparse file restoration and so
on. machinectl's "pull-tar", "pull-raw" and "pull-dkr" commands are
simply frontends for what systemd-importd provides.

You can also access importd from your own programs, this is supposed
to be a public API. However, there's currently no documentation for the
bus API, as this is a really recent addition (219), hence check
machinectl's sources for details, as well as "busctl introspect" and
"gdbus introspect.

> I need dbus because i have unprivileged app, that needs to create
> container and run it. I'm try libvirt, but it does not have ability to
> download image (only possible to use already prepared directory or
> downloaded image)

importd's APIs are opened up via policykit, hence when you rpovide the
right permission sets you can open this up to unprivileged users.

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] [Q] About supporting nested systemd daemon

[Lennart Poettering]

On Wed, 25.02.15 00:05, Cyrill Gorcunov (gorcu...@gmail.com) wrote:

> Hi all! I would really appreciate if someone enlighten me if there is some 
> simple
> solution for the problem we met in OpenVZ: modern containers are mostly 
> systemd
> based so that once it is started up the systemd daemon mounts own instance of
> the systemd cgroup (if previously has not been pre-mounted by container 
> startup
> tools or whatever). To make a strict isolation of nested systemd cgroup (by
> "nested" I mean systemd cgroup instance mounted inside container) we've 
> patched
> the kernel so that container's systemd obtains own instance of cgroup 
> non-intersected
> anyhow with one present on a host system.
> 
> And we would really love to get rid of this kind of kernel's hack but be able
> to isolate nested systemd with own cgroup instance using solely userspace
> tools. Is there some way to reach this?

Not really. cgroupfs doesn't really allow that. First of all the root
cgroup has a different set of attributes than child cgroups, hence you
cannot mount an arbitrary child to the root cgroup and assume it
works. But even worse, /proc/$PID/cgroup actually contains the full
cgroup path, and hence mounting only a subtree would break the
refernces from that file.

systemd-nspawn nowadays mounts all hierarchies into the container, but
mounts all controller hierarchies read-only, and of the name=systemd
hierarchy mounts everything read-only, except the subtree the
container is allowed to manage. That way only the cgroup tree the
container needs access to is writable to it. That solution however
does not hide the cgroup tree. A process running inside the container
can still go an explore the tree and its attributes. However, all
other groups will appear empty to it, since processes not in the
container PID namespaces will be suppressed when reading the member
process list.

There have been proposals on LKML to add cgroup namespacings, but no
idea where that went.

LXC created a FUSE emulation of /proc and /sys, called lxcfs to solve
this problem. Quite honestly I find this a pretty crazy idea however.

> If I understand correctly we can provide separate slice to container's
> systemd leaving the rest of host cgroup in ro mode, right?

Yes.

> If so maybe there a way to hide host cgroup completely from
> container so it would see only own cgroup in sysfs?

I don't see how this could work. I mean, you could overmount all other
cgroup siblings with empty directories in the containers, but not
realy scalable nor compatible with cgroups being added or removed
later 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] Enable port forwarding via upnp

[Mike Gilbert]

On Wed, Feb 25, 2015 at 2:16 AM, Kai Krakow  wrote:
> Hello!
>
> Is it possible to somehow create a service which enables port forwardings on
> my router using upnp? Currently, I guess it is not possible (except maybe
> using ExecPost or ExecPre and the upnpc program). But when my client IP
> changes via DHCP, it should be reapplied. Also, it needs to be maintained as
> the programmed port forwardings would timeout and be cleared from the router
> after a while. So it needs to be hooked up to systemd-networkd somehow (at
> least that is what I am using).
>
> Please advice and tell your thoughts. Maybe it is just plain insane...

It seems like it would be easy to do this using dhcpcd or dhclient via
a hook/script, assuming your DHCP lease times are shorter than the
UPnP timeout period.

I'm not sure if/how it would be possible when using networkd to
configure the interface.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Enable port forwarding via upnp

[Lennart Poettering]

On Wed, 25.02.15 08:16, Kai Krakow (hurikha...@gmail.com) wrote:

> Hello!
> 
> Is it possible to somehow create a service which enables port forwardings on 
> my router using upnp? Currently, I guess it is not possible (except maybe 
> using ExecPost or ExecPre and the upnpc program). But when my client IP 
> changes via DHCP, it should be reapplied. Also, it needs to be maintained as 
> the programmed port forwardings would timeout and be cleared from the router 
> after a while. So it needs to be hooked up to systemd-networkd somehow (at 
> least that is what I am using).

Not really. Such a upnp port setup tool could just subscribe to rtnl
and update the router's configuration dynamically each time the local
configuration is changed, without having to know anything about
networkd, NM or anything else.

That said I think it wouldn't be too far off I figure to add logic for
this to networkd. I mean, it speaks a variety of client side protocols
already, and this could just be one more. The major difference though
is that upnp is a frickin insane pseudo-HTTP XML craziness, while
DHCP, IPv4LL and so on are much more low-level. That said, I figure
we'll have some kind of HTTP logic in networkd eventually anyway to
support wispr and things like that, so maybe doing upnp wouldn't be
completely off either...

I figure if we can do this with existing deps, the internal XML parser
and so on, this could work. I.e. a minimal upnp port forwarding
library á la sd-dhcp would be acceptable...

> So I guess this logic should be built into systemd-networkd, maybe offering 
> some dbus interface also. And service and/or socket files could have a flag 
> to enable upnp forwards. This way, systemd-networkd knows about the 
> registered forwards and maintains them, and systemd will trigger 
> registration/unregistration on it whenever services start or stop which have 
> such flags enabled. By using dbus, this could be an interface implemented by 
> other network management daemons, too.

This is already the second step... It kinda opens another can of worms
though: we discussed on and off how integration between mDNS/DNS-SD
and .socket units could look like. This port forwarding thing and the
mDNS hookup are somewhat related: in both cases we have a concept of
actively registering with some external code as long as as a socket is
up.

Originally, when we discussed that in the mDNS context I thought of
simply using ExecStartPre= and ExecStopPre= for this, and forking off
a tool that pushes the mDNS registration into avahi/resolved as long
as the socket is up. But I ended not liking this idea, since in most
cases this would mean having one addition process around, that does
some bits when it starts up, then only hangs around, and then does a
bit more when it shuts down. Hanging around pointlessly is bad
though. So the next idea was maybe then PID 1 could simply call
directly into avahi/resolved via async bus calls, so that we have no
extra pointless processes hanging around.

However, that idea I don't like either, because it makes PID 1 client
of another daemon, and I really don't like that, I'd really prefer it
the other way round: the higher level daemons should call into the
lower level daemons, and subscribe to them, but the lower level
daemons should never call into the higher level daemons...

In networkd we followed this correct stacking design quite
nicely. networkd never pushes NTP servers into timesyncd or DNS
servers into resolved. Instead, timesyncd and resolved subscribe to
what networkd announces and pull the data out that. Most likely that's
the logic we should follow here too: 

- For the port forwarding logic we should introduce a new .socket
  property, that PID 1 doesn't really do much with, except exporting
  it on the bus

- networkd susbcribes to .socket units starting and stopping in
  PID 1, and pulls out that one property of them, and acting on it.

Similar, we would handle the mDNS case: the .socket units would gain a
new DNSSDService property, that resolved then keeps track of an
operates on.

I hope that makes some sense?

Lennart

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

[systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

[Ivan Shapovalov]

Because the order of coldplugging is not defined, we can reference a
not-yet-coldplugged unit and read its state while it has not yet been
set to a meaningful value.

This way, already active units may get started again.

We fix this by deferring such actions until all units have been at least
somehow coldplugged.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=88401
---

v2: set waiting state on path/timer units after deferring the actual coldplug,
so that we won't run into the exactly same problem during processing the
deferred entries.

 src/core/automount.c |  2 +-
 src/core/busname.c   |  2 +-
 src/core/device.c|  2 +-
 src/core/manager.c   | 33 -
 src/core/mount.c |  2 +-
 src/core/path.c  | 14 ++
 src/core/scope.c |  2 +-
 src/core/service.c   |  2 +-
 src/core/slice.c |  2 +-
 src/core/snapshot.c  |  2 +-
 src/core/socket.c|  2 +-
 src/core/swap.c  |  2 +-
 src/core/target.c|  2 +-
 src/core/timer.c | 14 ++
 src/core/unit.c  | 25 -
 src/core/unit.h  | 12 +---
 16 files changed, 88 insertions(+), 32 deletions(-)

diff --git a/src/core/automount.c b/src/core/automount.c
index 4a509ef..0539fbb 100644
--- a/src/core/automount.c
+++ b/src/core/automount.c
@@ -233,7 +233,7 @@ static void automount_set_state(Automount *a, 
AutomountState state) {
 unit_notify(UNIT(a), state_translation_table[old_state], 
state_translation_table[state], true);
 }
 
-static int automount_coldplug(Unit *u) {
+static int automount_coldplug(Unit *u, Hashmap *deferred_work) {
 Automount *a = AUTOMOUNT(u);
 int r;
 
diff --git a/src/core/busname.c b/src/core/busname.c
index 1d77292..43d7607 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -335,7 +335,7 @@ static void busname_set_state(BusName *n, BusNameState 
state) {
 unit_notify(UNIT(n), state_translation_table[old_state], 
state_translation_table[state], true);
 }
 
-static int busname_coldplug(Unit *u) {
+static int busname_coldplug(Unit *u, Hashmap *deferred_work) {
 BusName *n = BUSNAME(u);
 int r;
 
diff --git a/src/core/device.c b/src/core/device.c
index 2d983cc..70c2233 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -104,7 +104,7 @@ static void device_set_state(Device *d, DeviceState state) {
 unit_notify(UNIT(d), state_translation_table[old_state], 
state_translation_table[state], true);
 }
 
-static int device_coldplug(Unit *u) {
+static int device_coldplug(Unit *u, Hashmap *deferred_work) {
 Device *d = DEVICE(u);
 
 assert(d);
diff --git a/src/core/manager.c b/src/core/manager.c
index 79a9d54..239c8bb 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -975,8 +975,29 @@ static int manager_coldplug(Manager *m) {
 Unit *u;
 char *k;
 
+/*
+ * Some unit types tend to spawn jobs or check other units' state
+ * during coldplug. This is wrong because it is undefined whether the
+ * units in question have been already coldplugged (i. e. their state
+ * restored). This way, we can easily re-start an already started unit
+ * or otherwise make a wrong decision based on the unit's state.
+ *
+ * Solve this by providing a way for coldplug functions to defer
+ * such actions until after all units have been coldplugged.
+ *
+ * We store Unit* -> int(*)(Unit*).
+ *
+ * https://bugs.freedesktop.org/show_bug.cgi?id=88401
+ */
+_cleanup_hashmap_free_ Hashmap *deferred_work = NULL;
+int(*proc)(Unit*);
+
 assert(m);
 
+deferred_work = hashmap_new(&trivial_hash_ops);
+if (!deferred_work)
+return -ENOMEM;
+
 /* Then, let's set up their initial state. */
 HASHMAP_FOREACH_KEY(u, k, m->units, i) {
 int q;
@@ -985,7 +1006,17 @@ static int manager_coldplug(Manager *m) {
 if (u->id != k)
 continue;
 
-q = unit_coldplug(u);
+q = unit_coldplug(u, deferred_work);
+if (q < 0)
+r = q;
+}
+
+/* After coldplugging and setting up initial state of the units,
+ * let's perform operations which spawn jobs or query units' state. */
+HASHMAP_FOREACH_KEY(proc, u, deferred_work, i) {
+int q;
+
+q = proc(u);
 if (q < 0)
 r = q;
 }
diff --git a/src/core/mount.c b/src/core/mount.c
index 40037e7..ac91134 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -612,7 +612,7 @@ static void mount_set_state(Mount *m, MountState state) {
 m->reload_result = MOUNT_SUCCESS;
 }
 
-static int mount_coldplug(Unit *u) {
+static int mount_coldplug(Unit *u, Hashmap *deferred_work) {
 Mount *m = MOUNT(u);
 MountState new_state =

[systemd-devel] [PATCH] user-sessions: move into own subdir and build independently of logind

[Ivan Shapovalov]

Suggested by Zbyszek on IRC.

---

This does not conditionalize on HAVE_PAM. Don't know whether that's right.

 Makefile.am   | 37 
 man/systemd-user-sessions.service.xml |  2 +-
 src/login/Makefile|  1 -
 src/login/user-sessions.c | 80 ---
 src/user-sessions/Makefile|  1 +
 src/user-sessions/user-sessions.c | 80 +++
 6 files changed, 101 insertions(+), 100 deletions(-)
 delete mode 12 src/login/Makefile
 delete mode 100644 src/login/user-sessions.c
 create mode 12 src/user-sessions/Makefile
 create mode 100644 src/user-sessions/user-sessions.c

diff --git a/Makefile.am b/Makefile.am
index 93c0509..0378478 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -393,7 +393,8 @@ rootlibexec_PROGRAMS = \
systemd-sleep \
systemd-bus-proxyd \
systemd-socket-proxyd \
-   systemd-update-done
+   systemd-update-done \
+   systemd-user-sessions
 
 if HAVE_UTMP
 rootlibexec_PROGRAMS += \
@@ -554,7 +555,8 @@ nodist_systemunit_DATA = \
units/initrd-udevadm-cleanup-db.service \
units/initrd-switch-root.service \
units/systemd-nspawn@.service \
-   units/systemd-update-done.service
+   units/systemd-update-done.service \
+   units/systemd-user-sessions.service
 
 if HAVE_UTMP
 nodist_systemunit_DATA += \
@@ -607,7 +609,8 @@ EXTRA_DIST += \
units/initrd-udevadm-cleanup-db.service.in \
units/initrd-switch-root.service.in \
units/systemd-nsp...@.service.in \
-   units/systemd-update-done.service.in
+   units/systemd-update-done.service.in \
+   units/systemd-user-sessions.service.in
 
 CLEANFILES += \
units/console-shell.service.m4 \
@@ -2123,6 +2126,13 @@ systemd_update_done_LDADD = \
libsystemd-shared.la
 
 # 
--
+systemd_user_sessions_SOURCES = \
+   src/user-sessions/user-sessions.c
+
+systemd_user_sessions_LDADD = \
+   libsystemd-shared.la
+
+# 
--
 systemd_shutdownd_SOURCES = \
src/shutdownd/shutdownd.c
 
@@ -5903,15 +5913,8 @@ endif
 noinst_LTLIBRARIES += \
libsystemd-logind-core.la
 
-systemd_user_sessions_SOURCES = \
-   src/login/user-sessions.c
-
-systemd_user_sessions_LDADD = \
-   libsystemd-shared.la
-
 rootlibexec_PROGRAMS += \
-   systemd-logind \
-   systemd-user-sessions
+   systemd-logind
 
 loginctl_SOURCES = \
src/login/loginctl.c \
@@ -6011,8 +6014,7 @@ dist_pamconf_DATA = \
 endif
 
 nodist_systemunit_DATA += \
-   units/systemd-logind.service \
-   units/systemd-user-sessions.service
+   units/systemd-logind.service
 
 dist_systemunit_DATA += \
units/user.slice
@@ -6036,8 +6038,7 @@ INSTALL_DIRS += \
$(systemdstatedir)
 
 MULTI_USER_TARGET_WANTS += \
-   systemd-logind.service \
-   systemd-user-sessions.service
+   systemd-logind.service
 
 SYSTEM_UNIT_ALIASES += \
systemd-logind.service dbus-org.freedesktop.login1.service
@@ -6066,8 +6067,7 @@ EXTRA_DIST += \
src/login/logind-gperf.gperf \
src/login/71-seat.rules.in \
src/login/73-seat-late.rules.in \
-   units/systemd-logind.service.in \
-   units/systemd-user-sessions.service.in
+   units/systemd-logind.service.in
 
 # 
--
 if HAVE_PYTHON_DEVEL
@@ -6592,7 +6592,8 @@ LOCAL_FS_TARGET_WANTS += \
 
 MULTI_USER_TARGET_WANTS += \
getty.target \
-   systemd-ask-password-wall.path
+   systemd-ask-password-wall.path \
+   systemd-user-sessions.service
 
 SYSINIT_TARGET_WANTS += \
dev-hugepages.mount \
diff --git a/man/systemd-user-sessions.service.xml 
b/man/systemd-user-sessions.service.xml
index 9d796b1..9a228df 100644
--- a/man/systemd-user-sessions.service.xml
+++ b/man/systemd-user-sessions.service.xml
@@ -19,7 +19,7 @@
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see .
 -->
-
+
 
   
 systemd-user-sessions.service
diff --git a/src/login/Makefile b/src/login/Makefile
deleted file mode 12
index d0b0e8e..000
--- a/src/login/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-../Makefile
\ No newline at end of file
diff --git a/src/login/user-sessions.c b/src/login/user-sessions.c
deleted file mode 100644
index 1c31769..000
--- a/src/login/user-sessions.c
+++ /dev/null
@@ -1,80 +0,0 @@
-/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
-
-/***
-  This file is part of systemd.
-
-  Copyright 2010 Lennart Poettering
-
-  systemd is free software; you can redistribute it and/or modify it
-  under the terms of the GNU Lesser General Public License as published by
-  the Free Software Foundation; e

Re: [systemd-devel] Linking containers

[Lennart Poettering]

On Tue, 24.02.15 11:00, Peter Paule (systemd-de...@fedux.org) wrote:

> Hi,
> 
> while playing around with "systemd-nspawn" a lot in the last few days two
> things
> I'm really missing are links between containers like dkr supports
> https://docs.docker.com/userguide/dockerlinks/ and getting an ip within the
> container when running a single application like /usr/sbin/nginx and no
> container-internal dhcp-server.

dhcp client you mean?

In general, I am not really keen on doing IP configuration in
nspawn. We have one solution for doing IP configuration already in
systemd, and that's networkd, and it's a ton more powerful than
anything we could add to nspawn.

The general philosophy with nspawn I try to follow is that we invent
as little new concepts and configuration as possible. Specifically,
for network setup this means we use DHCP and all the other standard
technologies but avoid inventing any addition IP configuration
propagation protocol beyond that.

networkd is by default shipped in a way now that it will do dhcp
server stuff on the host for the network interfaces exposed by nspawn,
and dhcp client stuff in the container for the interface it sees
there. This stuff works now, and is really how I recommend what people
use on the host and in the container if they use nspawn. (Note that
networkd on the host only takes possession of these nspawn network
interaces by default, hence it's completely safe to run this in
parallel with NM or some other network configuration scheme, which is
used for the other interfaces).

I am quite interested to find ways to make all these things work
without using too many container-specific technologies. More
specifically this means I will always prefer a solution that could be
made work for kvm containers the same way as for containers. Solutions
involving env vars (like docker does it) are hence less than ideal
since they do not translate nicely to VMs...

> Are there plans to support something like that in future versions? Or are
> there better options to do the same things?
> 
> Example:
> 
>   systemd-nspawn -x -M db1 -D /var/lib/machines/centos-postgresql
> /usr/bin/postgresql
>   systemd-nspawn -x -M web_app2 -D /var/lib/machines/centos-nginx
> --link-with db1 /usr/sbin/nginx
> 
> I know that that there are some new options introduced with systemd 219, but I
> was not able to make it work for my use case.
> 
> * --port
> * --private-network
> * --network-veth
> 
> Did I understand it correctly, that I need to install systemd-networkd or some
> other dhcp-daemon to get an ip address for now?

Correct. You don#t really have to configure it as mentioned though. It
will just work out of the box.

> # The use case #
> 
> Here's my use case. I would like to run everything in containers to better
> separate web applications which use different software stacks - ruby, python,
> native code etc. - security is important for me but not my main concern using
> containers.
> 
> [ Client ] -->  [ Web Server 1 ] -+-> [ Web App 1 ] -+-> [ Database 1 ]
>   |  |
>   +-> [ Web App 2 ] -+
>   |
>   +-> [ Web Server 2 ]
> 
> My idea is to run an nginx-webserver as reverse proxy in front of some web
> application and other web servers. It should be responsible to route requests
> to the web applications/server.

So, my proposal to solve this would be like this: we could extend
nspawn's --network-bridge= setting so that it would allow creating a
bridge interface when the first container referencing it is created,
and ref-counting it by the containers using it. Maybe via a new switch
--network-bridge-make=foobar or so, where "foobar" is the name of this
bridge to create.

Then, for all containers that shall be linked one would specify the
same --network-bridge-make= parameter, so that they are all added to
the same bridge, and can thus communicate with each other. networkd
would be configured out-of-the-box to do dhcp server magic on the host
side for these kind of bridges, so that IP configuration works out of
the box again, fully automatically, as long as the containers run
networkd or some other DHCP client.

With that in place you could easily create arbitrary groups of
containers that can communicate with each other via IP. Now, the
question is how they would find each other. For that I'd simply use
LLMNR, and each container should just pick a descriptive host name,
and that's it. LLMNR support is built into systemd-resolved. As long as each
container runs resolved (or any other LLMNR implementation) it will be
found by the other containers on the network, and it can find the
other containers. The containers would simply reference each other by
host names, the way the unix gods intended it. There would not be any
further concept of passing configuration data about who talks to who
in this.

With this solution we have something that would work

Re: [systemd-devel] [Q] About supporting nested systemd daemon

[Cyrill Gorcunov]

On Wed, Feb 25, 2015 at 06:48:20PM +0100, Lennart Poettering wrote:
...
> 
> There have been proposals on LKML to add cgroup namespacings, but no
> idea where that went.

As far as I know they are still being discussed. Thanks a huge for reply, 
Lennart!
Need to figure out if we can use this nspawn facility.

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

[systemd-devel] USENIX/LISA conference in November 2015 seeks paid presenter for systemd tutorial

[Alison Chaiken]

The USENIX/LISA conference to be held in Washington, DC, USA in
November is seeking a paid presenter for a half-day tutorial about
systemd. I received an invitation to present a tutorial which I
will be happy to forward to anyone who would like to respond.I
have no information about the conference other than that in the
invitation.

https://www.usenix.org/conference/lisa15/call-for-participation/submission

Best wishes,
Alison

-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600http://{she-devel.com,
exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Shutting down service using systemd-nspawn

[Lennart Poettering]

On Tue, 24.02.15 09:39, Peter Paule (systemd-de...@fedux.org) wrote:

> Hi, any suggestions to cleanly shutdown containers?
> 
> If using defaults in a service file for stopping a container started with
> nspawn it will be killed by SIGTERM/SIGKILL. This makes "systemd-nspawn" to
> exit with
> "1" and the unit is marked as failed.

Hmm, nspawn actually passes the exit code it got from the container's
PID 1 on to its caller.

When nspawn itself gets SIGTERM it will send SIGRTMIN+3 to the
container's PID 1. In systemd that triggers an orderly shutdown, other
init systems have no nice way to trigger an orderly shutdown in a
similar way. When systemd runs nspawn as a service it will eventually
send SIGKILL to the service if SIGTERM does not shutdown the thing.

>   nginx@example_org.service - Webservice for example_org
>  Loaded: loaded (/etc/systemd/system/nginx@.service; enabled; vendor
> preset: disabled)
>  Active: failed (Result: exit-code) since Tue 2015-02-24 08:11:54 UTC;
> 25ms ago
> Process: 17351 ExecStart=/usr/bin/systemd-nspawn --register=no
> --ephemeral --bind-ro ${SSL_DIR}:/etc/ssl/nginx --bind-ro
> ${WWW_DIR}:/srv/www --bind ${LOG_DIR}:/var/log/nginx/ --bind-ro
> ${SITES_DIR}:/etc/nginx/sites-enabled/ --bind-ro
> ${CONFIG_DIR}:/etc/nginx/other-config/ -M docker-centos-nginx
> /usr/sbin/nginx (code=exited, status=1/FAILURE)
>Main PID: 17351 (code=exited, status=1/FAILURE)

In general: nspawn is primarily designed to run init-like processes as
PID 1 inside the container. If you run other code as PID 1 then you
will run into problems, since PID 1 is magic on UNIX, and your process
might not be able to deal with that fact. For example, it needs to
reap arbitrary children it doesn't expect, or it needs to handle
SIGWINCH, SIGINT, SIGPWR the right way. Or, so that that nspawn can
nicely shut down the container it ideally needs to handle SIGRTMIN+3.

Docker ignores the fact that PID 1 is special, and thus runs into
problems with daemons that do not reap unknown children. You can run
things the same way with nspawn, but if you do this you really need to
know what you are doing and the problems you run into with that.

I'd be willing to take a patch that adds --kill-signal= that allows
changing the kill signal from SIGRTMIN+3 to anything else. With that
you could use --kill-signal=SIGTERM to get the behaviour you want...

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] Enable port forwarding via upnp

[Kai Krakow]

Mike Gilbert  schrieb:

> On Wed, Feb 25, 2015 at 2:16 AM, Kai Krakow  wrote:
>> Hello!
>>
>> Is it possible to somehow create a service which enables port forwardings
>> on my router using upnp? Currently, I guess it is not possible (except
>> maybe using ExecPost or ExecPre and the upnpc program). But when my
>> client IP changes via DHCP, it should be reapplied. Also, it needs to be
>> maintained as the programmed port forwardings would timeout and be
>> cleared from the router after a while. So it needs to be hooked up to
>> systemd-networkd somehow (at least that is what I am using).
>>
>> Please advice and tell your thoughts. Maybe it is just plain insane...
> 
> It seems like it would be easy to do this using dhcpcd or dhclient via
> a hook/script, assuming your DHCP lease times are shorter than the
> UPnP timeout period.

Oh, I never thought about exploiting those hooks to do it. Nice idea. But...

> I'm not sure if/how it would be possible when using networkd to
> configure the interface.

I imagine something integrated with systemd, or more specific, with the 
Listen directives for socket activated systemd units, or specifying 
something like "ForwardPorts" for non-socket-activated units. See other 
post...

-- 
Replies to list only preferred.

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

Re: [systemd-devel] Enable port forwarding via upnp

[Kai Krakow]

Lennart Poettering  schrieb:

> On Wed, 25.02.15 08:16, Kai Krakow (hurikha...@gmail.com) wrote:
> 
>> Hello!
>> 
>> Is it possible to somehow create a service which enables port forwardings
>> on my router using upnp? Currently, I guess it is not possible (except
>> maybe using ExecPost or ExecPre and the upnpc program). But when my
>> client IP changes via DHCP, it should be reapplied. Also, it needs to be
>> maintained as the programmed port forwardings would timeout and be
>> cleared from the router after a while. So it needs to be hooked up to
>> systemd-networkd somehow (at least that is what I am using).
> 
> Not really. Such a upnp port setup tool could just subscribe to rtnl
> and update the router's configuration dynamically each time the local
> configuration is changed, without having to know anything about
> networkd, NM or anything else.

Okay, didn't know about rtnl. I will look into it. It makes sense to keep 
things separated to allow people to choose between networks, NM or anything 
else.

> That said I think it wouldn't be too far off I figure to add logic for
> this to networkd. I mean, it speaks a variety of client side protocols
> already, and this could just be one more. The major difference though
> is that upnp is a frickin insane pseudo-HTTP XML craziness, while
> DHCP, IPv4LL and so on are much more low-level. That said, I figure
> we'll have some kind of HTTP logic in networkd eventually anyway to
> support wispr and things like that, so maybe doing upnp wouldn't be
> completely off either...

To make sure we speak the same language: I propose to have a upnp client 
only, not a server - my system is a desktop, not a router. I just want to 
offer some services on my public router IP to get access from outside 
without having to resort to static IP assignment and without having to edit 
port numbers in two or more places. As far as I know, there's already a upnp 
client library one could link to and use that to talk to the upnp server on 
the router.

My idea is to add a config option to socket activated services which just 
reuses the Listen directives to publish the ports to upnp on the router. 
Maybe something like

[Socket]
ListenStream=22
PublishStream=yes

which would instruct yet the to be planned upnp client to create a port 
forwarding for 22/tcp on the router. The same could work for ListenDatagram. 
Of course this only makes sense, if sockets are not bound to localhost only.

It may make sense to move "PublishStream" to the service section of a unit 
(as "PublishStreams=yes") so it could publish all sockets from each socket 
unit associated with it - though I'm not sure if this is wanted as it moves 
socket logic into another section. And it probably doesn't make sense either 
because the service is started lazily when triggered by the sockets - which 
suggests the upnp mapping should have run earlier (when the socket unit was 
started).

But it would make sense for non-socket-activated services where the 
PublishStreams directive could just be reused in the following form:

[Service]
PublishStreams=22 # SSH server

or

[Service]
PublishStreams=80,443 # WWW server

[Service]
PublishDatagrams=51900-51999 # example service publishing 51900-99/udp

[Service]
PublishDatagrams=51900-51999:5190
  # publish 51900-99/udp as 5190-99/udp on eth*

[Service]
PublishStreams=8080:80 # publish 8080/tcp on the router as 80 on eth*


So instead of defining port mappings on the router manually, this would be 
done automatically, depending on which services/sockets are started.

> I figure if we can do this with existing deps, the internal XML parser
> and so on, this could work. I.e. a minimal upnp port forwarding
> library á la sd-dhcp would be acceptable...

It should not take much more than a wrapper around libminiupnpc.so, it's 
designed around having the smallest possible footprint:

http://miniupnp.free.fr/

It comes with a small test client program "upnpc" which provides all the 
stuff needed to implement the above ideas.

>> So I guess this logic should be built into systemd-networkd, maybe
>> offering some dbus interface also. And service and/or socket files could
>> have a flag to enable upnp forwards. This way, systemd-networkd knows
>> about the registered forwards and maintains them, and systemd will
>> trigger registration/unregistration on it whenever services start or stop
>> which have such flags enabled. By using dbus, this could be an interface
>> implemented by other network management daemons, too.
> 
> This is already the second step... It kinda opens another can of worms
> though: we discussed on and off how integration between mDNS/DNS-SD
> and .socket units could look like. This port forwarding thing and the
> mDNS hookup are somewhat related: in both cases we have a concept of
> actively registering with some external code as long as as a socket is
> up.
> 
> Originally, when we discussed that in the mDNS context I thought of
> simply using ExecStartPre= and Ex

Re: [systemd-devel] [PATCH 2/2] vconsole: set font on tty16..tty63 as well

[Lennart Poettering]

On Tue, 24.02.15 19:53, Jan Engelhardt (jeng...@inai.de) wrote:

> On Tuesday 2015-02-24 19:47, Lennart Poettering wrote:
> 
> >On Tue, 24.02.15 17:49, Jan Engelhardt (jeng...@inai.de) wrote:
> >
> >> The setup program would not set the font on tty16 upwards.
> >> There is a maximum of 63 VCs possible in Linux. (That number is
> >> hardcoded.)
> >
> >We deliberately do not support such high VTs in systemds.
> 
> And what's the rationale?

Initially it was that we had the "systemd" udev tag on all VCs, which
made them appear as .device units in systemd, and I really didn't want
63 of them. Then, some of the VC ioctls have a 16bit bitmap, which
makes the higher VCs not as accesible. Mostly it's now though that the
concept of having that many VCs is kinda crazy...

What's your usecase 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] Logroate + Pass signal to executable in container (nspawn)

[Lennart Poettering]

On Mon, 23.02.15 15:12, Peter Paule (systemd-de...@fedux.org) wrote:

> Hi,
> 
> I run "nginx" in a container which itself is under systemd-control. All
> error messages are put to stderr and the incomming requests are logged in
> access.log. To reduce the filesize I want to rotate the access.log.
> 
> I see two possibilities to make nginx release the file handle:
>   * Restart service
>   * Send signal USR1 or whatever it needs to the service

Well, as mentioned in the other mails: nspawn is really primarily
designed for running init systems, as the entire concept of PID
contaienrs on Linux. My recommendation would hence be: run systemd in
the container, make it run your nginx service as normal service, and
run the rotation stuff as .timer and .service unit within the
container, not outside of it.

> Does it make sense to send SIGUSR1 (or whatever signal it needs) to
> nginx to rotate the logs afterwards or is it ok to restart the whole
> service because systemd will buffer all incoming request - though socket
> activation is not in use? I'm not sure, what's best for this use
> case.

This will not work. Neither with nor without socket activation, as all
ongoing connections would be abruptly terminated.

> And to make things easier for you to read, here's the expanded exec start
> commandline
> 
>   /usr/bin/systemd-nspawn \
> --register=no \
> --ephemeral \
> --bind-ro /etc/ssl/machines/www_example_org:/etc/ssl/nginx \
> --bind-ro /srv/machines/www_example_org:/srv/www \
> --bind /var/log/machines/www_example_org:/var/log/nginx/ \
> --bind-ro
> /etc/machines/www_example_org/sites-enabled:/etc/nginx/sites-enabled/ \
> --bind-ro
> /etc/machines/www_example_org/other-config:/etc/nginx/other-config/ \
> -M docker-centos-nginx \
> /usr/sbin/nginx

One option is to use --register=yes (the default), then machined will
know about the container, and you can send signal to its PID 1 via
"machinectl kill".

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] Enable port forwarding via upnp

[Lennart Poettering]

On Wed, 25.02.15 21:14, Kai Krakow (hurikha...@gmail.com) wrote:

> > That said I think it wouldn't be too far off I figure to add logic for
> > this to networkd. I mean, it speaks a variety of client side protocols
> > already, and this could just be one more. The major difference though
> > is that upnp is a frickin insane pseudo-HTTP XML craziness, while
> > DHCP, IPv4LL and so on are much more low-level. That said, I figure
> > we'll have some kind of HTTP logic in networkd eventually anyway to
> > support wispr and things like that, so maybe doing upnp wouldn't be
> > completely off either...
> 
> To make sure we speak the same language: I propose to have a upnp client 
> only, not a server - my system is a desktop, not a router. 

Yes, that's what I understood.

> I just want to offer some services on my public router IP to get
> access from outside without having to resort to static IP assignment
> and without having to edit port numbers in two or more places. As
> far as I know, there's already a upnp client library one could link
> to and use that to talk to the upnp server on the router.

Well, to get this natively integrated in networkd I'd prefer avoiding
an extra dep. I wonder if we can avoid pulling this in if we stick to
the minimal upnp bits necessary to set up the port forwarding. I mean,
this is after all just a client, not a server...

> My idea is to add a config option to socket activated services which just 
> reuses the Listen directives to publish the ports to upnp on the router. 
> Maybe something like
> 
> [Socket]
> ListenStream=22
> PublishStream=yes
> 
> which would instruct yet the to be planned upnp client to create a port 
> forwarding for 22/tcp on the router. The same could work for ListenDatagram. 
> Of course this only makes sense, if sockets are not bound to
> localhost only.

Yeah, I agree. Though I'd explicitly clarify that this is about
Upnp. Hence call it ExposeUPNP= or so.

> It may make sense to move "PublishStream" to the service section of a unit 
> (as "PublishStreams=yes") so it could publish all sockets from each socket 
> unit associated with it - though I'm not sure if this is wanted as it moves 
> socket logic into another section. And it probably doesn't make sense either 
> because the service is started lazily when triggered by the sockets - which 
> suggests the upnp mapping should have run earlier (when the socket unit was 
> started).
> 
> But it would make sense for non-socket-activated services where the 
> PublishStreams directive could just be reused in the following form:
> 
> [Service]
> PublishStreams=22 # SSH server

I'd avoid this. If people don't use socket activation, then they
might as well configure this in networkd itself...

> It should not take much more than a wrapper around libminiupnpc.so, it's 
> designed around having the smallest possible footprint:
> 
> http://miniupnp.free.fr/
> 
> It comes with a small test client program "upnpc" which provides all the 
> stuff needed to implement the above ideas.

Hmm, the API doesn't look that great to me that I'd be enthusiastic to
depend on this I must say...

> > Similar, we would handle the mDNS case: the .socket units would gain a
> > new DNSSDService property, that resolved then keeps track of an
> > operates on.
> > 
> > I hope that makes some sense?
> 
> Well, then I suppose it would be better to have a standalone daemon, let's 
> call it systemd-upnpclientd.
> 
> This service would subscribe to rtnl you mentioned above. This will make it 
> independent of systemd-networkd and could support other implementations like 
> NM etc.

Sure, you could hack that up with the daemon that miniupnp provides.

> Next step, I'm not sure however: It also needs to gain knowledge about every 
> socket monitored by systemd and every socket mentioned in service files, as 
> outlined in my examples. But I'm sure PID1 could simply export such 
> information. Or alternatively: You mentioned that one could subscribe to 
> units starting and stopping, so we could simply pull out the information 
> needed.

PID 1 exports this already, via dbus. It's all readily accessible.

> I currently see problems with both approaches:
> 
> When getting exported info from systemd about sockets to be published on the 
> router: How do we get notified about changes introduced by starting or 
> stopping units?

bus signals are sent out when units change their state.

> When subscribing to starting and stopping of units, how do we pull the info 
> from the unit files if systemd-upnpclientd gets started after some units 
> wanting to publish sockets are already up?

they are exposed as properties on the bus.

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] Shutting down service using systemd-nspawn

[Lennart Poettering]

On Wed, 25.02.15 20:35, Lennart Poettering (lenn...@poettering.net) wrote:

> I'd be willing to take a patch that adds --kill-signal= that allows
> changing the kill signal from SIGRTMIN+3 to anything else. With that
> you could use --kill-signal=SIGTERM to get the behaviour you want...

I implemented this now:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=c6c8f6e218995852350e5e35c080dec788c42c3f

Enjoy,

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] Enable port forwarding via upnp

[Kai Krakow]

Lennart Poettering  schrieb:

> On Wed, 25.02.15 21:14, Kai Krakow (hurikha...@gmail.com) wrote:
> 
>> > That said I think it wouldn't be too far off I figure to add logic for
>> > this to networkd. I mean, it speaks a variety of client side protocols
>> > already, and this could just be one more. The major difference though
>> > is that upnp is a frickin insane pseudo-HTTP XML craziness, while
>> > DHCP, IPv4LL and so on are much more low-level. That said, I figure
>> > we'll have some kind of HTTP logic in networkd eventually anyway to
>> > support wispr and things like that, so maybe doing upnp wouldn't be
>> > completely off either...
>> 
>> To make sure we speak the same language: I propose to have a upnp client
>> only, not a server - my system is a desktop, not a router.
> 
> Yes, that's what I understood.

Fine. :-)

>> I just want to offer some services on my public router IP to get
>> access from outside without having to resort to static IP assignment
>> and without having to edit port numbers in two or more places. As
>> far as I know, there's already a upnp client library one could link
>> to and use that to talk to the upnp server on the router.
> 
> Well, to get this natively integrated in networkd I'd prefer avoiding
> an extra dep. I wonder if we can avoid pulling this in if we stick to
> the minimal upnp bits necessary to set up the port forwarding. I mean,
> this is after all just a client, not a server...

I'm not sure if I'd like to have it in networkd natively after all. But I 
agree to pulling in only the minimal upnp bits. There's also NAT-PMP which 
is much simpler but probably much less common on generic consumer routers, 
plus it can only do single port forwardings.

>> My idea is to add a config option to socket activated services which just
>> reuses the Listen directives to publish the ports to upnp on the router.
>> Maybe something like
>> 
>> [Socket]
>> ListenStream=22
>> PublishStream=yes
>> 
>> which would instruct yet the to be planned upnp client to create a port
>> forwarding for 22/tcp on the router. The same could work for
>> ListenDatagram. Of course this only makes sense, if sockets are not bound
>> to localhost only.
> 
> Yeah, I agree. Though I'd explicitly clarify that this is about
> Upnp. Hence call it ExposeUPNP= or so.

Good point, I like that suggestion. But how would you differentiate udp and 
tcp then?

>> It may make sense to move "PublishStream" to the service section of a
>> unit (as "PublishStreams=yes") so it could publish all sockets from each
>> socket unit associated with it - though I'm not sure if this is wanted as
>> it moves socket logic into another section. And it probably doesn't make
>> sense either because the service is started lazily when triggered by the
>> sockets - which suggests the upnp mapping should have run earlier (when
>> the socket unit was started).
>> 
>> But it would make sense for non-socket-activated services where the
>> PublishStreams directive could just be reused in the following form:
>> 
>> [Service]
>> PublishStreams=22 # SSH server
> 
> I'd avoid this. If people don't use socket activation, then they
> might as well configure this in networkd itself...

Yeah, I already thought about that, too. And now that you also mention it, 
I'd like to follow that idea. So, while (see above) I think the function 
should be provided as a separate daemon, it would have it's own 
configuration file - similar to how journald has it, or even networkd has it 
with its /etc/systemd/network configuration directory.

I'd even suggest one could simply let alone service files and just list the 
mappings here, independent of services. The user would just list all tcp and 
udp sockets to expose via the router, and "systemd-upnpclientd" would match 
up those ports with tcp and udp listening sockets as they appear and vanish.

Such a configuration could be made up of multiple files so complete feature 
sets or single services could be configured with single files. The daemon 
reads all files and compiles it into one configuration at runtime:

# ls /etc/systemd/upnp-mappings.d/
lamp-stack.conf
ssh.conf

# cat lamp-stack.conf
[ExposeTCP]
Ports=80,443,3306

# cat ssh.conf
[ExposeTCP]
Ports=22022:22 # map external port 22022 to local port 22

What do you think?

>> It should not take much more than a wrapper around libminiupnpc.so, it's
>> designed around having the smallest possible footprint:
>> 
>> http://miniupnp.free.fr/
>> 
>> It comes with a small test client program "upnpc" which provides all the
>> stuff needed to implement the above ideas.
> 
> Hmm, the API doesn't look that great to me that I'd be enthusiastic to
> depend on this I must say...

I didn't look at the API yet (just very very roughly) though I prefer to 
reuse work already done. Do you think your concern is an as big issue if it 
was used by a separate daemon only even if it would become part of the 
systemd distribution?

OTOH, that library could be used as a template t

[systemd-devel] How to make debug-shell more usable?

[Michael Biebl]

Hi,

if one is trying to debug (eary-)boot issues, debug-shell.service is a
handy tool.

Unfortunately there is the very unpleasant side effect, that systemd
spews all log messages to tty9, once you switched to that tty, making
it almost impossible to work on this shell.
If it reaches a timeout for a critical device, the emergency shell is
even started on tty9, if debug-shell is active. At this point, the
debug shell becomes basically useless, as you have two processes
fighting over tty9.


Is there a way to make tty9/debug-shell more usable, by restricting
the log messages  to tty1 / have emergency mode always be started on
tty1?

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] How to make debug-shell more usable?

[Lennart Poettering]

On Thu, 26.02.15 00:36, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,
> 
> if one is trying to debug (eary-)boot issues, debug-shell.service is a
> handy tool.
> 
> Unfortunately there is the very unpleasant side effect, that systemd
> spews all log messages to tty9, once you switched to that tty, making
> it almost impossible to work on this shell.

What precisely is supposedly written there? I have never seen anythign
like that on FEdora...

Maybe you should reconfigure your kernel to not spew its output always
on the console?

Lennart

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

[systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications

[Ivan Shapovalov]

This is useful, for example, to create system accounts on an initramfs
using the host's configuration.
---
 src/sysusers/sysusers.c | 97 +
 1 file changed, 66 insertions(+), 31 deletions(-)

diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 0b5668a..9d39bd4 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -64,7 +64,7 @@ typedef struct Item {
 bool todo_group:1;
 } Item;
 
-static char *arg_root = NULL;
+static char *arg_root_config = NULL, *arg_root_dest = NULL;
 
 static const char conf_file_dirs[] = CONF_DIRS_NULSTR("sysusers");
 
@@ -79,7 +79,7 @@ static uid_t search_uid = UID_INVALID;
 static UidRange *uid_range = NULL;
 static unsigned n_uid_range = 0;
 
-#define fix_root(x) (arg_root ? strjoina(arg_root, x) : x)
+#define fix_root_dest(x) (arg_root_dest ? strjoina(arg_root_dest, x) : x)
 
 static int load_user_database(void) {
 _cleanup_fclose_ FILE *f = NULL;
@@ -87,7 +87,7 @@ static int load_user_database(void) {
 struct passwd *pw;
 int r;
 
-passwd_path = fix_root("/etc/passwd");
+passwd_path = fix_root_dest("/etc/passwd");
 f = fopen(passwd_path, "re");
 if (!f)
 return errno == ENOENT ? 0 : -errno;
@@ -139,7 +139,7 @@ static int load_group_database(void) {
 struct group *gr;
 int r;
 
-group_path = fix_root("/etc/group");
+group_path = fix_root_dest("/etc/group");
 f = fopen(group_path, "re");
 if (!f)
 return errno == ENOENT ? 0 : -errno;
@@ -368,7 +368,7 @@ static int write_files(void) {
 _cleanup_fclose_ FILE *original = NULL;
 
 /* First we update the actual group list file */
-group_path = fix_root("/etc/group");
+group_path = fix_root_dest("/etc/group");
 r = fopen_temporary_label("/etc/group", group_path, &group, 
&group_tmp);
 if (r < 0)
 goto finish;
@@ -447,7 +447,7 @@ static int write_files(void) {
 }
 
 /* OK, now also update the shadow file for the group list */
-gshadow_path = fix_root("/etc/gshadow");
+gshadow_path = fix_root_dest("/etc/gshadow");
 r = fopen_temporary_label("/etc/gshadow", gshadow_path, 
&gshadow, &gshadow_tmp);
 if (r < 0)
 goto finish;
@@ -513,7 +513,7 @@ static int write_files(void) {
 long lstchg;
 
 /* First we update the user database itself */
-passwd_path = fix_root("/etc/passwd");
+passwd_path = fix_root_dest("/etc/passwd");
 r = fopen_temporary_label("/etc/passwd", passwd_path, &passwd, 
&passwd_tmp);
 if (r < 0)
 goto finish;
@@ -598,7 +598,7 @@ static int write_files(void) {
 }
 
 /* The we update the shadow database */
-shadow_path = fix_root("/etc/shadow");
+shadow_path = fix_root_dest("/etc/shadow");
 r = fopen_temporary_label("/etc/shadow", shadow_path, &shadow, 
&shadow_tmp);
 if (r < 0)
 goto finish;
@@ -772,7 +772,7 @@ static int uid_is_ok(uid_t uid, const char *name) {
 return 0;
 
 /* Let's also check via NSS, to avoid UID clashes over LDAP and such, 
just in case */
-if (!arg_root) {
+if (!arg_root_dest) {
 errno = 0;
 p = getpwuid(uid);
 if (p)
@@ -792,10 +792,10 @@ static int uid_is_ok(uid_t uid, const char *name) {
 return 1;
 }
 
-static int root_stat(const char *p, struct stat *st) {
+static int root_dest_stat(const char *p, struct stat *st) {
 const char *fix;
 
-fix = fix_root(p);
+fix = fix_root_dest(p);
 if (stat(fix, st) < 0)
 return -errno;
 
@@ -811,7 +811,7 @@ static int read_id_from_file(Item *i, uid_t *_uid, gid_t 
*_gid) {
 assert(i);
 
 /* First, try to get the gid directly */
-if (_gid && i->gid_path && root_stat(i->gid_path, &st) >= 0) {
+if (_gid && i->gid_path && root_dest_stat(i->gid_path, &st) >= 0) {
 gid = st.st_gid;
 found_gid = true;
 }
@@ -819,7 +819,7 @@ static int read_id_from_file(Item *i, uid_t *_uid, gid_t 
*_gid) {
 /* Then, try to get the uid directly */
 if ((_uid || (_gid && !found_gid))
 && i->uid_path
-&& root_stat(i->uid_path, &st) >= 0) {
+&& root_dest_stat(i->uid_path, &st) >= 0) {
 
 uid = st.st_uid;
 found_uid = true;
@@ -837,7 +837,7 @@ static int read_id_from_file(Item *i, uid_t *_uid, gid_t 
*_gid) {
 if (found_gid) {
 uid = (uid_t) gid;
 fo

[systemd-devel] [PATCH 0/3] using firstboot and sysusers to construct an initramfs

[Ivan Shapovalov]

Hi there.

These patches allow using firstboot and sysusers together to construct an
initramfs with a fully functional emergency.service and rescue.service.

Moreover, they allow to build a "clean" passwd for the initramfs and don't
resort to copying it from the host system (as it has been done in Arch's
mkinitcpio).

The first one allows sysusers to take configuration from the real root
but to apply it to a specified alternate root.

The next two patches fix an apparent integration problem between firstboot
and sysusers, as previously described here:
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028355.html

All in all, with this series I'm able to do a simple

systemd-firstboot --root="$BUILDROOT" --root-password=""
systemd-sysusers --dest-root="$BUILDROOT"

and, after adding respective units and /sbin/sulogin to the initramfs,
to use "rd.systemd.unit=rescue.target" as a complete alternative to pre-systemd
arch-specific "break=premount" kernel parameter.

Ivan Shapovalov (3):
  sysusers: allow separate alternate roots for configs and modifications
  firstboot: set all spwd fields to -1 for consistency with sysusers
  sysusers: do not reject users with already present /etc/shadow entries

 src/firstboot/firstboot.c |   6 +--
 src/sysusers/sysusers.c   | 120 +-
 2 files changed, 78 insertions(+), 48 deletions(-)

-- 
2.3.0

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

[systemd-devel] [PATCH 3/3] sysusers: do not reject users with already present /etc/shadow entries

[Ivan Shapovalov]

This is needed to interoperate firstboot and sysusers. The former one is started
first, and it writes only /etc/shadow when it is told to set the root password.
It's better to relax checks here than to duplicate functionality in firstboot.
---
 src/sysusers/sysusers.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 9d39bd4..ec3e8ad 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -603,6 +603,8 @@ static int write_files(void) {
 if (r < 0)
 goto finish;
 
+lstchg = (long) (now(CLOCK_REALTIME) / USEC_PER_DAY);
+
 original = fopen(shadow_path, "re");
 if (original) {
 struct spwd *sp;
@@ -616,8 +618,13 @@ static int write_files(void) {
 
 i = hashmap_get(users, sp->sp_namp);
 if (i && i->todo_user) {
-r = -EEXIST;
-goto finish;
+/* we will update the existing entry */
+sp->sp_lstchg = lstchg;
+
+/* only the /etc/shadow stage is left, 
so we can
+ * safely remove the item from the 
todo set */
+i->todo_user = false;
+hashmap_remove(todo_uids, 
UID_TO_PTR(i->uid));
 }
 
 errno = 0;
@@ -640,7 +647,6 @@ static int write_files(void) {
 goto finish;
 }
 
-lstchg = (long) (now(CLOCK_REALTIME) / USEC_PER_DAY);
 HASHMAP_FOREACH(i, todo_uids, iterator) {
 struct spwd n = {
 .sp_namp = i->name,
@@ -877,7 +883,6 @@ static int add_user(Item *i) {
 
 if (!arg_root_dest) {
 struct passwd *p;
-struct spwd *sp;
 
 /* Also check NSS */
 errno = 0;
@@ -893,16 +898,6 @@ static int add_user(Item *i) {
 }
 if (!IN_SET(errno, 0, ENOENT))
 return log_error_errno(errno, "Failed to check if user 
%s already exists: %m", i->name);
-
-/* And shadow too, just to be sure */
-errno = 0;
-sp = getspnam(i->name);
-if (sp) {
-log_error("User %s already exists in shadow database, 
but not in user database.", i->name);
-return -EBADMSG;
-}
-if (!IN_SET(errno, 0, ENOENT))
-return log_error_errno(errno, "Failed to check if user 
%s already exists in shadow database: %m", i->name);
 }
 
 /* Try to use the suggested numeric uid */
-- 
2.3.0

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

[systemd-devel] [PATCH 2/3] firstboot: set all spwd fields to -1 for consistency with sysusers

[Ivan Shapovalov]

---
 src/firstboot/firstboot.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/firstboot/firstboot.c b/src/firstboot/firstboot.c
index a765d6d..a37ca17 100644
--- a/src/firstboot/firstboot.c
+++ b/src/firstboot/firstboot.c
@@ -525,9 +525,9 @@ static int process_root_password(void) {
 
 struct spwd item = {
 .sp_namp = (char*) "root",
-.sp_min = 0,
-.sp_max = 9,
-.sp_warn = 7,
+.sp_min = -1,
+.sp_max = -1,
+.sp_warn = -1,
 .sp_inact = -1,
 .sp_expire = -1,
 .sp_flag = (unsigned long) -1, /* this appears to be what 
everybody does ... */
-- 
2.3.0

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

Re: [systemd-devel] [PATCH 0/3] using firstboot and sysusers to construct an initramfs

[Ivan Shapovalov]

On 2015-02-26 at 02:46 +0300, Ivan Shapovalov wrote:
> Hi there.
> 
> These patches allow using firstboot and sysusers together to construct an
> initramfs with a fully functional emergency.service and rescue.service.
> 
> Moreover, they allow to build a "clean" passwd for the initramfs and don't
> resort to copying it from the host system (as it has been done in Arch's
> mkinitcpio).
> 
> The first one allows sysusers to take configuration from the real root
> but to apply it to a specified alternate root.
> 
> The next two patches fix an apparent integration problem between firstboot
> and sysusers, as previously described here:
> http://lists.freedesktop.org/archives/systemd-devel/2015-February/028355.html
> 
> All in all, with this series I'm able to do a simple
> 
>   systemd-firstboot --root="$BUILDROOT" --root-password=""
>   systemd-sysusers --dest-root="$BUILDROOT"
> 
> and, after adding respective units and /sbin/sulogin to the initramfs,
> to use "rd.systemd.unit=rescue.target" as a complete alternative to 
> pre-systemd
> arch-specific "break=premount" kernel parameter.
>
> [...]

Forgot to add Dave Reisner to Cc:.

Dave, what do you think about all this? If this is a bad idea, then I'm
open for suggestions.
I just miss these "break=..." from the pre-systemd era.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to make debug-shell more usable?

[Michael Biebl]

2015-02-26 0:44 GMT+01:00 Lennart Poettering :
> What precisely is supposedly written there? I have never seen anythign
> like that on FEdora...
>
> Maybe you should reconfigure your kernel to not spew its output always
> on the console?

Well, if you want to debug boot issues, you typically remove the quiet
flag from the kernel command line. That aside, once systemd hits a
timeout or a service failure, it switches to verbose mode
automatically.

To reproduce the problem, add e.g. a non-existing device to /etc/fstab

The "Waiting for device to show up ..." messages are printed all over tty9.

Also, as mentioned, once the 90 sec timeout has been reached and tty9
is the active tty, the emergency shell is started on tty9 with the
aforementioned issues.


-- 
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] How to make debug-shell more usable?

[Michael Biebl]

2015-02-26 0:55 GMT+01:00 Michael Biebl :
> To reproduce the problem, add e.g. a non-existing device to /etc/fstab
>
> The "Waiting for device to show up ..." messages are printed all over tty9.

And just in case you have plymouth enabled, make sure to remove
"splash" from the kernel command line.


-- 
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] How to make debug-shell more usable?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 26, 2015 at 01:04:55AM +0100, Michael Biebl wrote:
> 2015-02-26 0:55 GMT+01:00 Michael Biebl :
> > To reproduce the problem, add e.g. a non-existing device to /etc/fstab
> >
> > The "Waiting for device to show up ..." messages are printed all over tty9.
We made rescue.service conflict with emergency.service for similar
reasons some time ago. We could do something similar here. OTOH,
killing debug-shell.service to start emergency.service does not seem
useful. So maybe we could hardcode not starting emergency.service in case
debug-shell.service is already running.

Zbyszek
 
> And just in case you have plymouth enabled, make sure to remove
> "splash" from the kernel command line.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] requiring all template instances in a service

[Benjamin Rose]

Hello all,

I hope this is the right place for this inquiry. I was noticing 
extremely slow reboot times on three of my hosts running 
corosync/pacemaker for shared storage. I enabled the systemd debug logs, 
and found that pacemaker was attempting to communicate with it's peers 
to notify of the shutdown, and failed to do so as networking was not 
functioning. This was odd because networking was fine during normal 
operation and the distribution's unit file has the proper "Requires" for 
networking. Eventually it hit the distro "TimeoutStopSec=30m" and forced 
the reboot, hence the slow reboot times.


In the debug logs, I found that it was all because I am using teamd 
(partially related - through ifcfg files using network.service), and 
teamd was being killed long before pacemaker got the chance to send its 
closing messages. So, I fixed the problem in my implementation with this 
little bit:


[root@myhost ~]# cat 
/etc/systemd/system/pacemaker.service.d/require_teamd.conf

[Unit]
After=teamd@team_pub.service
After=teamd@team_priv.service
Requires=teamd@team_pub.service
Requires=teamd@team_priv.service

But, soon I will be changing a lot about my networking. I'll be using 
puppet to deploy a few more teams and bridges on this host. So, my 
question comes down to - is there a way to accomplish something like this:


Requires=teamd@*.service
After=teamd@*.service

to include all running instances? I know this makes no sense in an 
xinetd-type situation on bootup, when instances will be created 
on-demand, but it does make perfect sense on a shutdown or reboot to 
want to wait for all instances of a certain type to complete their work 
before proceeding.


Thanks for your time,
Ben
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] looking for an 'uptime' value from a journal entry

[Chris Morgan]

Hello.

I'm looking to store some process tick values from /proc//stat
into the journal and retrieve them later to look at cpu load. This
information is most useful if I can also retrieve how long the system
has been up since last boot.

From 
http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#__MONOTONIC_TIMESTAMP=
it looks like __MONOTONIC_TIMESTAMP might be just what I'm looking for
but the information at the start of that section has me wondering if I
can rely on this __MONOTONIC_TIMESTAMP being present for all entries
and use this as the system uptime.

Thoughts?

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

Re: [systemd-devel] looking for an 'uptime' value from a journal entry

[Daurnimator]

On 25 February 2015 at 20:50, Chris Morgan  wrote:

> From
> http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#__MONOTONIC_TIMESTAMP=
> it looks like __MONOTONIC_TIMESTAMP might be just what I'm looking for
> but the information at the start of that section has me wondering if I
> can rely on this __MONOTONIC_TIMESTAMP being present for all entries
> and use this as the system uptime.
>

Those three fields will always be present.
They are not *in* the data, but metadata kept for every journal entry.
At the libsystemd level, you access them via their own apis, see
http://www.freedesktop.org/software/systemd/man/sd_journal_get_cutoff_monotonic_usec.html

Please refer to `man 2 clock_gettime` on whether CLOCK_MONOTONIC suits your
needs for an 'uptime' clock.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core: emit changes for NFailedUnits property

[Lucas De Marchi]

Ping?

-- 
Lucas De Marchi

On Wed, Feb 18, 2015 at 2:22 PM,   wrote:
> From: Lucas De Marchi 
>
> By notifying the clients when this property is changed it's possible to
> allow "system health monitor" tools to get transitions like
> running<->degraded. This is an alternative to send changes on the
> SystemState property since the latter is more difficult to derive.
> ---
>  src/core/dbus-manager.c | 20 +++-
>  src/core/dbus-manager.h |  1 +
>  src/core/manager.c  | 17 +
>  src/core/manager.h  |  2 ++
>  src/core/unit.c |  7 ++-
>  5 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
> index 8ba665d..5e83afb 100644
> --- a/src/core/dbus-manager.c
> +++ b/src/core/dbus-manager.c
> @@ -1949,7 +1949,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
>  SD_BUS_WRITABLE_PROPERTY("LogLevel", "s", property_get_log_level, 
> property_set_log_level, 0, 0),
>  SD_BUS_WRITABLE_PROPERTY("LogTarget", "s", property_get_log_target, 
> property_set_log_target, 0, 0),
>  SD_BUS_PROPERTY("NNames", "u", property_get_n_names, 0, 0),
> -SD_BUS_PROPERTY("NFailedUnits", "u", property_get_n_failed_units, 0, 
> 0),
> +SD_BUS_PROPERTY("NFailedUnits", "u", property_get_n_failed_units, 0, 
> SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
>  SD_BUS_PROPERTY("NJobs", "u", property_get_n_jobs, 0, 0),
>  SD_BUS_PROPERTY("NInstalledJobs", "u", bus_property_get_unsigned, 
> offsetof(Manager, n_installed_jobs), 0),
>  SD_BUS_PROPERTY("NFailedJobs", "u", bus_property_get_unsigned, 
> offsetof(Manager, n_failed_jobs), 0),
> @@ -2102,5 +2102,23 @@ void bus_manager_send_reloading(Manager *m, bool 
> active) {
>  r = bus_foreach_bus(m, NULL, send_reloading, INT_TO_PTR(active));
>  if (r < 0)
>  log_debug_errno(r, "Failed to send reloading signal: %m");
> +}
> +
> +static int send_changed_signal(sd_bus *bus, void *userdata) {
> +assert(bus);
> +
> +return sd_bus_emit_properties_changed_strv(bus,
> +   
> "/org/freedesktop/systemd1",
> +   
> "org.freedesktop.systemd1.Manager",
> +   NULL);
> +}
>
> +void bus_manager_send_change_signal(Manager *m) {
> +int r;
> +
> +assert(m);
> +
> +r = bus_foreach_bus(m, NULL, send_changed_signal, NULL);
> +if (r < 0)
> +log_debug_errno(r, "Failed to send manager change signal: 
> %m");
>  }
> diff --git a/src/core/dbus-manager.h b/src/core/dbus-manager.h
> index e1903fa..3f7cfef 100644
> --- a/src/core/dbus-manager.h
> +++ b/src/core/dbus-manager.h
> @@ -28,3 +28,4 @@ extern const sd_bus_vtable bus_manager_vtable[];
>
>  void bus_manager_send_finished(Manager *m, usec_t firmware_usec, usec_t 
> loader_usec, usec_t kernel_usec, usec_t initrd_usec, usec_t userspace_usec, 
> usec_t total_usec);
>  void bus_manager_send_reloading(Manager *m, bool active);
> +void bus_manager_send_change_signal(Manager *m);
> diff --git a/src/core/manager.c b/src/core/manager.c
> index 4775219..0e9e154 100644
> --- a/src/core/manager.c
> +++ b/src/core/manager.c
> @@ -3061,6 +3061,23 @@ const char *manager_get_runtime_prefix(Manager *m) {
> getenv("XDG_RUNTIME_DIR");
>  }
>
> +void manager_update_failed_units(Manager *m, Unit *u, bool failed) {
> +unsigned size;
> +
> +assert(m);
> +assert(u->manager == m);
> +
> +size = set_size(m->failed_units);
> +
> +if (failed)
> +set_put(m->failed_units, u);
> +else
> +set_remove(m->failed_units, u);
> +
> +if (set_size(m->failed_units) != size)
> +bus_manager_send_change_signal(m);
> +}
> +
>  ManagerState manager_state(Manager *m) {
>  Unit *u;
>
> diff --git a/src/core/manager.h b/src/core/manager.h
> index d3971f1..418b752 100644
> --- a/src/core/manager.h
> +++ b/src/core/manager.h
> @@ -367,5 +367,7 @@ const char *manager_get_runtime_prefix(Manager *m);
>
>  ManagerState manager_state(Manager *m);
>
> +void manager_update_failed_units(Manager *m, Unit *u, bool failed);
> +
>  const char *manager_state_to_string(ManagerState m) _const_;
>  ManagerState manager_state_from_string(const char *s) _pure_;
> diff --git a/src/core/unit.c b/src/core/unit.c
> index ee8e607..ec45ec9 100644
> --- a/src/core/unit.c
> +++ b/src/core/unit.c
> @@ -522,7 +522,7 @@ void unit_free(Unit *u) {
>  free(u->cgroup_path);
>  }
>
> -set_remove(u->manager->failed_units, u);
> +manager_update_failed_units(u->manager, u, false);
>  set_remove(u->manager->startup_units, u);
>
>  free(u->description);
> @@ -1801,10 +1801,7 @@ void unit_notify(Unit *u, UnitActiveState os, 
> UnitActiveState ns, bool reload_su
>  }
>
>  

Re: [systemd-devel] requiring all template instances in a service

[Andrei Borzenkov]

В Wed, 25 Feb 2015 18:42:47 -0500
Benjamin Rose  пишет:

> Hello all,
> 
> I hope this is the right place for this inquiry. I was noticing 
> extremely slow reboot times on three of my hosts running 
> corosync/pacemaker for shared storage. I enabled the systemd debug logs, 
> and found that pacemaker was attempting to communicate with it's peers 
> to notify of the shutdown, and failed to do so as networking was not 
> functioning. This was odd because networking was fine during normal 
> operation and the distribution's unit file has the proper "Requires" for 
> networking. Eventually it hit the distro "TimeoutStopSec=30m" and forced 
> the reboot, hence the slow reboot times.
> 
> In the debug logs, I found that it was all because I am using teamd 
> (partially related - through ifcfg files using network.service), and 
> teamd was being killed long before pacemaker got the chance to send its 
> closing messages. So, I fixed the problem in my implementation with this 
> little bit:
> 
> [root@myhost ~]# cat 
> /etc/systemd/system/pacemaker.service.d/require_teamd.conf
> [Unit]
> After=teamd@team_pub.service
> After=teamd@team_priv.service
> Requires=teamd@team_pub.service
> Requires=teamd@team_priv.service
> 
> But, soon I will be changing a lot about my networking. I'll be using 
> puppet to deploy a few more teams and bridges on this host. So, my 
> question comes down to - is there a way to accomplish something like this:
> 
> Requires=teamd@*.service
> After=teamd@*.service
> 
> to include all running instances? I know this makes no sense in an 
> xinetd-type situation on bootup, when instances will be created 
> on-demand, but it does make perfect sense on a shutdown or reboot to 
> want to wait for all instances of a certain type to complete their work 
> before proceeding.
> 

Services that implement networking are expected to order itself before
network.target on startup and hence after network.target on shutdown,
so that it should be sufficient to just have

After=network.target

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

[systemd-devel] Plans to fix or provide alternative for lz4?

[Laszlo Papp]

Hi,

it seems that the lz4 headers are broken when getting coredumps
generated. They cannot even be extracted by the lz4 tool itself, let
alone using them via the coredump controller util.

My system, which is Archlinux, is using lz4 127 and systemd 219.

My current workaround was to disable compression altogether for
coredumps in the corresponding config file, but it is suboptimal,
especially on embedded systems.

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

Re: [systemd-devel] Plans to fix or provide alternative for lz4?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 26, 2015 at 04:41:48AM +, Laszlo Papp wrote:
> Hi,
> 
> it seems that the lz4 headers are broken when getting coredumps
> generated. They cannot even be extracted by the lz4 tool itself, let
> alone using them via the coredump controller util.
> 
> My system, which is Archlinux, is using lz4 127 and systemd 219.
> 
> My current workaround was to disable compression altogether for
> coredumps in the corresponding config file, but it is suboptimal,
> especially on embedded systems.
The headers are different because when lz4 support was added, lz4 did
not provide a library to write the headers so I added custom headers.
You should be able to use coredumpctl to unpack the file.

"Proper" lz4 support has been written, but lz4 upstream has trouble
with keeping .so compatibility: 
https://code.google.com/p/lz4/issues/detail?id=147.
So the question is whether to replace lz4 with something more stable
or to ignore the issue and hope it doesn't happen again.

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