[systemd-devel] multipath breaks with recent udev/systemd

2014-12-15 Thread Hannes Reinecke
Hi all,

in commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
(udev: serialize/synchronize block device event handling with file
locks) udev started using flock() on the device node, supposedly to
synchronize with an ominous 'block event handling'.

The code looks like this:

  if (d) {
fd_lock = open(udev_device_get_devnode(d),
O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
if (fd_lock = 0  flock(fd_lock,
LOCK_SH|LOCK_NB)  0) {
 log_debug(Unable to flock(%s),
skipping event handling: %m, udev_device_get_devnode(d));
 err = -EWOULDBLOCK;
 goto skip;
   }
   }

However, multipath since several years is using a similar construct
to lock all devices belonging to a multipath device table before
creating a mulitpath dm-device:

vector_foreach_slot (mpp-pg, pgp, i) {
if (!pgp-paths)
continue;
vector_foreach_slot(pgp-paths, pp, j) {
if (lock  flock(pp-fd, LOCK_SH | LOCK_NB) 
errno == EWOULDBLOCK)
goto fail;
else if (!lock)
flock(pp-fd, LOCK_UN);
}
}

So during bootup it's anyone's guess who's first, multipath or udev.
And depending on the timing either multipath will fail to setup
the device-mapper device or udev will simply ignore the device.
Neither of those is a good, but the first is an absolute killer for
modern systems which _rely_ on udev to configure devices.

So how it this supposed to work?
Why does udev ignore the entire event if it can't get the lock?
Shouldn't it rather be retried?
What is the supposed recovery here?

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries  Storage
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] systemctl: fix argument handling when invoked as shutdown

2014-12-15 Thread Jan Synacek
---
 src/systemctl/systemctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 8400bc8..91e8f7c 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -6942,7 +6942,7 @@ static int shutdown_parse_argv(int argc, char *argv[]) {
 assert(argc = 0);
 assert(argv);
 
-while ((c = getopt_long(argc, argv, HPrhkt:afFc, options, NULL)) = 
0)
+while ((c = getopt_long(argc, argv, HPrhkKt:afFc, options, NULL)) = 
0)
 switch (c) {
 
 case ARG_HELP:
@@ -6983,6 +6983,8 @@ static int shutdown_parse_argv(int argc, char *argv[]) {
 
 case 't':
 case 'a':
+case 'f':
+case 'F':
 /* Compatibility nops */
 break;
 
-- 
2.2.0

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


[systemd-devel] [PATCH v2] Add FDB support

2014-12-15 Thread Alin Rauta
Hi,

Based on your feedback, I've created a new patch for adding the FDB support.
networkd takes ownership of the FDB table.

Configuration example:

 cat /etc/systemd/network/em1.network

[Match]
Name=em1

[Network]
DHCP=v4

[BridgeFDB]
MACAddress=04:44:12:34:56:70
VLAN=2

[BridgeFDB]
MACAddress=04:44:12:34:56:69
VLAN=3

Let me know what you think.

Thanks,
Alin

Alin Rauta (1):
  Add FDB support

 Makefile.am  |   1 +
 man/systemd.network.xml  |  22 ++
 src/libsystemd/sd-rtnl/rtnl-message.c|  56 -
 src/libsystemd/sd-rtnl/rtnl-types.c  |  15 +-
 src/network/networkd-fdb.c   | 357 +++
 src/network/networkd-link.c  |  25 +++
 src/network/networkd-network-gperf.gperf |   2 +
 src/network/networkd-network.c   |  13 +-
 src/network/networkd.h   |  30 +++
 src/systemd/sd-rtnl.h|   4 +
 10 files changed, 514 insertions(+), 11 deletions(-)
 create mode 100644 src/network/networkd-fdb.c

-- 
1.9.3

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


[systemd-devel] [PATCH v2] Add FDB support

2014-12-15 Thread Alin Rauta
Signed-off-by: Alin Rauta alin.ra...@intel.com
---
 Makefile.am  |   1 +
 man/systemd.network.xml  |  22 ++
 src/libsystemd/sd-rtnl/rtnl-message.c|  56 -
 src/libsystemd/sd-rtnl/rtnl-types.c  |  15 +-
 src/network/networkd-fdb.c   | 357 +++
 src/network/networkd-link.c  |  25 +++
 src/network/networkd-network-gperf.gperf |   2 +
 src/network/networkd-network.c   |  13 +-
 src/network/networkd.h   |  30 +++
 src/systemd/sd-rtnl.h|   4 +
 10 files changed, 514 insertions(+), 11 deletions(-)
 create mode 100644 src/network/networkd-fdb.c

diff --git a/Makefile.am b/Makefile.am
index 84b587d..226d298 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5271,6 +5271,7 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-address.c \
src/network/networkd-route.c \
src/network/networkd-manager.c \
+   src/network/networkd-fdb.c \
src/network/networkd-address-pool.c
 
 nodist_libsystemd_networkd_core_la_SOURCES = \
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 79c7a23..39bf385 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -549,6 +549,28 @@
 /refsect1
 
 refsect1
+title[BridgeFDB] Section Options/title
+paraThe literal[BridgeFDB]/literal section 
manages the forwarding database table of a port and accepts the following keys. 
Specify
+several literal[BridgeFDB]/literal sections to 
configure several static MAC table entries./para
+
+variablelist class='network-directives'
+varlistentry
+
termvarnameMACAddress=/varname/term
+listitem
+paraAs in the 
literal[Network]/literal section. This key is mandatory./para
+/listitem
+/varlistentry
+varlistentry
+termvarnameVLAN=/varname/term
+listitem
+paraThe VLAN for the new 
static MAC table entry.
+If omitted, no VLAN info is 
appended to the new static MAC table entry./para
+/listitem
+/varlistentry
+/variablelist
+/refsect1
+
+refsect1
 titleExample/title
 example
 title/etc/systemd/network/50-static.network/title
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 165e84d..9099440 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -220,6 +220,58 @@ int sd_rtnl_message_new_route(sd_rtnl *rtnl, 
sd_rtnl_message **ret,
 return 0;
 }
 
+int sd_rtnl_message_neigh_set_flags(sd_rtnl_message *m, uint8_t flags) {
+struct ndmsg *ndm;
+
+assert_return(m, -EINVAL);
+assert_return(m-hdr, -EINVAL);
+assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), -EINVAL);
+
+ndm = NLMSG_DATA(m-hdr);
+ndm-ndm_flags |= flags;
+
+return 0;
+}
+
+int sd_rtnl_message_neigh_set_state(sd_rtnl_message *m, uint16_t state) {
+struct ndmsg *ndm;
+
+assert_return(m, -EINVAL);
+assert_return(m-hdr, -EINVAL);
+assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), -EINVAL);
+
+ndm = NLMSG_DATA(m-hdr);
+ndm-ndm_state |= state;
+
+return 0;
+}
+
+int sd_rtnl_message_neigh_get_flags(sd_rtnl_message *m, uint8_t *flags) {
+struct ndmsg *ndm;
+
+assert_return(m, -EINVAL);
+assert_return(m-hdr, -EINVAL);
+assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), -EINVAL);
+
+ndm = NLMSG_DATA(m-hdr);
+*flags = ndm-ndm_flags;
+
+return 0;
+}
+
+int sd_rtnl_message_neigh_get_state(sd_rtnl_message *m, uint16_t *state) {
+struct ndmsg *ndm;
+
+assert_return(m, -EINVAL);
+assert_return(m-hdr, -EINVAL);
+assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), -EINVAL);
+
+ndm = NLMSG_DATA(m-hdr);
+*state = ndm-ndm_state;
+
+return 0;
+}
+
 int sd_rtnl_message_neigh_get_family(sd_rtnl_message *m, int *family) {
 struct ndmsg *ndm;
 
@@ -255,7 +307,9 @@ int sd_rtnl_message_new_neigh(sd_rtnl *rtnl, 
sd_rtnl_message **ret, uint16_t nlm
 int r;
 
 assert_return(rtnl_message_type_is_neigh(nlmsg_type), -EINVAL);
-assert_return(ndm_family == AF_INET || ndm_family == AF_INET6, 
-EINVAL);
+assert_return(ndm_family == 

[systemd-devel] [PATCH] hwdb: Logitech MX 518

2014-12-15 Thread harald
From: Harald Hoyer har...@redhat.com

---
 hwdb/70-mouse.hwdb | 4 
 1 file changed, 4 insertions(+)

diff --git a/hwdb/70-mouse.hwdb b/hwdb/70-mouse.hwdb
index 36778d5..06b5338 100644
--- a/hwdb/70-mouse.hwdb
+++ b/hwdb/70-mouse.hwdb
@@ -168,6 +168,10 @@ mouse:usb:v046dpc52b:name:Logitech Unifying Device. 
Wireless PID:4026:
 mouse:bluetooth:v046dpb00d:name:Ultrathin Touch Mouse:
  MOUSE_DPI=1000@1000
 
+# Logitech MX 518
+mouse:usb:v046dpc01e:name:Logitech USB-PS/2 Optical Mouse:
+ MOUSE_DPI=400@125 *800@125 1600@125
+
 ##
 # Microsoft
 ##
-- 
2.2.0

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


[systemd-devel] [PATCH] nss-myhostname: also recognize gateway.

2014-12-15 Thread harald
From: Harald Hoyer har...@redhat.com

gateway. skips adding the domain search path and saves some queries to
the nameserver.
---
 src/nss-myhostname/nss-myhostname.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/nss-myhostname/nss-myhostname.c 
b/src/nss-myhostname/nss-myhostname.c
index aa92cc9..2f76860 100644
--- a/src/nss-myhostname/nss-myhostname.c
+++ b/src/nss-myhostname/nss-myhostname.c
@@ -78,7 +78,7 @@ enum nss_status _nss_myhostname_gethostbyname4_r(
 canonical = localhost;
 local_address_ipv4 = htonl(INADDR_LOOPBACK);
 
-} else if (streq(name, gateway)) {
+} else if (streq(name, gateway) || streq(name, gateway.)) {
 
 n_addresses = local_gateways(NULL, 0, AF_UNSPEC, addresses);
 if (n_addresses = 0) {
@@ -348,7 +348,7 @@ enum nss_status _nss_myhostname_gethostbyname3_r(
 canonical = localhost;
 local_address_ipv4 = htonl(INADDR_LOOPBACK);
 
-} else if (streq(name, gateway)) {
+} else if (streq(name, gateway) || streq(name, gateway.)) {
 
 n_addresses = local_gateways(NULL, 0, af, addresses);
 if (n_addresses = 0) {
-- 
2.2.0

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


[systemd-devel] systemd boot issue

2014-12-15 Thread P J P
   Hello,

Please see:
  - http://fpaste.org/159783/
  - https://lists.fedoraproject.org/pipermail/devel/2014-September/202289.html

I first encountered this issue with a custom built kernel-3.16,
then in kernel-3.17 and now in 3.18 too. First issue here is that
kernel boot-up halts after saying

   ...
   Starting Switch root.
   [3.031675] systemd-journald[948]: Received SIGTERM from PID 1 (systemd).

And second, I've tried various systemd kernel parameters and to sift
through systemd/journalctl logs, but can't find anything pointing at a real
problem that halts the system. Others too have faced this issue before,

  - https://lists.fedoraproject.org/pipermail/devel/2014-September/202274.html

Does anyone here have a clue or suggestion?

Thank you.
---

Regards
   -P J P
http://feedmug.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] timedatectl regression in 218: crash with Etc/UTC

2014-12-15 Thread Martin Pitt
Hey Tom, all,

with systemd 218 our integration tests picked out a regression with
timedatectl: just calling it without any arguments crashes with

  *** Error in `./timedatectl': free(): invalid next size (fast): 0xf8cce8d8 ***

I only get this crash on i386 (32 bit), not x86_64. It also only
happens with /etc/timezone having Etc/UTC, other time zones like
Europe/Berlin work. Presumably because Etc/UTC does not have any DST
rules.

Back trace, with details from the interesting frame:

#0  0xf7fd9ca0 in __kernel_vsyscall ()
#1  0xf7e2b607 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xf7e2cd83 in __GI_abort () at abort.c:89
#3  0xf7e6a9e3 in __libc_message (do_abort=do_abort@entry=1, 
fmt=fmt@entry=0xf7f628fc *** Error in `%s': %s: 0x%s ***\n)
at ../sysdeps/posix/libc_fatal.c:175
#4  0xf7e70b0a in malloc_printerr (action=optimized out, str=0xf7f62a9c 
free(): invalid next size (fast), ptr=0x565b98d8)
at malloc.c:4996
#5  0xf7e71765 in _int_free (av=0xf7fa7420 main_arena, p=optimized out, 
have_lock=0) at malloc.c:3840
#6  0x5659b613 in freep (p=0xd6c8) at src/shared/util.h:659
#7  0x5659c185 in time_get_dst (date=1418644009, tzfile=0x5659e9ee 
/etc/localtime, switch_cur=0xd81c, zone_cur=0xd810, 
dst_cur=0xd809, switch_next=0xd824, delta_next=0xd820, 
zone_next=0xd814, dst_next=0xd80a)
at src/shared/time-dst.c:104
at src/shared/time-dst.c:104
type_idxs = 0x565b98d8 
num_types = 1
types = 0x565b98d8
zone_names = 0x565b98e0 UTC
st = {st_dev = 40, __pad1 = 348, __st_ino = 351284, st_mode = 33188, 
st_nlink = 1, st_uid = 0, st_gid = 0, st_rdev = 0, 
  __pad2 = 4, st_size = 118, st_blksize = 4096, st_blocks = 8, st_atim 
= {tv_sec = 1418641254, tv_nsec = 924653672}, 
  st_mtim = {tv_sec = 1418641254, tv_nsec = 920653672}, st_ctim = 
{tv_sec = 1418641254, tv_nsec = 920653672}, 
  st_ino = 351284}
num_isstd = 1
num_isgmt = 1
tzhead = {tzh_magic = TZif, tzh_version = 2, tzh_reserved = '\000' 
repeats 14 times, 
  tzh_ttisgmtcnt = \000\000\000\001, tzh_ttisstdcnt = 
\000\000\000\001, tzh_leapcnt = \000\000\000, 
  tzh_timecnt = \000\000\000, tzh_typecnt = \000\000\000\001, 
tzh_charcnt = \000\000\000\004}
chars = 4
i = 1
total_size = 12
types_idx = 0
trans_width = 4
tzspec_len = 0
num_leaps = 0
lo = 4294956851
hi = 1
num_transitions = 0
transitions = 0x565b98d8
f = 0x565b9970
#8  0x5655965b in print_status_info (i=0xd924) at 
src/timedate/timedatectl.c:167
#9  0x56559ae9 in show_status (bus=0x565b8008, args=0xdaa8, n=0) at 
src/timedate/timedatectl.c:239
#10 0x5655aa8b in timedatectl_main (bus=0x565b8008, argc=1, argv=0xdaa4) at 
src/timedate/timedatectl.c:542
#11 0x5655aba7 in main (argc=1, argv=0xdaa4) at 
src/timedate/timedatectl.c:563

I bisected this to commit 681f9718c shared: time-dst - ensure nulstr is null
terminated, reverting it fixes the crash.

+zone_names[chars] = '\0';

At first sight this smells like writing one past the array boundary,
if chars is the length of a string.

Was there some actual visible bug before this?

Thanks!

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] systemd boot issue

2014-12-15 Thread Jóhann B. Guðmundsson


On 12/15/2014 11:45 AM, P J P wrote:

I first encountered this issue with a custom built kernel-3.16,
then in kernel-3.17 and now in 3.18


Do you encounter this with none custom built kernel in Fedora?

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


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread P J P
 On Monday, 15 December 2014 5:24 PM, Jóhann B. Guðmundsson  wrote:
 Do you encounter this with none custom built kernel in Fedora?

I don't use the Fedora kernel, so I haven't seen it there. But as said earlier,
Paul I guess encountered it with the Fedora kernel

   - https://lists.fedoraproject.org/pipermail/devel/2014-September/202274.html


---
Regards
   -P J P
http://feedmug.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] Re: timedatectl regression in 218: crash with Etc/UTC

2014-12-15 Thread Martin Pitt
Martin Pitt [2014-12-15 12:50 +0100]:
 #7  0x5659c185 in time_get_dst (date=1418644009, tzfile=0x5659e9ee 
 /etc/localtime, switch_cur=0xd81c, zone_cur=0xd810, 
 dst_cur=0xd809, switch_next=0xd824, delta_next=0xd820, 
 zone_next=0xd814, dst_next=0xd80a)
 at src/shared/time-dst.c:104
 at src/shared/time-dst.c:104
 type_idxs = 0x565b98d8 
 num_types = 1
 types = 0x565b98d8
 zone_names = 0x565b98e0 UTC
 st = {st_dev = 40, __pad1 = 348, __st_ino = 351284, st_mode = 33188, 
 st_nlink = 1, st_uid = 0, st_gid = 0, st_rdev = 0, 
   __pad2 = 4, st_size = 118, st_blksize = 4096, st_blocks = 8, 
 st_atim = {tv_sec = 1418641254, tv_nsec = 924653672}, 
   st_mtim = {tv_sec = 1418641254, tv_nsec = 920653672}, st_ctim = 
 {tv_sec = 1418641254, tv_nsec = 920653672}, 
   st_ino = 351284}
 num_isstd = 1
 num_isgmt = 1
 tzhead = {tzh_magic = TZif, tzh_version = 2, tzh_reserved = 
 '\000' repeats 14 times, 
   tzh_ttisgmtcnt = \000\000\000\001, tzh_ttisstdcnt = 
 \000\000\000\001, tzh_leapcnt = \000\000\000, 
   tzh_timecnt = \000\000\000, tzh_typecnt = \000\000\000\001, 
 tzh_charcnt = \000\000\000\004}
 chars = 4
 i = 1
 total_size = 12
 types_idx = 0
 trans_width = 4
 tzspec_len = 0
 num_leaps = 0
 lo = 4294956851
 hi = 1
 num_transitions = 0
 transitions = 0x565b98d8
 f = 0x565b9970

To clarify:

186 transitions = malloc0(total_size + tzspec_len);

transitions gets 12 bytes allocated (see above frame for values of
variables).

192types = (struct ttinfo *)((char *)transitions + types_idx);

As types_idx == 0, types == transitions, thus 12 bytes long.

193zone_names = (char *)types + num_types * sizeof(struct ttinfo);

num_types == 1, thus zone_names == types + 8, i. e. zone_names is 4
bytes. chars is 4 bytes, thus

247zone_names[chars] = '\0';

writes at zone_names[4] aka transitions[12] which is one byte past the
allocated buffer.

I think the most robust solution would be to just allocate an extra
byte so that we can always actually fit that null byte. Does that
sound ok?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From 597f3557b73ae0b4b449dc54b6b0e0a720864051 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Mon, 15 Dec 2014 13:06:48 +0100
Subject: [PATCH] shared: time-dst: Avoid buffer overflow

Commit 681f9718 introduced an additional null terminator for the zone names.
Increase the allocation of transitions to actually make room for this.
---
 src/shared/time-dst.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/shared/time-dst.c b/src/shared/time-dst.c
index 926d22b..1ce6f72 100644
--- a/src/shared/time-dst.c
+++ b/src/shared/time-dst.c
@@ -183,7 +183,8 @@ read_again:
 return -EINVAL;
 }
 
-transitions = malloc0(total_size + tzspec_len);
+/* leave space for additional zone_names zero terminator */
+transitions = malloc0(total_size + tzspec_len + 1);
 if (transitions == NULL)
 return -EINVAL;
 
-- 
2.1.3



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


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread Jóhann B. Guðmundsson


On 12/15/2014 12:02 PM, P J P wrote:

On Monday, 15 December 2014 5:24 PM, Jóhann B. Guðmundsson  wrote:
Do you encounter this with none custom built kernel in Fedora?

I don't use the Fedora kernel, so I haven't seen it there. But as said earlier,
Paul I guess encountered it with the Fedora kernel

- 
https://lists.fedoraproject.org/pipermail/devel/2014-September/202274.html



Start by Installing and trying the Fedora stock kernel to see if it 
happens there then report back here.


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


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread P J P
 On Monday, 15 December 2014 5:40 PM, Jóhann B. Guðmundsson wrote:
 Start by Installing and trying the Fedora stock kernel to see if it 
 happens there then report back here.


  It does not happen there. Though IMO that's irrelevant.

I left the VM with the custom 3.18.0 kernel in the stalled state since morning,

   - http://fpaste.org/159783/

and now after 6-7 hours suddenly I see the login prompt with kernel-3.18.0. I 
have hit 

   # shutdown -r now

and boot-up has stalled at the same spot again. Let's see...

---
Regards
   -P J P
http://feedmug.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] multipath breaks with recent udev/systemd

2014-12-15 Thread Alexander E. Patrakov

15.12.2014 14:31, Hannes Reinecke wrote:

Hi all,

in commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
(udev: serialize/synchronize block device event handling with file
locks) udev started using flock() on the device node, supposedly to
synchronize with an ominous 'block event handling'.


This is a duplicate of the issue that I have reported earlier:

https://www.redhat.com/archives/dm-devel/2014-October/msg00210.html

Therefore, I want to be CCed on replies.



The code looks like this:

   if (d) {
 fd_lock = open(udev_device_get_devnode(d),
O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
 if (fd_lock = 0  flock(fd_lock,
LOCK_SH|LOCK_NB)  0) {
  log_debug(Unable to flock(%s),
skipping event handling: %m, udev_device_get_devnode(d));
  err = -EWOULDBLOCK;
  goto skip;
}
}

However, multipath since several years is using a similar construct
to lock all devices belonging to a multipath device table before
creating a mulitpath dm-device:

vector_foreach_slot (mpp-pg, pgp, i) {
if (!pgp-paths)
continue;
vector_foreach_slot(pgp-paths, pp, j) {
if (lock  flock(pp-fd, LOCK_SH | LOCK_NB) 
errno == EWOULDBLOCK)
goto fail;
else if (!lock)
flock(pp-fd, LOCK_UN);
}
}

So during bootup it's anyone's guess who's first, multipath or udev.
And depending on the timing either multipath will fail to setup
the device-mapper device or udev will simply ignore the device.
Neither of those is a good, but the first is an absolute killer for
modern systems which _rely_ on udev to configure devices.

So how it this supposed to work?
Why does udev ignore the entire event if it can't get the lock?
Shouldn't it rather be retried?
What is the supposed recovery here?

Cheers,

Hannes




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


Re: [systemd-devel] [udev] Giving exclusive rights over a sound card to a user

2014-12-15 Thread David Herrmann
Hi

On Sat, Dec 13, 2014 at 5:34 PM, Léo Gillot-Lamure
leo.gil...@navaati.net wrote:
 Hi.

 I want to give ownership of a particular sound card to a specific user
 permanently, so that 1/ I have a guarantee that other users' sessions
 can not emit sound on this card and 2/ the sound playing on the
 specific users' session does not stop when Ctrl+Alt+Fx'ing to
 another session (due to Pulse releasing the card after noticing the
 ACL changed).

This is really not something we're going to support. You're free to
make your system run like this, but I don't think any upstream will
help you make it work. Anyway, see below..

 To this goal the straight approach was to write an udev rule stating :
 SUBSYSTEM==sound, ATTRS{idVendor}==08bb, ATTRS{idProduct}==2705, 
 OWNER=navaati
 But this was not enough, as the ACL rights were still dynamically
 granted to the user when it had a front session on the seat.

 I then found out that the combination of this rule in 70-uaccess.rules :
 SUBSYSTEM==sound, TAG+=uaccess
 and this rule in 73-seat-late.rules :
 TAG==uaccess, ENV{MAJOR}!=, RUN{builtin}+=uaccess
 provoked the device to be ACL-managed (with udev talking to logind and stuff).

 Thus I changed my udev rule to
 SUBSYSTEM==sound, ATTRS{idVendor}==08bb, ATTRS{idProduct}==2705, 
 OWNER=navaati, TAG:=
 (the doc says that the := operator forbid any subsequent overriding of
 the variable, and my rule file is ordered early starting with 01-) but
 my soundcard devices still have ACL.

 Now I don't know what else to do or what mechanism is actually setting
 these ACL...

I don't think := works for TAGS. Please try systemd-218 and use:

TAG-=uaccess

in a 99- rule.

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


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread Jóhann B. Guðmundsson


On 12/15/2014 12:32 PM, P J P wrote:

   It does not happen there. Though IMO that's irrelevant.


It's not irrelevant since you might not be compiling your kernel without 
required config options which either break dracut or systemd.


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


Re: [systemd-devel] [PATCH] hwdb: Logitech MX 518

2014-12-15 Thread David Herrmann
Hi

On Mon, Dec 15, 2014 at 11:26 AM,  har...@redhat.com wrote:
 From: Harald Hoyer har...@redhat.com

 ---
  hwdb/70-mouse.hwdb | 4 
  1 file changed, 4 insertions(+)

 diff --git a/hwdb/70-mouse.hwdb b/hwdb/70-mouse.hwdb
 index 36778d5..06b5338 100644
 --- a/hwdb/70-mouse.hwdb
 +++ b/hwdb/70-mouse.hwdb
 @@ -168,6 +168,10 @@ mouse:usb:v046dpc52b:name:Logitech Unifying Device. 
 Wireless PID:4026:
  mouse:bluetooth:v046dpb00d:name:Ultrathin Touch Mouse:
   MOUSE_DPI=1000@1000

 +# Logitech MX 518
 +mouse:usb:v046dpc01e:name:Logitech USB-PS/2 Optical Mouse:
 + MOUSE_DPI=400@125 *800@125 1600@125
 +

Reordered and pushed!

Thanks
David

  ##
  # Microsoft
  ##
 --
 2.2.0

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


Re: [systemd-devel] [PATCH] Re: timedatectl regression in 218: crash with Etc/UTC

2014-12-15 Thread David Herrmann
Hi

On Mon, Dec 15, 2014 at 1:08 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Martin Pitt [2014-12-15 12:50 +0100]:
 #7  0x5659c185 in time_get_dst (date=1418644009, tzfile=0x5659e9ee 
 /etc/localtime, switch_cur=0xd81c, zone_cur=0xd810,
 dst_cur=0xd809, switch_next=0xd824, delta_next=0xd820, 
 zone_next=0xd814, dst_next=0xd80a)
 at src/shared/time-dst.c:104
 at src/shared/time-dst.c:104
 type_idxs = 0x565b98d8 
 num_types = 1
 types = 0x565b98d8
 zone_names = 0x565b98e0 UTC
 st = {st_dev = 40, __pad1 = 348, __st_ino = 351284, st_mode = 33188, 
 st_nlink = 1, st_uid = 0, st_gid = 0, st_rdev = 0,
   __pad2 = 4, st_size = 118, st_blksize = 4096, st_blocks = 8, 
 st_atim = {tv_sec = 1418641254, tv_nsec = 924653672},
   st_mtim = {tv_sec = 1418641254, tv_nsec = 920653672}, st_ctim = 
 {tv_sec = 1418641254, tv_nsec = 920653672},
   st_ino = 351284}
 num_isstd = 1
 num_isgmt = 1
 tzhead = {tzh_magic = TZif, tzh_version = 2, tzh_reserved = 
 '\000' repeats 14 times,
   tzh_ttisgmtcnt = \000\000\000\001, tzh_ttisstdcnt = 
 \000\000\000\001, tzh_leapcnt = \000\000\000,
   tzh_timecnt = \000\000\000, tzh_typecnt = \000\000\000\001, 
 tzh_charcnt = \000\000\000\004}
 chars = 4
 i = 1
 total_size = 12
 types_idx = 0
 trans_width = 4
 tzspec_len = 0
 num_leaps = 0
 lo = 4294956851
 hi = 1
 num_transitions = 0
 transitions = 0x565b98d8
 f = 0x565b9970

 To clarify:

 186 transitions = malloc0(total_size + tzspec_len);

 transitions gets 12 bytes allocated (see above frame for values of
 variables).

 192types = (struct ttinfo *)((char *)transitions + types_idx);

 As types_idx == 0, types == transitions, thus 12 bytes long.

 193zone_names = (char *)types + num_types * sizeof(struct ttinfo);

 num_types == 1, thus zone_names == types + 8, i. e. zone_names is 4
 bytes. chars is 4 bytes, thus

 247zone_names[chars] = '\0';

 writes at zone_names[4] aka transitions[12] which is one byte past the
 allocated buffer.

 I think the most robust solution would be to just allocate an extra
 byte so that we can always actually fit that null byte. Does that
 sound ok?

Nice catch! Applied!

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


Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Lennart Poettering
On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 NetworkManager sets logind inhibitor lock to monitor for suspend
 events. So it implicitly requires logind to be present when NM
 starts.

Any idea what it needs the inhibitor for?

 logind is ordered after nss-user-lookup.target. If we have remote user
 database, it means that logind depends on network to be up and running.
 
 If network is provided by NetworkManager we have a loop.
 
 Due to the fact that NetworkManager service itself does not declare
 dependency on logind, it can be pretty hard to recognize.
 
 Any idea how it can be solved nicely? I can only think of delaying
 inhibitor logic in NM until logind is started. Not sure what side
 effects it may have.

Yeah, I figure if they want to be able to run in early parts of boot
they should watch logind's bus name and create their inhibitor only
after it appears.

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] systemd boot issue

2014-12-15 Thread P J P
 On Monday, 15 December 2014 6:43 PM, Jóhann B. Guðmundsson wrote:
 It's not irrelevant since you might not be compiling your kernel without 
 required config options which either break dracut or systemd.


  Is there a known list of these options that a user must enable?

---
Regards
   -P J P
http://feedmug.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread Jóhann B. Guðmundsson


On 12/15/2014 03:15 PM, P J P wrote:

On Monday, 15 December 2014 6:43 PM, Jóhann B. Guðmundsson wrote:
It's not irrelevant since you might not be compiling your kernel without
required config options which either break dracut or systemd.


   Is there a known list of these options that a user must enable?




See the Requirements section in the readme file [1]

1. https://github.com/systemd/systemd/blob/master/README
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] build-sys: remove commented-out m4 from user@.service

2014-12-15 Thread Lennart Poettering
On Sun, 14.12.14 19:12, Mantas Mikulėnas (graw...@gmail.com) wrote:

 Otherwise this actually remains in the generated unit in /usr/lib.
 
 If you want to keep it commented out, a m4-compatible way would be:
 
 m4_ifdef(`HAVE_SMACK',
 dnl Capabilities=cap_mac_admin=i
 dnl SecureBits=keep-caps
 )

This really was only a temporary commenting, since the bits broke the
user instance in containers. See

http://lists.freedesktop.org/archives/systemd-devel/2014-December/026188.html

We really should find a proper fix for this, instead of just removing
the code for it.

Lennart

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


Re: [systemd-devel] [systemd-commits] 2 commits - src/core src/journal-remote src/network

2014-12-15 Thread Lennart Poettering
On Sat, 13.12.14 08:32, Matthias Urlichs (matth...@urlichs.de) wrote:

 Hi,
 
 Zbigniew Jędrzejewski-Szmek:
   wrap a few *_FOREACH macros in curly braces
   
  cppcheck is full of errors anyway. I don't think we should make the code
  less pretty just to satisfy a checker, and a rarely used one.
  
 While you may be right about cppcheck, IMHO it's good style to wrap all
 multi-line subordinates in curlies on general principle.

For the sake of brevity our CODING_STYLE docs suggest to leave out
unnecessary curly braces. Single-line code blocks should not be
enclosed in them, this is not PHP after all...

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] [PATCH] build-sys: remove commented-out m4 from user@.service

2014-12-15 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Dec 15, 2014 at 04:36:51PM +0100, Lennart Poettering wrote:
 On Sun, 14.12.14 19:12, Mantas Mikulėnas (graw...@gmail.com) wrote:
 
  Otherwise this actually remains in the generated unit in /usr/lib.
  
  If you want to keep it commented out, a m4-compatible way would be:
  
  m4_ifdef(`HAVE_SMACK',
  dnl Capabilities=cap_mac_admin=i
  dnl SecureBits=keep-caps
  )
 
 This really was only a temporary commenting, since the bits broke the
 user instance in containers. See
 
 http://lists.freedesktop.org/archives/systemd-devel/2014-December/026188.html
 
 We really should find a proper fix for this, instead of just removing
 the code for it.
Sure, but pulling it out of git history is trivial in either case.
And you know what they say about the durability of temporary measures...
so I thought it is better to keep the files that the user sees clean.

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


Re: [systemd-devel] [systemd-commits] 2 commits - src/core src/journal-remote src/network

2014-12-15 Thread Mantas Mikulėnas
On Mon, Dec 15, 2014 at 5:40 PM, Lennart Poettering mzta...@0pointer.de
wrote:

 On Sat, 13.12.14 08:32, Matthias Urlichs (matth...@urlichs.de) wrote:

  Hi,
 
  Zbigniew Jędrzejewski-Szmek:
wrap a few *_FOREACH macros in curly braces
   
   cppcheck is full of errors anyway. I don't think we should make the
 code
   less pretty just to satisfy a checker, and a rarely used one.
  
  While you may be right about cppcheck, IMHO it's good style to wrap all
  multi-line subordinates in curlies on general principle.

 For the sake of brevity our CODING_STYLE docs suggest to leave out
 unnecessary curly braces. Single-line code blocks should not be
 enclosed in them, this is not PHP after all...


There's no difference between C and PHP in this case. Perhaps you meant
Perl or Go?

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


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread Lennart Poettering
On Mon, 15.12.14 11:45, P J P (p...@fedoraproject.org) wrote:

Hello,
 
 Please see:
   - http://fpaste.org/159783/
   - 
 https://lists.fedoraproject.org/pipermail/devel/2014-September/202289.html
 
 I first encountered this issue with a custom built kernel-3.16,
 then in kernel-3.17 and now in 3.18 too. First issue here is that
 kernel boot-up halts after saying
 
...
Starting Switch root.
[3.031675] systemd-journald[948]: Received SIGTERM from PID 1 
 (systemd).
 
 And second, I've tried various systemd kernel parameters and to sift
 through systemd/journalctl logs, but can't find anything pointing at a real
 problem that halts the system. Others too have faced this issue before,
 
   - 
 https://lists.fedoraproject.org/pipermail/devel/2014-September/202274.html
 
 Does anyone here have a clue or suggestion?

Can you boot with systemd.log_level=debug systemd.log_target=kmsg?
This should print all logs to the console.

Most likely there's some necessary kernel option not enabled in your
custom kernel. Check that you have enabled everything listed in README.

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] nspawn: fix invocation of the raw clone() system call on s390 and cris

2014-12-15 Thread Ken Werner
From: Ken Werner k...@linux.vnet.ibm.com

Since the order of the first and second arguments of the raw clone()
system call is reversed on s390 and cris it needs to be invoked differently.

Signed-off-by: Ken Werner k...@linux.vnet.ibm.com
---
 src/nspawn/nspawn.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 9ca53cd..9bfd7a5 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -3133,9 +3133,17 @@ int main(int argc, char *argv[]) {
 goto finish;
 }
 
+#if defined(__s390__) || defined(__CRIS)
+/* On s390 and cris the order of the first and second arguments
+ * of the raw clone() system call is reversed. */
+pid = syscall(__NR_clone, NULL, SIGCHLD|CLONE_NEWNS|
+  (arg_share_system ? 0 : 
CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
+  (arg_private_network ? CLONE_NEWNET 
: 0));
+#else
 pid = syscall(__NR_clone, SIGCHLD|CLONE_NEWNS|
   (arg_share_system ? 0 : 
CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
   (arg_private_network ? CLONE_NEWNET 
: 0), NULL);
+#endif
 if (pid  0) {
 if (errno == EINVAL)
 r = log_error_errno(errno, clone() failed, do 
you have namespace support enabled in your kernel? (You need UTS, IPC, PID and 
NET namespacing built in): %m);
-- 
1.7.1

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


[systemd-devel] systemd-nspawn doesn't work on s390

2014-12-15 Thread Ken Werner
From: Ken Werner k...@linux.vnet.ibm.com

Hi there,

It appears that systemd-nspawn doesn't work on s390 (and cris probably). The 
clone() fails because the signature of the raw system call is slightly 
different on these architectures. Since the order of the first and second 
arguments is reversed it gets invoked with a bogus value of the child_stack 
pointer. The following patch attempts to fix this. Any comments are appreciated.

Regards,
Ken

Ken Werner (1):
  nspawn: fix invocation of the raw clone() system call on s390 and
cris

 src/nspawn/nspawn.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

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


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread P J P
   Hi,

 On Monday, 15 December 2014 9:23 PM, Lennart Poettering wrote:
 Can you boot with systemd.log_level=debug systemd.log_target=kmsg?
 This should print all logs to the console.

  Yes done! - http://fpaste.org/159929/

 Most likely there's some necessary kernel option not enabled in your
 custom kernel. Check that you have enabled everything listed in README.

  Yes, all of those options are duly set, except 'CONFIG_SCHED_DEBUG';
And CONFIG_UEVENT_HELPER_PATH was set to /sbin/hotplug; Both seem fairly 
innocuous.

  - http://fpaste.org/159938/

Even after setting these two configuration options, system boot halts at the 
same spot as earlier. The fpaste link above is after setting above two 
configuration options.

---

Regards
   -P J P
http://feedmug.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] nspawn: fix invocation of the raw clone() system call on s390 and cris

2014-12-15 Thread Lennart Poettering
On Mon, 15.12.14 08:01, Ken Werner (k...@linux.vnet.ibm.com) wrote:

 From: Ken Werner k...@linux.vnet.ibm.com
 
 Since the order of the first and second arguments of the raw clone()
 system call is reversed on s390 and cris it needs to be invoked differently.
 
 Signed-off-by: Ken Werner k...@linux.vnet.ibm.com

Hmm, I'd prefer if we could move the definition of this syscall
wrapper into missing.h, and do the per-arch magic there, like we do
for all the other syscalls missing from glibc. Maybe call the function
raw_clone() there or so.

Alternatively we could move to the glibc-provided wrapper, but I think
it's nastier to use, since it requires a stack parameter to be
specified.

 @@ -3133,9 +3133,17 @@ int main(int argc, char *argv[]) {
  goto finish;
  }
  
 +#if defined(__s390__) || defined(__CRIS)
 +/* On s390 and cris the order of the first and second 
 arguments
 + * of the raw clone() system call is reversed. */
 +pid = syscall(__NR_clone, NULL, SIGCHLD|CLONE_NEWNS|
 +  (arg_share_system ? 0 : 
 CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
 +  (arg_private_network ? 
 CLONE_NEWNET : 0));
 +#else
  pid = syscall(__NR_clone, SIGCHLD|CLONE_NEWNS|
(arg_share_system ? 0 : 
 CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
(arg_private_network ? 
 CLONE_NEWNET : 0), NULL);
 +#endif
  if (pid  0) {
  if (errno == EINVAL)
  r = log_error_errno(errno, clone() failed, 
 do you have namespace support enabled in your kernel? (You need UTS, IPC, PID 
 and NET namespacing built in): %m);
 -- 
 1.7.1
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Dan Williams

On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
 On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
 
  NetworkManager sets logind inhibitor lock to monitor for suspend
  events. So it implicitly requires logind to be present when NM
  starts.

NM doesn't actually require that, it just wants to know about the
signals that logind sends and have a chance to respond to them.  If
logind isn't running, NM shouldn't really care.  But perhaps expectation
is not matching reality in the code.

 Any idea what it needs the inhibitor for?

To be aware of suspend/resume events of course.  NM may want to
disconnect the network cleanly before suspending, and on resume may need
to clean up network connections and restart certain operations.

  logind is ordered after nss-user-lookup.target. If we have remote
user
  database, it means that logind depends on network to be up and
running.
  
  If network is provided by NetworkManager we have a loop.
  
  Due to the fact that NetworkManager service itself does not declare
  dependency on logind, it can be pretty hard to recognize.
  
  Any idea how it can be solved nicely? I can only think of delaying
  inhibitor logic in NM until logind is started. Not sure what side
  effects it may have.
 
 Yeah, I figure if they want to be able to run in early parts of boot
 they should watch logind's bus name and create their inhibitor only
 after it appears.

Does logind get D-Bus autolaunched?  NM is just creating a bus proxy for
the logind DBus service, and then attempting to call a D-Bus method on
logind to take an inhibitor.  It doesn't actually care that much about
the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
prohibit logind from launching.

Perhaps NM is requesting logind to start through D-Bus autolaunch, but
since the network isn't up yet logind then fails itself?

Dan


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


Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Andrei Borzenkov
В Mon, 15 Dec 2014 11:34:17 -0600
Dan Williams d...@redhat.com пишет:

 
 On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
  On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
  
   NetworkManager sets logind inhibitor lock to monitor for suspend
   events. So it implicitly requires logind to be present when NM
   starts.
 
 NM doesn't actually require that, it just wants to know about the
 signals that logind sends and have a chance to respond to them.  If
 logind isn't running, NM shouldn't really care.  But perhaps expectation
 is not matching reality in the code.
 
  Any idea what it needs the inhibitor for?
 
 To be aware of suspend/resume events of course.  NM may want to
 disconnect the network cleanly before suspending, and on resume may need
 to clean up network connections and restart certain operations.
 
   logind is ordered after nss-user-lookup.target. If we have remote
 user
   database, it means that logind depends on network to be up and
 running.
   
   If network is provided by NetworkManager we have a loop.
   
   Due to the fact that NetworkManager service itself does not declare
   dependency on logind, it can be pretty hard to recognize.
   
   Any idea how it can be solved nicely? I can only think of delaying
   inhibitor logic in NM until logind is started. Not sure what side
   effects it may have.
  
  Yeah, I figure if they want to be able to run in early parts of boot
  they should watch logind's bus name and create their inhibitor only
  after it appears.
 
 Does logind get D-Bus autolaunched?

Yes.

NM is just creating a bus proxy for
 the logind DBus service, and then attempting to call a D-Bus method on
 logind to take an inhibitor.  It doesn't actually care that much about
 the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
 prohibit logind from launching.
 
 Perhaps NM is requesting logind to start through D-Bus autolaunch, but
 since the network isn't up yet logind then fails itself?
 

systemd tries to launch logind service which now waits for services it
is ordered After and eventually times out.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH v2] Add FDB support

2014-12-15 Thread Tom Gundersen
Hi Alin,

Thanks for the patch!

Overall it looks excellent, my only concern is with the clearing of
FDB entries. Is there any reason to treat this differently than how we
currently treat routes and addresses?

The current logic is that we don't support run-time reconfiguration
(we only apply our (static) config once when the interfaces appear,
and that's it). If there is some config there already we assume that
it is intentional and leave it alone (i.e., if someone else have set
addresses or routes we don't remove them, we just add new ones). In
the future we plan to get a dbus API where networkd can be
reconfigured at run-time (i.e., change which .network file is applied
to a link), and then it definitely would make sense to flush routes
and addresses when removing the .network from the link, but currently
we don't do that at all.

If people want to reconfigure stuff now, they can of course just
restart networkd, but then they should also manually flush the
settings from the kernel, and this (changing the config, restarting
the daemon and flushing) is more of a hack for testing than something
we support.

So the question I have is: can we treat FDB entries the same as routes
and addresses and simply leave them alone rather than flushing them,
and then only add the flushing logic once we start supporting
reconfiguration? If not, can you explain a bit more what the typical
usecase is where flushing is desirable?

As to the naming, I like the suggestion made above to call it VLANId
rather than VLAN.

Cheers,

Tom

On Mon, Dec 15, 2014 at 11:20 AM, Alin Rauta alin.ra...@intel.com wrote:
 Hi,

 Based on your feedback, I've created a new patch for adding the FDB support.
 networkd takes ownership of the FDB table.

 Configuration example:

 cat /etc/systemd/network/em1.network

 [Match]
 Name=em1

 [Network]
 DHCP=v4

 [BridgeFDB]
 MACAddress=04:44:12:34:56:70
 VLAN=2

 [BridgeFDB]
 MACAddress=04:44:12:34:56:69
 VLAN=3

 Let me know what you think.

 Thanks,
 Alin

 Alin Rauta (1):
   Add FDB support

  Makefile.am  |   1 +
  man/systemd.network.xml  |  22 ++
  src/libsystemd/sd-rtnl/rtnl-message.c|  56 -
  src/libsystemd/sd-rtnl/rtnl-types.c  |  15 +-
  src/network/networkd-fdb.c   | 357 
 +++
  src/network/networkd-link.c  |  25 +++
  src/network/networkd-network-gperf.gperf |   2 +
  src/network/networkd-network.c   |  13 +-
  src/network/networkd.h   |  30 +++
  src/systemd/sd-rtnl.h|   4 +
  10 files changed, 514 insertions(+), 11 deletions(-)
  create mode 100644 src/network/networkd-fdb.c

 --
 1.9.3

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


Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Dan Williams
On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
 В Mon, 15 Dec 2014 11:34:17 -0600
 Dan Williams d...@redhat.com пишет:
 
  
  On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
   On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
   
NetworkManager sets logind inhibitor lock to monitor for suspend
events. So it implicitly requires logind to be present when NM
starts.
  
  NM doesn't actually require that, it just wants to know about the
  signals that logind sends and have a chance to respond to them.  If
  logind isn't running, NM shouldn't really care.  But perhaps expectation
  is not matching reality in the code.
  
   Any idea what it needs the inhibitor for?
  
  To be aware of suspend/resume events of course.  NM may want to
  disconnect the network cleanly before suspending, and on resume may need
  to clean up network connections and restart certain operations.
  
logind is ordered after nss-user-lookup.target. If we have remote
  user
database, it means that logind depends on network to be up and
  running.

If network is provided by NetworkManager we have a loop.

Due to the fact that NetworkManager service itself does not declare
dependency on logind, it can be pretty hard to recognize.

Any idea how it can be solved nicely? I can only think of delaying
inhibitor logic in NM until logind is started. Not sure what side
effects it may have.
   
   Yeah, I figure if they want to be able to run in early parts of boot
   they should watch logind's bus name and create their inhibitor only
   after it appears.
  
  Does logind get D-Bus autolaunched?
 
 Yes.
 
 NM is just creating a bus proxy for
  the logind DBus service, and then attempting to call a D-Bus method on
  logind to take an inhibitor.  It doesn't actually care that much about
  the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
  prohibit logind from launching.
  
  Perhaps NM is requesting logind to start through D-Bus autolaunch, but
  since the network isn't up yet logind then fails itself?
  
 
 systemd tries to launch logind service which now waits for services it
 is ordered After and eventually times out.

NM patch filed for review by NM dev team:

https://bugzilla.gnome.org/show_bug.cgi?id=741572

Also, I don't think logind should fail if there is no network; no reason
for it to crash and burn just because everything isn't quite ready when
it starts.  I presume it's got capability to deal with sporadic network
outages, and that's not really different than waiting for networking to
show up soon after it starts.  But not my department...

Dan

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


[systemd-devel] pam_limits: Could not set limit for ...: Operation not permitted

2014-12-15 Thread Kai Krakow
Hello!

I'm seeing the following errors in systemd's journal:

Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): 
Could not set limit for 'memlock': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): 
Could not set limit for 'nice': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): 
Could not set limit for 'rtprio': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message() failed: 
Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning 
/usr/lib/systemd/systemd: Operation not permitted

Is it meaningless? Do I have to worry? Or which configuration do I miss?

-- 
Replies to list only preferred.

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


[systemd-devel] DefaultDependencies=false on scopes

2014-12-15 Thread Brandon Philips
Hello-

How is a user supposed to disable DefaultDependencies on a scope? From
the docs it seems like it should work:

Unless DefaultDependencies=false is used, scope units will implicitly
have dependencies of type Conflicts= and Before= on shutdown.target.

But, in practice:

systemd-run --scope --property=DefaultDependencies=false /usr/bin/sleep 5
Unknown assignment DefaultDependencies=false.
Failed to create message: Invalid argument

The root problem I am trying to fix is that it seems the docker daemon
uses DefaulDependencies for all of its scopes which means that the
containers get killed by systemd before the docker daemon is notified
to shutdown.

AFAICS, this would need to be added here:
http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd/sd-bus/bus-util.c#n1319

Thanks,

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


Re: [systemd-devel] systemd boot issue

2014-12-15 Thread P J P
   Hi,

 On Monday, 15 December 2014 10:54 PM, P J P wrote:
 and now after 6-7 hours suddenly I see the login prompt with kernel-3.18.0. I 
 have hit 
# shutdown -r now
and boot-up has stalled at the same spot again. Let's see...

  On a VM I had enabled 'CONFIG_LOCKUP_DETECTOR=y'  'CONFIG_DETECT_HUNG_TASK=y'
to detect hung tasks and to panic on hard or soft kernel lock-ups. After a 
while it did panic with a hung task trace.

   - http://fpaste.org/159929/
   - http://fpaste.org/159938/
 
 Even after setting these two configuration options, system boot halts at the 
 same spot as earlier. The fpaste link above is after setting above two 
 configuration options.


On another machine that I left over night, it says - Failed to load SELinux 
policy. Freezing.

===
...
Starting Switch Root...
[ 4.615752] systemd[1]: Switching root.
[ 4.632717] systemd-journald[126]: Received SIGTERM from PID 1 (systemd).
[ 5.296874] audit: type=1404 audit(1418662423.615:2): enforcing=1 
old_enforcing=0 auid=4294967295 ses=4294967295
[ 302.048179] kworker/dying (32) used greatest stack depth: 12976 bytes left
[13112.020686] systemd[1]: Failed to load SELinux policy. Freezing.
===


I've restarted it with - systemd.log_level=debug systemd.log_target=kmsg 
enforcing=0.

Is there a way to see what systemd(1) is doing after it says - Starting Switch 
Root... - ?
---
Regards
   -P J P
http://feedmug.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] fix compiler warning

2014-12-15 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Dec 16, 2014 at 08:48:34AM +0530, Susant Sahani wrote:
 src/shared/utf8.c:268:13: warning: unused variable 'd'
 [-Wunused-variable]
  int d;
Applied.

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


Re: [systemd-devel] [PATCH] systemctl: fix argument handling when invoked as shutdown

2014-12-15 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Dec 15, 2014 at 10:39:00AM +0100, Jan Synacek wrote:
 ---
  src/systemctl/systemctl.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
 index 8400bc8..91e8f7c 100644
 --- a/src/systemctl/systemctl.c
 +++ b/src/systemctl/systemctl.c
 @@ -6942,7 +6942,7 @@ static int shutdown_parse_argv(int argc, char *argv[]) {
  assert(argc = 0);
  assert(argv);
  
 -while ((c = getopt_long(argc, argv, HPrhkt:afFc, options, NULL)) 
 = 0)
 +while ((c = getopt_long(argc, argv, HPrhkKt:afFc, options, NULL)) 
 = 0)
  switch (c) {
  
  case ARG_HELP:
 @@ -6983,6 +6983,8 @@ static int shutdown_parse_argv(int argc, char *argv[]) {
  
  case 't':
  case 'a':
 +case 'f':
 +case 'F':
  /* Compatibility nops */

Applied.

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


Re: [systemd-devel] [PATCH] nss-myhostname: also recognize gateway.

2014-12-15 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Dec 15, 2014 at 11:34:24AM +0100, har...@redhat.com wrote:
 From: Harald Hoyer har...@redhat.com
 
 gateway. skips adding the domain search path and saves some queries to
 the nameserver.
Pushed it... Works nicely and seems useful.

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


Re: [systemd-devel] Using `systemctl edit` on invalid unit names

2014-12-15 Thread Zbigniew Jędrzejewski-Szmek
On Sun, Dec 14, 2014 at 04:21:32PM +0300, Ivan Shapovalov wrote:
 On Saturday 13 December 2014 at 15:34:01, Ronny Chevalier wrote:  
  2014-12-13 11:33 GMT+01:00 Ivan Shapovalov intelfx...@gmail.com:
   Hello all,
  
  Hi,
  
  
   it seems that the newly added `systemctl edit` command requires its 
   arguments
   to be valid unit names.
  
   This causes `edit` operation to fail in apparently valid use-cases like
  
   systemctl edit getty@.service
  
  This is fixed in git now, thanks!
  
   or
   systemctl edit autovt@tty1.service
  
   In second case, the error message is especially cryptic:
   autovt@tty1.service ignored: not found.
  
  It worked before and it still works for me.
 
 Do you have getty@tty1.service explicity enabled? I do have.
 
   Actually I understand what it does mean: systemctl asks the manager to 
   show
   unit's FragmentPath - the manager tries to load the unit - loading 
   fails with
   File exists because getty@tty1.service is already instantiated.
  
  I don't see why it should fail for this reason ?
  
  
   (BTW, it's a separate question: is this failure valid or is it a bug?)
  
  
  systemctl edit getty@.service, should have worked before so yes this was a 
  bug.
 
 Now both `edit getty@` and `edit getty@tty1` work, but I'd expect the latter
 to honor the template parameter; i. e. create a drop-in for 
 getty@tty1.service...
 Is this possible?
I made various unifications to the code to make it more maintainable. This
case should be fixed too. Please test it... it's easy to miss the corner cases.

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


Re: [systemd-devel] [PATCH v3] systemctl: add edit verb

2014-12-15 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Oct 21, 2014 at 10:55:46PM +0200, Ronny Chevalier wrote:
   +if (arg_transport != BUS_TRANSPORT_LOCAL) {
   +log_error(Cannot remotely edit units);
   +return -EINVAL;
   +}
   +
   +if (arg_runtime) {
   +log_error(Cannot edit runtime units);
   +return -EINVAL;
   +}
  
   Hmm, why not support this? And imply --runtime or so?
 
  You are right, I forgot to ask a question about this one, sorry.
 
  If there is a unit in /etc/systemd/system/ and someone wants to edit
  this unit temporarily it will run systemctl --runtime myunit. The
  problem is the unit will be copied in the /run/ directory but this
  directory do not have precedence over /etc/systemd/, so when this unit
  will be restarted, it won't take into account the one in /run/, right?
  (My understanding of this come from src/shared/path-lookup.c)
 
  Indeed. We should probably print an error in this case and refuse
  operation. However we should support adding a --runtime .d/ snippet if
  a unit file is in /etc, because that will actually work fine.
 I think you meant /usr/.

No, actually /etc was meant, iiuc. I updated the code to check 
for overriding snippets, so e.g. 
/run/systemd/system/getty@tty1.service.d/override.conf is
allowed in /etc/systemd/sytem/getty@tty1.service exists, but not
if /etc/systemd/sytem/getty@tty1.service.d/override.conf does.

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


Re: [systemd-devel] Fedora 21: Cannot scan to EPSON WF-2540

2014-12-15 Thread poma

Unlike the case with a network capable scanner i.e. the scanner connected 
directly to the network,
these are the settings for sharing across a network scanner connected to a 
computer via USB.


As root, on *server*:

1. Create 'saned' user  group

# getent group saned /dev/null 21 || groupadd -r saned 21
# getent passwd saned /dev/null 21 || useradd -r -l -g saned -d /dev/null -s 
/sbin/nologin -c SANE network daemon saned /dev/null 21

~~

2. Create template unit configuration service file

/etc/systemd/system/saned@.service 
[Unit]
Description=SANE network daemon
Requires=saned.socket

[Service]
ExecStart=/usr/sbin/saned
User=saned
Group=saned
StandardInput=socket
Environment=SANE_CONFIG_DIR=/etc/sane.d
# Debug:
#Environment=SANE_DEBUG_DLL=128 SANE_DEBUG_NET=128

[Install]
Also=saned.socket



3. Create unit configuration socket file

/etc/systemd/system/saned.socket 
[Unit]
Description=saned incoming socket

[Socket]
ListenStream=6566
Accept=yes
MaxConnections=1

[Install]
WantedBy=sockets.target



4. Create udev rule file

/etc/udev/rules.d/70-saned.rules 
ACTION==add, ENV{libsane_matched}==yes, GROUP=saned, MODE=0660

~~

5. Apply udev rule

# udevadm trigger --action=add

~~~

6. Add clinet name, client IP address, or IP subnet
   to saned configuration file, within 'Access list' section.
   In this example clinet IP address is used

/etc/sane.d/saned.conf
192.168.1.2

~

7. Firewall - open SANE control port 6566/tcp


\\//
 \\  //
  \\//
  //\\
 //  \\
//\\


As root, on *client*:

1. Add server name or server IP address to net backend configuration file,
   within 'saned hosts' section.
   In this example server IP address is used

/etc/sane.d/net.conf
192.168.1.1

~~~

2. Fire up your favorite frontend,
   xsane, scanimage, simple-scan, skanlite, ...



Tested and works.

poma


Ref.
saned systemd support
https://bugzilla.redhat.com/show_bug.cgi?id=1091566

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


Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread David Herrmann
Hi

On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams d...@redhat.com wrote:
 On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
 systemd tries to launch logind service which now waits for services it
 is ordered After and eventually times out.

 NM patch filed for review by NM dev team:

 https://bugzilla.gnome.org/show_bug.cgi?id=741572

Thanks a lot!

 Also, I don't think logind should fail if there is no network; no reason
 for it to crash and burn just because everything isn't quite ready when
 it starts.  I presume it's got capability to deal with sporadic network
 outages, and that's not really different than waiting for networking to
 show up soon after it starts.  But not my department...

When a user loggs in, we resolve the name to UID. As the initial
logind binary was only used for login management, it was reasonable to
avoid starting up before the nss-user-lookup is initialized. Now that
systemd-logind provides other independent APIs, it might be ok to drop
that requirement again.
If the nss user lookup is not ready at the time someone logs in, we
will print a warning and skip tracking that session. Sounds fine to
me, but Lennart might have more comments.

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