Re: [systemd-devel] Cleaning up transient scopes
On Thu, Mar 5, 2015 at 12:00 AM, Lennart Poettering wrote: > On Wed, 04.03.15 18:51, Alexander Larsson (al...@redhat.com) wrote: > >> If i run a transient scope on the user systemd instance like: >> >> $ systemd-run --user --scope true >> >> Then the scope seems to live past the end of the process. Is there any >> way to make it automatically go away with the last process in the >> cgroup? > > Well, yes, the idea is that that just works. However, this is kinda > broken if the systemd instance managing your scope is not PID 1, as we > don't get SIGCHLD then. It has been broken for PID 1 too for some time, https://bugs.freedesktop.org/show_bug.cgi?id=86520 Umut > > Do you create any subcgroups? presumably not? > > Normally it should just work then, but I must admit that --user scopes > got much less testing that system scopes... > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > 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
[systemd-devel] [PATCH] networkd vxlan: Add support for enabling UDP checksums
Add UdpCheckSum option to enable transmitting UDP checksums when doing
VXLAN/IPv4. Add Udp6ZeroChecksumRx, and Udp6ZeroChecksumTx
options to enable sending zero checksums and receiving zero
checksums in VXLAN/IPv6
---
man/systemd.netdev.xml | 24 +++-
src/libsystemd/sd-rtnl/rtnl-types.c | 3 +++
src/network/networkd-netdev-gperf.gperf | 3 +++
src/network/networkd-netdev-vxlan.c | 27 +++
src/network/networkd-netdev-vxlan.h | 3 +++
5 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index e278aa1..9304ce2 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -391,7 +391,29 @@
A boolean. When true
route short circuit is turned on.
-
+
+
UdpCheckSum=
+
+ A boolean. When true
transmitting UDP checksums when doing
+ VXLAN/IPv4 is turned on. The default
value is false.
+
+
+
+
Udp6ZeroCheckSumTx=
+
+ A boolean. When true sending
zero checksums in VXLAN/IPv6 is turned on.
+ The default value is false.
+
+
+
+
Udp6ZeroCheckSumRx=
+
+A boolean. When true receiving zero
checksums in VXLAN/IPv6 is turned on.
+The default value is false./
+
+
+
+
[Tunnel] Section Options
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
index d4abe4c..95924cd 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -89,6 +89,9 @@ static const NLType
rtnl_link_info_data_vxlan_types[IFLA_VXLAN_MAX+1] = {
[IFLA_VXLAN_RSC] = { .type = NLA_U8 },
[IFLA_VXLAN_L2MISS] = { .type = NLA_U8 },
[IFLA_VXLAN_L3MISS] = { .type = NLA_U8 },
+[IFLA_VXLAN_UDP_CSUM] = { .type = NLA_U8 },
+[IFLA_VXLAN_UDP_ZERO_CSUM6_TX] = { .type = NLA_U8 },
+[IFLA_VXLAN_UDP_ZERO_CSUM6_RX] = { .type = NLA_U8 },
};
static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
diff --git a/src/network/networkd-netdev-gperf.gperf
b/src/network/networkd-netdev-gperf.gperf
index 963c47c..7a9fbf8 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -47,6 +47,9 @@ VXLAN.ARPProxy, config_parse_bool,
0,
VXLAN.L2MissNotification, config_parse_bool, 0,
offsetof(VxLan, l2miss)
VXLAN.L3MissNotification, config_parse_bool, 0,
offsetof(VxLan, l3miss)
VXLAN.RouteShortCircuit, config_parse_bool, 0,
offsetof(VxLan, route_short_circuit)
+VXLAN.UdpCheckSum,config_parse_bool, 0,
offsetof(VxLan, udpcsum)
+VXLAN.Udp6ZeroCheckSumRx, config_parse_bool, 0,
offsetof(VxLan, udp6zerocsumrx)
+VXLAN.Udp6ZeroCheckSumTx, config_parse_bool, 0,
offsetof(VxLan, udp6zerocsumtx)
VXLAN.FDBAgeingSec, config_parse_sec, 0,
offsetof(VxLan, fdb_ageing)
Tun.OneQueue, config_parse_bool, 0,
offsetof(TunTap, one_queue)
Tun.MultiQueue, config_parse_bool, 0,
offsetof(TunTap, multi_queue)
diff --git a/src/network/networkd-netdev-vxlan.c
b/src/network/networkd-netdev-vxlan.c
index d5128cb..d9b13e3 100644
--- a/src/network/networkd-netdev-vxlan.c
+++ b/src/network/networkd-netdev-vxlan.c
@@ -135,6 +135,30 @@ static int netdev_vxlan_fill_message_create(NetDev
*netdev, Link *link, sd_rtnl_
}
}
+r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_CSUM, v->udpcsum);
+if (r < 0) {
+log_netdev_error(netdev,
+ "Could not append IFLA_VXLAN_UDP_CSUM
attribute: %s",
+ strerror(-r));
+return r;
+}
+
+
Re: [systemd-devel] Cleaning up transient scopes
On tor, 2015-03-05 at 00:00 +0100, Lennart Poettering wrote: > On Wed, 04.03.15 18:51, Alexander Larsson (al...@redhat.com) wrote: > > > If i run a transient scope on the user systemd instance like: > > > > $ systemd-run --user --scope true > > > > Then the scope seems to live past the end of the process. Is there any > > way to make it automatically go away with the last process in the > > cgroup? > > Well, yes, the idea is that that just works. However, this is kinda > broken if the systemd instance managing your scope is not PID 1, as we > don't get SIGCHLD then. > > Do you create any subcgroups? presumably not? > > Normally it should just work then, but I must admit that --user scopes > got much less testing that system scopes... Oh, i'm not doing anything special at all: $ systemd-run --user --scope sleep 10 & [1] 10613 $ Running as unit run-10613.scope. systemd-ctl status --user run-10613.scope ● run-10613.scope - /usr/bin/sleep 10 Loaded: loaded (/run/user/1000/systemd/user/run-10613.scope; static) Drop-In: /run/user/1000/systemd/user/run-10613.scope.d └─50-Description.conf Active: active (running) since tor 2015-03-05 10:06:24 CET; 8s ago CGroup: /user.slice/user-1000.slice/user@1000.service/run-10613.scope └─10613 /usr/bin/sleep 10 mar 05 10:06:24 localhost.localdomain systemd[1405]: Starting /usr/bin/sleep 10. mar 05 10:06:24 localhost.localdomain systemd[1405]: Started /usr/bin/sleep 10. $ sleep 10 [1]+ Donesystemd-run --user --scope sleep 10 $ systemctl status --user run-10613.scope ● run-10613.scope - /usr/bin/sleep 10 Loaded: loaded (/run/user/1000/systemd/user/run-10613.scope; static) Drop-In: /run/user/1000/systemd/user/run-10613.scope.d └─50-Description.conf Active: active (running) since tor 2015-03-05 10:06:24 CET; 25s ago mar 05 10:06:24 localhost.localdomain systemd[1405]: Starting /usr/bin/sleep 10. mar 05 10:06:24 localhost.localdomain systemd[1405]: Started /usr/bin/sleep 10. See, even when the sleep command died the scope still exists, and is even ACTIVE. Also, while we're on the topic of scopes. Is there any way to hang some random metadata off a unit during creation, that can be read back? For xdg-app I'd like to put information like the app id, the exact version, the security level, etc into the scope. Then anyone talking to the app could go: getpeercred => cgroup => scope => unfakable (by the app) data about the application. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an uncontrollable coffee-fuelled filmmaker for the 21st century. She's an enchanted tomboy doctor with a song in her heart and a spring in her step. They fight crime! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Regression in 219: tmpfiles.d order not respected any more
Hey Zbigniew, hey all, our autopkgtests found a regression in 219; unfortunately only yesterday when we flipped our cloud images to systemd by default, before that the bug was hidden. As per tmpfiles.d(5), the first match should win if there are several tmpfiles.d lines for the same directory. Our rsyslog package ships a /usr/lib/tmpfiles.d/00rsyslog.conf which sets /var/log to 0775, so that it can write into it as the "syslog" system user. But now the permissions of /var/log are 0755 as /usr/lib/tmpfiles.d/var.conf overwrites it. This can be reproduced with | $ cat ~/test.conf | d /var/log 0775 root syslog - | d /var/log 0755 - - - | | $ sudo SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --create ~/test.conf | [/home/martin/test.conf:2] Duplicate line for path "/var/log", ignoring. | Running create action for entry d /var/log | Found existing directory "/var/log". | chmod "/var/log" to mode 775 | /var/log created successfully. | Running remove action for entry d /var/log | Running create action for entry d /var/log | Found existing directory "/var/log". | chmod "/var/log" to mode 755 | /var/log created successfully. | Running remove action for entry d /var/log (this command works well right out of the built tree, which is what I used for git bisect run) In 218 this still worked fine, but git bisect shows that http://cgit.freedesktop.org/systemd/systemd/commit/?id=3f93da987961 introduced this regression: i. e. even though it still warns about the duplicate line for /var/log/, the second line is now being processed anyway. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] use dolt.m4 to speedup compilation
From: Harald Hoyer
The speedup is significant
Original libtool
$ ccache -C && make clean && time make -j4
[…]
real6m4.104s
user13m49.234s
sys7m37.864s
Original libtool + dolt
$ ccache -C && make clean && time make -j4
[…]
real2m24.869s
user7m30.198s
sys1m17.813s
---
configure.ac | 1 +
m4/dolt.m4 | 178 +++
2 files changed, 179 insertions(+)
create mode 100644 m4/dolt.m4
diff --git a/configure.ac b/configure.ac
index 14518bc..bc75c31 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,6 +40,7 @@ AC_CANONICAL_HOST
AC_DEFINE_UNQUOTED([CANONICAL_HOST], "$host", [Canonical host string.])
LT_PREREQ(2.2)
LT_INIT([disable-static])
+DOLT
AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static is not
supported by systemd])])
AS_IF([test "x$enable_largefile" = "xno"], [AC_MSG_ERROR([--disable-largefile
is not supported by systemd])])
diff --git a/m4/dolt.m4 b/m4/dolt.m4
new file mode 100644
index 000..af76e9d
--- /dev/null
+++ b/m4/dolt.m4
@@ -0,0 +1,178 @@
+dnl dolt, a replacement for libtool
+dnl Copyright © 2007-2010 Josh Triplett
+dnl Copying and distribution of this file, with or without modification,
+dnl are permitted in any medium without royalty provided the copyright
+dnl notice and this notice are preserved.
+dnl
+dnl To use dolt, invoke the DOLT macro immediately after the libtool macros.
+dnl Optionally, copy this file into acinclude.m4, to avoid the need to have it
+dnl installed when running autoconf on your project.
+
+AC_DEFUN([DOLT], [
+AC_REQUIRE([AC_CANONICAL_HOST])
+# dolt, a replacement for libtool
+# Josh Triplett
+AC_PATH_PROG(DOLT_BASH, bash)
+AC_MSG_CHECKING([if dolt supports this host])
+dolt_supported=yes
+if test x$DOLT_BASH = x; then
+dolt_supported=no
+fi
+if test x$GCC != xyes; then
+dolt_supported=no
+fi
+case $host in
+*-*-linux* \
+|amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*)
+pic_options='-fPIC'
+;;
+i?86-apple-darwin*)
+pic_options='-fno-common'
+;;
+*)
+dolt_supported=no
+;;
+esac
+if test x$dolt_supported = xno ; then
+AC_MSG_RESULT([no, falling back to libtool])
+LTCOMPILE='$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=compile $(COMPILE)'
+LTCXXCOMPILE='$(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=compile $(CXXCOMPILE)'
+else
+AC_MSG_RESULT([yes, replacing libtool])
+
+dnl Start writing out doltcompile.
+cat <<__DOLTCOMPILE__EOF__ >doltcompile
+#!$DOLT_BASH
+__DOLTCOMPILE__EOF__
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+args=("$[]@")
+for ((arg=0; arg<${#args@<:@@@:>@}; arg++)) ; do
+if test x"${args@<:@$arg@:>@}" = x-o ; then
+objarg=$((arg+1))
+break
+fi
+done
+if test x$objarg = x ; then
+echo 'Error: no -o on compiler command line' 1>&2
+exit 1
+fi
+lo="${args@<:@$objarg@:>@}"
+obj="${lo%.lo}"
+if test x"$lo" = x"$obj" ; then
+echo "Error: libtool object file name \"$lo\" does not end in .lo" 1>&2
+exit 1
+fi
+objbase="${obj##*/}"
+__DOLTCOMPILE__EOF__
+
+dnl Write out shared compilation code.
+if test x$enable_shared = xyes; then
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+libobjdir="${obj%$objbase}.libs"
+if test ! -d "$libobjdir" ; then
+mkdir_out="$(mkdir "$libobjdir" 2>&1)"
+mkdir_ret=$?
+if test "$mkdir_ret" -ne 0 && test ! -d "$libobjdir" ; then
+ echo "$mkdir_out" 1>&2
+exit $mkdir_ret
+fi
+fi
+pic_object="$libobjdir/$objbase.o"
+args@<:@$objarg@:>@="$pic_object"
+__DOLTCOMPILE__EOF__
+cat <<__DOLTCOMPILE__EOF__ >>doltcompile
+"\${args@<:@@@:>@}" $pic_options -DPIC || exit \$?
+__DOLTCOMPILE__EOF__
+fi
+
+dnl Write out static compilation code.
+dnl Avoid duplicate compiler output if also building shared objects.
+if test x$enable_static = xyes; then
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+non_pic_object="$obj.o"
+args@<:@$objarg@:>@="$non_pic_object"
+__DOLTCOMPILE__EOF__
+if test x$enable_shared = xyes; then
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+"${args@<:@@@:>@}" >/dev/null 2>&1 || exit $?
+__DOLTCOMPILE__EOF__
+else
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+"${args@<:@@@:>@}" || exit $?
+__DOLTCOMPILE__EOF__
+fi
+fi
+
+dnl Write out the code to write the .lo file.
+dnl The second line of the .lo file must match "^# Generated by .*libtool"
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+{
+echo "# $lo - a libtool object file"
+echo "# Generated by doltcompile, not libtool"
+__DOLTCOMPILE__EOF__
+
+if test x$enable_shared = xyes; then
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+echo "pic_object='.libs/${objbase}.o'"
+__DOLTCOMPILE__EOF__
+else
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+echo pic_object=none
+__DOLTCOMPILE__EOF__
+fi
+
+if test x$enable_static = xyes; then
+cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
+echo "non_pic_object
Re: [systemd-devel] [PATCH] core/socket: Add REMOTE_IP environment variable for Accept=true
On Thu, 05.03.15 01:27, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> >
> >
> >
> > diff --git a/src/core/service.c b/src/core/service.c
> > index a89ff3f..0942072 100644
> > --- a/src/core/service.c
> > +++ b/src/core/service.c
> > @@ -1119,6 +1119,30 @@ static int service_spawn(
> > goto fail;
> > }
> >
> > +if (s->accept_socket.unit) {
> > +union sockaddr_union pn;
> > +socklen_t pnlen = sizeof(pn);
> > +_cleanup_free_ char *remote_addr = NULL;
> > +
> > +r = getpeername(s->socket_fd, &pn.sa, &pnlen);
> This happens before the fork, right? You cannot call a blocking function
> like this in PID 1. This could be called either asynchronously, or
> after the fork, in the child thread. The latter seems easier.
getpeername() just gets the peer sockaddr, it's not slow. It should be
OK to invoke it, and we actually do already, to generate instantiated
service names.
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] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)
On 9 December 2014 at 17:28, Lennart Poettering wrote: > On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: > >> Hi. >> >> Currently notify socket is unavailable in chrooted services (again) >> unless you bind mount it there. Is there perhaps another, less >> cumbersome way? >> >> So far notify socket was: >> 1. abstract socket >> >>commit 8c47c7325fa1ab72febf807f8831ff24c75fbf45 >>notify: add minimal readiness/status protocol for spawned daemons >> >> 2. file-system socket >> >>commit 91b22f21f3824c1766d34f622c5bbb70cbe881a8 >>core: move abstract namespace sockets to /dev/.run >> >>Now that we have /dev/.run there's no need to use abstract >>namespace sockets. So, let's move things to /dev/.run, to make >>things more easily discoverable and improve compat with chroot() >>and fs namespacing. >> >> 3. abstract socket again >> >>commit 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da >>manager: turn notify socket into abstract namespace socket again >> >>sd_notify() should work for daemons that chroot() as part of their >>initilization, hence it's a good idea to use an abstract namespace >>socket which is not affected by chroot. >> >> 4. file-system socket again >> >>commit 7181dbdb2e3112858d62bdaea4f0ad2ed685ccba >>core: move notify sockets to /run and $XDG_RUNTIME_DIR >> >>A service with PrivateNetwork= cannot access abstract namespace >>sockets of the host anymore, hence let's better not use abstract >>namespace sockets for this, since we want to make sure that >>PrivateNetwork= is useful and doesn't break sd_notify(). >> >> >> So... would it be acceptable to have two notify sockets, one abstract >> and one normal, the latter only set for services with PrivateNetwork >> or - better maybe - explicitly selectable? Any other ideas? > > Hmm, but what would you do for a service that has both PrivateNetwork > and chroot enabled? > > I am all open for shifting things around again, but I inda would > prefer a solution that works universally in the end... > > Ideas? > > I figure we could open a new mount namespace and mount the file system > socket into the chroot, but not sure I like the idea... I don't know what is the best solution but using a socket file seems better than using an abstract unix socket: processes in a systemd-nspawn container could discover the notify socket of the host in /proc/net/unix (if it does not use a new network namespace) and send garbage file descriptors with SCM_RIGHTS from the container to the host. Systemd on the host does the right thing: it closes the fds when the datagram was not sent by a managed unit. Does manager_get_unit_by_pid() matches the exact cgroup path only or does it also matches a prefix path? I wonder about nspawn containers started by a service unit on the host. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/socket: Add REMOTE_IP environment variable for Accept=true
On Wed, 04.03.15 15:18, Shawn Landden (sh...@churchofgit.com) wrote: Can't this just use getpeername_pretty()? 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] networkd vxlan: Add support for enabling UDP checksums
On Thu, 05.03.15 14:05, Susant Sahani (sus...@redhat.com) wrote: > Add UdpCheckSum option to enable transmitting UDP checksums when doing > VXLAN/IPv4. Add Udp6ZeroChecksumRx, and Udp6ZeroChecksumTx > options to enable sending zero checksums and receiving zero > checksums in VXLAN/IPv6 I think useing the capitalization "UDPCheckSum=" instead of "UdpCheckSum=" would be more in line with how we capitalize this otherwise. (Also, indentation problems in the man page...) 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] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
On Wed, 04.03.15 16:27, Michael Biebl (mbi...@gmail.com) wrote: > 2015-03-04 15:41 GMT+01:00 Lennart Poettering : > > Well, just removing the symlink is kinda pointless. It might still be pulled > > in by anything else that implicitly depepends on /tmp. > > What unit is supposed to pull in tmp.mount explicitly? If a generic > unit did that, this sounds like a bug. It is pulled in implicitly. In many cases dependencies are automatically generated by systemd. For example: you have a mount unit for /tmp/foo and one for /tmp. The former is enabled, the latter is not. Simply because tmp-foo.mount is below tmp.mount this will pull in the latter too and you ened up with both enabled. Similar automatic deps are generated in a variety of cases, for example if you have an AF_UNIX socket, or a pipe socket listening inside of /tmp, you pull in tmp.mount via it. Also, anything that has PrivateTmp= set will pull in tmp.mount, since it implicitly refers to /tmp and /var/tmp. And so on, and so on. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
On Thu, 05.03.15 08:36, Didier Roche (didro...@ubuntu.com) wrote: > Le 04/03/2015 16:27, Michael Biebl a écrit : > >2015-03-04 15:41 GMT+01:00 Lennart Poettering : > >>Well, just removing the symlink is kinda pointless. It might still be pulled > >>in by anything else that implicitly depepends on /tmp. > >What unit is supposed to pull in tmp.mount explicitly? If a generic > >unit did that, this sounds like a bug. > > > > > It seems to be systemd-timesyncd.service. I still don't have an answer why > it's sometimes activated in my kvm env (and rightly, with condition > virtualized failing) and most of the time none. I'll try to spend some time > on that before the end of week. systemd-timesyncd.service has PrivateTmp= set, which will cause it to be pulled in. 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-networkd 219 chokes on can device
I have an Atom NM10-based industrial PC with three e1000e devices and a
PEAK can device (PCI ID 001c:0008). After updating from 216 to 219,
systemd-networkd is unable to get my e1000e-devices up and running. I
don't have any configuration for can0 within /etc/systemd/network.
It hit me that I didn't provide a full debug-loglevel debug with
everything custom disabled. So I created a bugreport at
https://bugs.freedesktop.org/show_bug.cgi?id=89442. Please do tell if
there's anything else I should provide.
--- a/src/network/networkd-manager.c2015-02-11 17:30:31.800897770
+0100
+++ b/src/network/networkd-manager.c2015-03-04 15:06:42.091892185
+0100
@@ -322,6 +322,10 @@
switch (type) {
case RTM_NEWLINK:
+
+if (strcmp("can0", name) == 0)
+return 0;
+
if (!link) {
/* link is new, so add it */
r = link_add(m, message, &link);
@@ -347,6 +351,9 @@
break;
case RTM_DELLINK:
+
+if (strcmp("can0", name) == 0)
+return 0;
link_drop(link);
netdev_drop(netdev);
Any tips for what I'm missing here to create a workaround making
systemd-networkd not consider can0 as a network device would also be
appreciated :)
- Mads
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] how to nest slices under system.slice
Hi, How do I add a slice that is inside the system.slice? Following slice gets nested to -.slice where I want to nest it inside system.slice (just like instantaneous service slices). hello.slice [Unit] Description=hello slice I tried following which produced the correct output with "systemctl show -p Slice hello.slice" but the slice was still in the top level hierarchy. [Unit] Description=hello slice [Slice] Slice=system.slice # ls -al /sys/fs/cgroup/systemd/ drwxr-xr-x4 root root 0 Mar 14 05:35 hello.slice drwxr-xr-x 89 root root 0 Mar 14 05:35 system.slice ... ... -rw-r--r--1 root root 0 Mar 14 05:47 tasks -rw-r--r--1 root root 0 Mar 14 05:35 release_agent Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd 219 chokes on can device
I have an Atom NM10-based industrial PC with three e1000e devices and
a PEAK can device (PCI ID 001c:0008). After updating from 216 to 219,
systemd-networkd is unable to get my e1000e-devices up and running. I
don't have any configuration for can0 within /etc/systemd/network.
It hit me that I didn't provide a full debug-loglevel debug with
everything custom disabled. So I created a bugreport at
https://bugs.freedesktop.org/show_bug.cgi?id=89442. Please do tell if
there's anything else I should provide.
--- a/src/network/networkd-manager.c 2015-02-11 17:30:31.800897770
+0100 +++ b/src/network/networkd-manager.c 2015-03-04
15:06:42.091892185 +0100 @@ -322,6 +322,10 @@ switch (type) { case
RTM_NEWLINK: + + if (strcmp("can0", name) == 0) + return 0; + if
(!link) { /* link is new, so add it */ r = link_add(m, message,
&link); @@ -347,6 +351,9 @@ break; case RTM_DELLINK: + + if
(strcmp("can0", name) == 0) + return 0; link_drop(link);
netdev_drop(netdev);
Any tips for what I'm missing here to create a workaround making
systemd-networkd not consider can0 as a network device would also be
appreciated :)
- Mads
I now see that the error with eth0 and eth1 not coming up is due to
missing IPv6 support in my kernel, not due to the existence of a CAN
device. So I changed the wording of the bug report to be a request for
adding CANbus support to systemd-networkd.
Sorry for the noise.
- Mads
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
On Thu, Mar 05, 2015 at 11:58:30AM +0100, har...@redhat.com wrote:
> Original libtool
> $ ccache -C && make clean && time make -j4
> […]
> real6m4.104s
> user13m49.234s
> sys7m37.864s
>
> Original libtool + dolt
> $ ccache -C && make clean && time make -j4
> […]
> real2m24.869s
> user7m30.198s
> sys1m17.813s
Nice speedup. I'd say just push it, if problems crop up we'll deal with them.
Zbyszek
> ---
> configure.ac | 1 +
> m4/dolt.m4 | 178
> +++
> 2 files changed, 179 insertions(+)
> create mode 100644 m4/dolt.m4
>
> diff --git a/configure.ac b/configure.ac
> index 14518bc..bc75c31 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -40,6 +40,7 @@ AC_CANONICAL_HOST
> AC_DEFINE_UNQUOTED([CANONICAL_HOST], "$host", [Canonical host string.])
> LT_PREREQ(2.2)
> LT_INIT([disable-static])
> +DOLT
>
> AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static is
> not supported by systemd])])
> AS_IF([test "x$enable_largefile" = "xno"],
> [AC_MSG_ERROR([--disable-largefile is not supported by systemd])])
> diff --git a/m4/dolt.m4 b/m4/dolt.m4
> new file mode 100644
> index 000..af76e9d
> --- /dev/null
> +++ b/m4/dolt.m4
> @@ -0,0 +1,178 @@
> +dnl dolt, a replacement for libtool
> +dnl Copyright © 2007-2010 Josh Triplett
> +dnl Copying and distribution of this file, with or without modification,
> +dnl are permitted in any medium without royalty provided the copyright
> +dnl notice and this notice are preserved.
> +dnl
> +dnl To use dolt, invoke the DOLT macro immediately after the libtool macros.
> +dnl Optionally, copy this file into acinclude.m4, to avoid the need to have
> it
> +dnl installed when running autoconf on your project.
> +
> +AC_DEFUN([DOLT], [
> +AC_REQUIRE([AC_CANONICAL_HOST])
> +# dolt, a replacement for libtool
> +# Josh Triplett
> +AC_PATH_PROG(DOLT_BASH, bash)
> +AC_MSG_CHECKING([if dolt supports this host])
> +dolt_supported=yes
> +if test x$DOLT_BASH = x; then
> +dolt_supported=no
> +fi
> +if test x$GCC != xyes; then
> +dolt_supported=no
> +fi
> +case $host in
> +*-*-linux* \
> +|amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*)
> +pic_options='-fPIC'
> +;;
> +i?86-apple-darwin*)
> +pic_options='-fno-common'
> +;;
> +*)
> +dolt_supported=no
> +;;
> +esac
> +if test x$dolt_supported = xno ; then
> +AC_MSG_RESULT([no, falling back to libtool])
> +LTCOMPILE='$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
> --mode=compile $(COMPILE)'
> +LTCXXCOMPILE='$(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
> --mode=compile $(CXXCOMPILE)'
> +else
> +AC_MSG_RESULT([yes, replacing libtool])
> +
> +dnl Start writing out doltcompile.
> +cat <<__DOLTCOMPILE__EOF__ >doltcompile
> +#!$DOLT_BASH
> +__DOLTCOMPILE__EOF__
> +cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> +args=("$[]@")
> +for ((arg=0; arg<${#args@<:@@@:>@}; arg++)) ; do
> +if test x"${args@<:@$arg@:>@}" = x-o ; then
> +objarg=$((arg+1))
> +break
> +fi
> +done
> +if test x$objarg = x ; then
> +echo 'Error: no -o on compiler command line' 1>&2
> +exit 1
> +fi
> +lo="${args@<:@$objarg@:>@}"
> +obj="${lo%.lo}"
> +if test x"$lo" = x"$obj" ; then
> +echo "Error: libtool object file name \"$lo\" does not end in .lo" 1>&2
> +exit 1
> +fi
> +objbase="${obj##*/}"
> +__DOLTCOMPILE__EOF__
> +
> +dnl Write out shared compilation code.
> +if test x$enable_shared = xyes; then
> +cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> +libobjdir="${obj%$objbase}.libs"
> +if test ! -d "$libobjdir" ; then
> +mkdir_out="$(mkdir "$libobjdir" 2>&1)"
> +mkdir_ret=$?
> +if test "$mkdir_ret" -ne 0 && test ! -d "$libobjdir" ; then
> + echo "$mkdir_out" 1>&2
> +exit $mkdir_ret
> +fi
> +fi
> +pic_object="$libobjdir/$objbase.o"
> +args@<:@$objarg@:>@="$pic_object"
> +__DOLTCOMPILE__EOF__
> +cat <<__DOLTCOMPILE__EOF__ >>doltcompile
> +"\${args@<:@@@:>@}" $pic_options -DPIC || exit \$?
> +__DOLTCOMPILE__EOF__
> +fi
> +
> +dnl Write out static compilation code.
> +dnl Avoid duplicate compiler output if also building shared objects.
> +if test x$enable_static = xyes; then
> +cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> +non_pic_object="$obj.o"
> +args@<:@$objarg@:>@="$non_pic_object"
> +__DOLTCOMPILE__EOF__
> +if test x$enable_shared = xyes; then
> +cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> +"${args@<:@@@:>@}" >/dev/null 2>&1 || exit $?
> +__DOLTCOMPILE__EOF__
> +else
> +cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> +"${args@<:@@@:>@}" || exit $?
> +__DOLTCOMPILE__EOF__
> +fi
> +fi
> +
> +dnl Write out the code to write the .lo file.
> +dnl The second line of the .lo file must match "^# Generated by .*libtool"
> +cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> +{
> +echo "# $lo - a libtool object file"
> +echo "# Generated by doltcompile, not libtoo
[systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
Hi, I spent some time last night trying to track down the issue preventing fedup from fedora 21 to 22: https://bugzilla.redhat.org/show_bug.cgi?id=1185604 I'm pretty sure I've tracked it down to when switch-root is called and systemd-219 gets executed being passed the serialised state of systemd-216 in the process. Unfortunately when this occurs the whole system is brought to a halt making further debugging tricky. Any ideas on how I might reproduce on a reduced an BBS simplified testcase for the behaviour involved? There is strace of pid1 from just before the switch-root to the crash along with coredumps that have been generated on the bug. These tests were carried out with enforcing=0 at the kernel command line so I'm reasonably confident the bug is not SELinux related. Cheers, James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: Fix handling of duplicate lines [was: Regression in 219: tmpfiles.d order not respected any more]
Hey Zbigniew, all,
Martin Pitt [2015-03-05 10:20 +0100]:
> As per tmpfiles.d(5), the first match should win if there are several
> tmpfiles.d lines for the same directory. Our rsyslog package ships a
> /usr/lib/tmpfiles.d/00rsyslog.conf which sets /var/log to 0775, so
> that it can write into it as the "syslog" system user. But now the
> permissions of /var/log are 0755 as /usr/lib/tmpfiles.d/var.conf
> overwrites it.
The attached patch helps and generally seems to behave fine. But I'd
really like Zbigniew to review/ack this, I'm not entirely sure whether
aborting on the first match is actually correct, or whether we need to
look at the other items in the array still for some reason.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From bae7be365da60db7086a93e7a9cbce7aa2cd0c07 Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Thu, 5 Mar 2015 14:58:56 +0100
Subject: [PATCH] tmpfiles: Fix handling of duplicate lines
Commit 3f93da987 accidentally dropped the "return 0" after detection of a
duplicate line. Put it back, to get back the documented and intended "first
match wins" behaviour.
https://launchpad.net/bugs/1428540
---
src/tmpfiles/tmpfiles.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 917bb3c..652fe5f 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1746,9 +1746,11 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) {
unsigned n;
for (n = 0; n < existing->count; n++) {
-if (!item_compatible(existing->items + n, &i))
+if (!item_compatible(existing->items + n, &i)) {
log_warning("[%s:%u] Duplicate line for path \"%s\", ignoring.",
fname, line, i.path);
+return 0;
+}
}
} else {
existing = new0(ItemArray, 1);
--
2.1.4
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-networkd and bonding config
On Thu, Mar 5, 2015 at 5:27 AM, Mikhail Morfikov wrote: >> The logic here is that when we create a new bond we will create it >> with these settings, but we will not change the settings of a >> preexisting bond, as that may have been created by somebody else we >> don't know about so we figure better leave it alone. >> >> The confusing part here is that the kernel will create bond0 with >> default settings, and we will then not touch that. Ideally there would >> be a kernel config switch to make it not create default devices like >> that, but for the moment I think the best solution is to simply call >> your bond something else. So if you put bond1 everywhere instead >> things should JustWork(TM). > > I performed some tests, and I was able to run my system without bond > interfaces. So I think there's nothing that could trigger creation of > these kind of interfaces. The next thing I did was to create a .netdev > file that set bond0 interface (+ the rest of config files), and > here's the log: > > # journalctl -b | grep -i bond > Mar 05 05:04:12 morfikownia kernel: bonding: Ethernet Channel Bonding Driver: > v3.7.1 (April 27, 2011) > Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0 : netdev > ready > Mar 05 05:04:12 morfikownia kernel: IPv6: ADDRCONF(NETDEV_UP): bond0: link is > not ready > Mar 05 05:04:12 morfikownia kernel: bonding: bond0: Enslaving wlan0 as an > active interface with an up link > Mar 05 05:04:12 morfikownia kernel: IPv6: ADDRCONF(NETDEV_CHANGE): bond0: > link becomes ready > Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0 : bond0 >: could not bring up interface: Invalid argument > Mar 05 05:04:12 morfikownia kernel: bonding: bond0: Enslaving eth1 as an > active interface with an up link > Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0 : gained > carrier > Mar 05 05:04:19 morfikownia systemd-networkd[862]: bond0 : DHCPv4 > address 192.168.1.113/24 via 192.168.1.1 > Mar 05 05:04:19 morfikownia systemd-networkd[862]: bond0 : link > configured > > As you can see, there's nothing before it, so I don't understand why the > bond0 interface has some problems. Anyway, I changed the files and set > bond1 instead of bond0, and here's the log: > > root:~# journalctl -b | grep -i bond > Mar 05 05:09:18 morfikownia kernel: bonding: Ethernet Channel Bonding Driver: > v3.7.1 (April 27, 2011) > Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting MII monitoring > interval to 1000 > Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting up delay to 5000 > Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting down delay to 5000 > Mar 05 05:09:18 morfikownia systemd-networkd[945]: bond1 : netdev > ready > Mar 05 05:09:19 morfikownia kernel: bonding: bond1: Enslaving wlan0 as an > active interface with a down link > Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : gained > carrier > Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : bond1 >: could not bring up interface: Invalid argument > Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : lost > carrier > Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : DHCPv4 > connection considered system critical, ignoring request to reconfigure it. > Mar 05 05:09:19 morfikownia kernel: bonding: bond1: Enslaving eth1 as an > active interface with a down link > Mar 05 05:09:20 morfikownia kernel: bonding: bond1: link status up for > interface wlan0, enabling it in 0 ms > Mar 05 05:09:20 morfikownia kernel: bonding: bond1: link status definitely up > for interface wlan0, 0 Mbps full duplex > Mar 05 05:09:20 morfikownia kernel: bonding: bond1: first active interface up! > Mar 05 05:09:20 morfikownia systemd-networkd[945]: bond1 : gained > carrier > Mar 05 05:09:22 morfikownia systemd-networkd[945]: bond1 : DHCPv4 > address 192.168.1.150/24 via 192.168.1.1 > Mar 05 05:09:22 morfikownia systemd-networkd[945]: bond1 : link > configured > > It's a little bit longer, and as you can see there's just bond1 info > and nothing concerning bond0. Also the MAC address changed in this > point -- it looks like the bond0 interface caused that problem. > > I thougt that the only one interface was created, but there were > two of them. > > The bond0 interface looks like this: > > root:~# cat /proc/net//bonding/bond0 > Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) > > Bonding Mode: load balancing (round-robin) > MII Status: down > MII Polling Interval (ms): 0 > Up Delay (ms): 0 > Down Delay (ms): 0 > > and the other one: > > root:~# cat /proc/net//bonding/bond1 > Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) > > Bonding Mode: load balancing (round-robin) > MII Status: up > MII Polling Interval (ms): 1000 > Up Delay (ms): 5000 > Down Delay (ms): 5000 > > Slave Interface: wlan0 > MII Status: up > Speed: Unknown > Dupl
Re: [systemd-devel] [PATCH] tmpfiles: Fix handling of duplicate lines [was: Regression in 219: tmpfiles.d order not respected any more]
On Thu, Mar 05, 2015 at 03:06:05PM +0100, Martin Pitt wrote: > Hey Zbigniew, all, > > Martin Pitt [2015-03-05 10:20 +0100]: > > As per tmpfiles.d(5), the first match should win if there are several > > tmpfiles.d lines for the same directory. Our rsyslog package ships a > > /usr/lib/tmpfiles.d/00rsyslog.conf which sets /var/log to 0775, so > > that it can write into it as the "syslog" system user. But now the > > permissions of /var/log are 0755 as /usr/lib/tmpfiles.d/var.conf > > overwrites it. > > The attached patch helps and generally seems to behave fine. But I'd > really like Zbigniew to review/ack this, I'm not entirely sure whether > aborting on the first match is actually correct, or whether we need to > look at the other items in the array still for some reason. Looks good, please push! Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!
Hello developers, I have a Problem whit Jessie, systemd (maybe?) and my OpenVPN. I am looking for help at the Debian Forum first, but i get no Answers :( (0) Maybe only developers can help by this issue? I use following packages: network-manager | 0.9.10.0-6 network-manager debug | 0.9.10.0-6 network-manager-openvpn | 0.9.10.0-1 network-manager-openvpn-gnome | 0.9.10.0-1 #I start Networkconnections at NM-Manager (Jessie / Cinnamon) Mar 5 14:55:31 desktop dbus[521]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' #I select my *.conf file, i get from my VPN-Provider (it's works on Wheezy!) Mar 5 14:55:31 desktop systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument Mar 5 14:55:31 desktop dbus[521]: [system] Successfully activated service 'org.freedesktop.hostname1' #NM-Manager (Window) crashes. My LAN was still allive (whitout VPN) Mar 5 14:55:45 desktop kernel: [ 1140.258095] nm-connection-e[2123]: segfault at 1326510 ip 01326510 sp 7fff11ebda18 error 15 Hint: (I am) the default User is *NOT* a Meber of the (new) Group "systemd-network" USERNAME@desktop:~$ groups USERNAME USERNAME : USERNAME cdrom floppy audio dip video plugdev netdev lpadmin scanner bluetooth wireshark Thanks in Advanced Michael (German Lang. Help Sream on Debian Forum) (0) http://debianforum.de/forum/viewtopic.php?f=30&t=153853&hilit=openvpn 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] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!
On Thu, Mar 5, 2015 at 3:46 PM, system_error wrote: > Hello developers, > > I have a Problem whit Jessie, systemd (maybe?) and my OpenVPN. I am > looking for help at the Debian Forum first, but i get no Answers :( (0) > > Maybe only developers can help by this issue? > > I use following packages: > > network-manager | 0.9.10.0-6 > network-manager debug | 0.9.10.0-6 > network-manager-openvpn | 0.9.10.0-1 > network-manager-openvpn-gnome | 0.9.10.0-1 > > #I start Networkconnections at NM-Manager (Jessie / Cinnamon) > > Mar 5 14:55:31 desktop dbus[521]: [system] Activating via systemd: > service name='org.freedesktop.hostname1' > unit='dbus-org.freedesktop.hostname1.service' > > #I select my *.conf file, i get from my VPN-Provider (it's works on Wheezy!) > > Mar 5 14:55:31 desktop systemd[1]: Failed to reset devices.list on > /system.slice: Invalid argument > Mar 5 14:55:31 desktop dbus[521]: [system] Successfully activated > service 'org.freedesktop.hostname1' > > #NM-Manager (Window) crashes. My LAN was still allive (whitout VPN) > Mar 5 14:55:45 desktop kernel: [ 1140.258095] nm-connection-e[2123]: > segfault at 1326510 ip 01326510 sp 7fff11ebda18 error 15 This is i segfault in NetworkManager, so I would start by figuring that one out. Probably the NM mailing list may be able to help you better. > Hint: (I am) the default User is *NOT* a Meber of the (new) Group > "systemd-network" That is ok. It is not meant for regular users. > USERNAME@desktop:~$ groups USERNAME > USERNAME : USERNAME cdrom floppy audio dip video plugdev netdev lpadmin > scanner bluetooth wireshark No specific group membership should be necessary afaik. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!
On Thu, 05.03.15 15:46, system_error (t...@cacn.de) wrote: > #NM-Manager (Window) crashes. My LAN was still allive (whitout VPN) > Mar 5 14:55:45 desktop kernel: [ 1140.258095] nm-connection-e[2123]: > segfault at 1326510 ip 01326510 sp 7fff11ebda18 error 15 This appears to be a bug in the NetworkManager's UI tool "nm-connection-editor". Please report this to the upstream or Debian bug trackers, for the NM package. As it looks systemd has nothing to do with this. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!
OK, thx! Am 05.03.2015 um 15:56 schrieb Tom Gundersen: > This is i segfault in NetworkManager, so I would start by figuring > that one out. Probably the NM mailing list may be able to help you > better. mike 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] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On Thu, 05.03.15 13:52, James Hogarth (james.hoga...@gmail.com) wrote: > Hi, > > I spent some time last night trying to track down the issue preventing > fedup from fedora 21 to 22: > > https://bugzilla.redhat.org/show_bug.cgi?id=1185604 > > I'm pretty sure I've tracked it down to when switch-root is called and > systemd-219 gets executed being passed the serialised state of systemd-216 > in the process. > > Unfortunately when this occurs the whole system is brought to a halt making > further debugging tricky. > > Any ideas on how I might reproduce on a reduced an BBS simplified testcase > for the behaviour involved? > > There is strace of pid1 from just before the switch-root to the crash along > with coredumps that have been generated on the bug. > > These tests were carried out with enforcing=0 at the kernel command line so > I'm reasonably confident the bug is not SELinux related. Well, journald is terminated during the switch root transition, since we want to transition it from the initrd journald to the host journald, much like PID 1 as well, hence the journal logs end right before the switch root, making them not particularly useful in this case. Right before switch rooting systemd will kill all remaining processes of the initrd, including the strace, hence the strace logs aren't that useful either, they end before the transition. Please boot with "systemd.log_level=debug systemd.log_target=kmsg" on the kernel cmdline, which ensures the logs go to the kernel log buffer. And then please provide the output this generates here. Also see: http://freedesktop.org/wiki/Software/systemd/Debugging/ 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] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!
On 03/05/2015 02:46 PM, system_error wrote: Mar 5 14:55:45 desktop kernel: [ 1140.258095] nm-connection-e[2123]: segfault at 1326510 ip 01326510 sp 7fff11ebda18 error 15 I'm not sure how you came to the conclusion that NetworkManager segfaulting is systemd's fault but file a bug against NetworkManager in your distro or report it upstream. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix handling of duplicate lines [was: Regression in 219: tmpfiles.d order not respected any more]
Zbigniew Jędrzejewski-Szmek [2015-03-05 15:47 +0100]: > Looks good, please push! Done, thanks for reviewing! 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-networkd and bonding config
On Thu, Mar 5, 2015 at 3:47 PM, Tom Gundersen wrote: > The kernel creates bond0 itself. This is confusing and we should > probably request the kernel to stop doing that (patch needed). You can use "options bonding max_bonds=0" to disable the creation of bond0. -- Michał Bartoszkiewicz ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix handling of duplicate lines [was: Regression in 219: tmpfiles.d order not respected any more]
On 5 March 2015 at 15:14, Martin Pitt wrote: > Zbigniew Jędrzejewski-Szmek [2015-03-05 15:47 +0100]: >> Looks good, please push! > > Done, thanks for reviewing! > Is this going into v219-stable as well? -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix handling of duplicate lines [was: Regression in 219: tmpfiles.d order not respected any more]
On Thu, Mar 05, 2015 at 03:37:46PM +, Dimitri John Ledkov wrote: > On 5 March 2015 at 15:14, Martin Pitt wrote: > > Zbigniew Jędrzejewski-Szmek [2015-03-05 15:47 +0100]: > >> Looks good, please push! > > > > Done, thanks for reviewing! > > > > Is this going into v219-stable as well? Yes. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd vxlan: Add support for enabling UDP checksums
Add UDPCheckSum option to enable transmitting UDP checksums when doing
VXLAN/IPv4. Add UDP6ZeroChecksumRx, and UDP6ZeroChecksumTx
options to enable sending zero checksums and receiving zero
checksums in VXLAN/IPv6
V2: rename Udp to UDP
---
man/systemd.netdev.xml | 20 +++-
src/network/networkd-netdev-gperf.gperf | 3 +++
src/network/networkd-netdev-vxlan.c | 27 +++
src/network/networkd-netdev-vxlan.h | 3 +++
4 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index e278aa1..7800dc4 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -391,7 +391,25 @@
A boolean. When true
route short circuit is turned on.
-
+
+
UDPCheckSum=
+
+A boolean. When true
transmitting UDP checksums when doing VXLAN/IPv4 is turned on.
+
+
+
+
UDP6ZeroChecksumTx=
+
+ A boolean. When true
sending zero checksums in VXLAN/IPv6 is turned on.
+
+
+
+
UDP6ZeroCheckSumRx=
+
+ A boolean. When true
receiving zero checksums in VXLAN/IPv6 is turned on.
+
+
+
[Tunnel] Section Options
diff --git a/src/network/networkd-netdev-gperf.gperf
b/src/network/networkd-netdev-gperf.gperf
index 963c47c..c06344c 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -47,6 +47,9 @@ VXLAN.ARPProxy, config_parse_bool,
0,
VXLAN.L2MissNotification, config_parse_bool, 0,
offsetof(VxLan, l2miss)
VXLAN.L3MissNotification, config_parse_bool, 0,
offsetof(VxLan, l3miss)
VXLAN.RouteShortCircuit, config_parse_bool, 0,
offsetof(VxLan, route_short_circuit)
+VXLAN.UDPCheckSum,config_parse_bool, 0,
offsetof(VxLan, udpcsum)
+VXLAN.UDP6ZeroCheckSumRx, config_parse_bool, 0,
offsetof(VxLan, udp6zerocsumrx)
+VXLAN.UDP6ZeroCheckSumTx, config_parse_bool, 0,
offsetof(VxLan, udp6zerocsumtx)
VXLAN.FDBAgeingSec, config_parse_sec, 0,
offsetof(VxLan, fdb_ageing)
Tun.OneQueue, config_parse_bool, 0,
offsetof(TunTap, one_queue)
Tun.MultiQueue, config_parse_bool, 0,
offsetof(TunTap, multi_queue)
diff --git a/src/network/networkd-netdev-vxlan.c
b/src/network/networkd-netdev-vxlan.c
index d5128cb..d9b13e3 100644
--- a/src/network/networkd-netdev-vxlan.c
+++ b/src/network/networkd-netdev-vxlan.c
@@ -135,6 +135,30 @@ static int netdev_vxlan_fill_message_create(NetDev
*netdev, Link *link, sd_rtnl_
}
}
+r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_CSUM, v->udpcsum);
+if (r < 0) {
+log_netdev_error(netdev,
+ "Could not append IFLA_VXLAN_UDP_CSUM
attribute: %s",
+ strerror(-r));
+return r;
+}
+
+r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_ZERO_CSUM6_TX,
v->udp6zerocsumtx);
+if (r < 0) {
+log_netdev_error(netdev,
+ "Could not append
IFLA_VXLAN_UDP_ZERO_CSUM6_TX attribute: %s",
+ strerror(-r));
+return r;
+}
+
+r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_ZERO_CSUM6_RX,
v->udp6zerocsumrx);
+if (r < 0) {
+log_netdev_error(netdev,
+ "Could not append
IFLA_VXLAN_UDP_ZERO_CSUM6_RX attribute: %s",
+ strerror(-r));
+return r;
+}
+
return r;
}
@@ -199,6 +223,9 @@ static void vxlan_init(NetDev *netdev) {
v->id = VXLAN_VID_MAX + 1;
v->learning = true;
+v->udpcsum = false;
+v->udp6zerocsumtx = false;
+
Re: [systemd-devel] [PATCH] networkd vxlan: Add support for enabling UDP checksums
On Thu, 05 Mar 2015 16:51:37 +0530, Lennart Poettering wrote: On Thu, 05.03.15 14:05, Susant Sahani (sus...@redhat.com) wrote: Add UdpCheckSum option to enable transmitting UDP checksums when doing VXLAN/IPv4. Add Udp6ZeroChecksumRx, and Udp6ZeroChecksumTx options to enable sending zero checksums and receiving zero checksums in VXLAN/IPv6 I think useing the capitalization "UDPCheckSum=" instead of "UdpCheckSum=" would be more in line with how we capitalize this otherwise. (Also, indentation problems in the man page...) Yes renamed to UDP and fixed indentation . Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!
On Thu, 2015-03-05 at 16:00 +0100, system_error wrote: > OK, thx! > > Am 05.03.2015 um 15:56 schrieb Tom Gundersen: > > This is i segfault in NetworkManager, so I would start by figuring > > that one out. Probably the NM mailing list may be able to help you > > better. nm-connection-editor, to be precise, not NetworkManager itself. Best to transfer this discussion into bugzilla, or over to the NetworkManager mailing list: https://mail.gnome.org/mailman/listinfo/networkmanager-list Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd and bonding config
On Thu, 05 Mar 2015 21:01:53 +0530, Michał Bartoszkiewicz wrote: On Thu, Mar 5, 2015 at 3:47 PM, Tom Gundersen wrote: The kernel creates bond0 itself. This is confusing and we should probably request the kernel to stop doing that (patch needed). You can use "options bonding max_bonds=0" to disable the creation of bond0. this options is not a netlink parameter.networkd does not use module parameters I guess. Specifically to use it we need to add /etc/modprobe.d/bonding.conf options bonding max_bonds=0 Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On 5 March 2015 at 15:10, Lennart Poettering wrote: > > > Right before switch rooting systemd will kill all remaining processes > of the initrd, including the strace, hence the strace logs aren't that > useful either, they end before the transition. > > Please boot with "systemd.log_level=debug systemd.log_target=kmsg" on > the kernel cmdline, which ensures the logs go to the kernel log > buffer. And then please provide the output this generates here. > > Also see: > > http://freedesktop.org/wiki/Software/systemd/Debugging/ > > Thanks Lennart - good point about the strace being killed before the interesting bit... This makes it annoyingly tricky to see what is happening as the systemd-219 binary gets loaded... Screenshot has been attached to the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1185604#c22 Doesn't show much though - just a SEGV reported by pid1 that immediately results in execution being halted. Tried to put together a reduced testcase via a yum installroot style container to switch-root into to see what that behaviour is like and do see a segfault - not certain if this is the same being seen during the fedup switch-root though... Any ideas to get a better grasp on this? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!
2015-03-05 17:54 GMT+01:00 Dan Williams : > On Thu, 2015-03-05 at 16:00 +0100, system_error wrote: >> OK, thx! >> >> Am 05.03.2015 um 15:56 schrieb Tom Gundersen: >> > This is i segfault in NetworkManager, so I would start by figuring >> > that one out. Probably the NM mailing list may be able to help you >> > better. > > nm-connection-editor, to be precise, not NetworkManager itself. Might be an issue of the NM-openvpn plugin. > transfer this discussion into bugzilla, or over to the NetworkManager > mailing list: > > https://mail.gnome.org/mailman/listinfo/networkmanager-list If you can share that .conf file, that would probably help to reproduce the issue. As Dan said, best followup on the NetworkManager mailing list. -- 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] systemd-networkd and bonding config
On 03/05/2015 09:31 AM, Michał Bartoszkiewicz wrote: You can use "options bonding max_bonds=0" to disable the creation of bond0. Now there's a poorly documented (and named) module parameter! -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging
On 2015-02-28 at 00:50 +0300, Ivan Shapovalov wrote: > On 2015-02-27 at 22:25 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Feb 25, 2015 at 09:40:23PM +0300, Ivan Shapovalov wrote: > > > 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. > > This looks good. I seems to be the correct thing to do independently of the > > idea to split device states into three with the new pending state. > > Let's see what Lennart thinks though. > > Hmm.. This does not relate to the ongoing discussion about adding a > third state for .device units. This is about coldplugging .path > and .timer units during reloads. > Ping? I don't want to miss v220 as well :) -- 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] [PATCH 0/3] using firstboot and sysusers to construct an initramfs
On 2015-02-26 at 02:53 +0300, Ivan Shapovalov wrote: > 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. > Anyone? -- 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] [PATCH 0/3] using firstboot and sysusers to construct an initramfs
On Thu, Mar 05, 2015 at 09:09:54PM +0300, Ivan Shapovalov wrote: > On 2015-02-26 at 02:53 +0300, Ivan Shapovalov wrote: > > 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. > > > > Anyone? 2/3 and 3/3 look fine. For 1/3 I was wondering if it wouldn't be simpler to simply copy the sysuser files into the tree. The semantics are then clear. But right now, if there are sysuser files in the source root, and in the destination root, it becomes unclear how to sort and merge them. Zbyszek ___ 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
On 2015-03-05 at 19:16 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Mar 05, 2015 at 09:09:54PM +0300, Ivan Shapovalov wrote: > > On 2015-02-26 at 02:53 +0300, Ivan Shapovalov wrote: > > > 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. > > > > > > > Anyone? > 2/3 and 3/3 look fine. For 1/3 I was wondering if it wouldn't be simpler > to simply copy the sysuser files into the tree. The semantics are then > clear. But right now, if there are sysuser files in the source root, and > in the destination root, it becomes unclear how to sort and merge them. Well, the intended semantics are pretty clear as well: simply ignore configs everywhere except the --config-root. (Just like we ignore configs in / when --root is given, for example.) Yes, copying/symlinking sysusers.d directories or individual files into the initramfs build root is less intrusive from the code perspective. But what if people add their own sysusers.d (people tend to have crazy setups...)? That'll need to be worked around. OTOH, the proposed changes are quite simple, and if needed, people with strange setups could just rm the generated files. However, no strong preference. -- 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
[systemd-devel] [PATCH] tmpfiles.c: Honor ordering within files as the docs say.
Previously, globs would always get processed first followed by any other
items in arbitrary order. This is contrary to the documentation which
states "Otherwise, the files/directories are processed in the order they
are listed."
To fix this, remove the separate "globs" hashmap, and instead use only one
marking each entry as a glob or not. There should be little overhead
from doing this, considering the only time nested processing will occur
is for processing of globs which are not of type "X".
Signed-off-by: Randy Witt
---
src/tmpfiles/tmpfiles.c | 53 ++---
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 917bb3c..0b6d226 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -116,6 +116,7 @@ typedef struct Item {
bool force:1;
bool done:1;
+bool glob:1;
} Item;
typedef struct ItemArray {
@@ -137,7 +138,7 @@ static const char conf_file_dirs[] =
CONF_DIRS_NULSTR("tmpfiles");
#define MAX_DEPTH 256
-static Hashmap *items = NULL, *globs = NULL;
+static OrderedHashmap *items = NULL;
static Set *unix_sockets = NULL;
static bool needs_glob(ItemType t) {
@@ -176,17 +177,17 @@ static bool takes_ownership(ItemType t) {
RECURSIVE_REMOVE_PATH);
}
-static struct Item* find_glob(Hashmap *h, const char *match) {
+static struct Item* find_glob(OrderedHashmap *h, const char *match) {
ItemArray *j;
Iterator i;
-HASHMAP_FOREACH(j, h, i) {
+ORDERED_HASHMAP_FOREACH(j, h, i) {
unsigned n;
for (n = 0; n < j->count; n++) {
Item *item = j->items + n;
-if (fnmatch(item->path, match,
FNM_PATHNAME|FNM_PERIOD) == 0)
+if (item->glob && fnmatch(item->path, match,
FNM_PATHNAME|FNM_PERIOD) == 0)
return item;
}
}
@@ -391,12 +392,12 @@ static int dir_cleanup(
}
/* Is there an item configured for this path? */
-if (hashmap_get(items, sub_path)) {
+if (ordered_hashmap_get(items, sub_path)) {
log_debug("Ignoring \"%s\": a separate entry exists.",
sub_path);
continue;
}
-if (find_glob(globs, sub_path)) {
+if (find_glob(items, sub_path)) {
log_debug("Ignoring \"%s\": a separate glob exists.",
sub_path);
continue;
}
@@ -1378,7 +1379,7 @@ static int process_item(Item *i) {
PATH_FOREACH_PREFIX(prefix, i->path) {
ItemArray *j;
-j = hashmap_get(items, prefix);
+j = ordered_hashmap_get(items, prefix);
if (j) {
int s;
@@ -1505,7 +1506,6 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
_cleanup_free_ char *action = NULL, *mode = NULL, *user = NULL, *group
= NULL, *age = NULL, *path = NULL;
_cleanup_(item_free_contents) Item i = {};
ItemArray *existing;
-Hashmap *h;
int r, c = -1, pos;
bool force = false, boot = false;
@@ -1739,9 +1739,9 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
i.age_set = true;
}
-h = needs_glob(i.type) ? globs : items;
+i.glob = needs_glob(i.type);
-existing = hashmap_get(h, i.path);
+existing = ordered_hashmap_get(items, i.path);
if (existing) {
unsigned n;
@@ -1752,7 +1752,7 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
}
} else {
existing = new0(ItemArray, 1);
-r = hashmap_put(h, i.path, existing);
+r = ordered_hashmap_put(items, i.path, existing);
if (r < 0)
return log_oom();
}
@@ -1911,14 +1911,20 @@ static int read_config_file(const char *fn, bool
ignore_enoent) {
}
/* we have to determine age parameter for each entry of type X */
-HASHMAP_FOREACH(i, globs, iterator) {
+ORDERED_HASHMAP_FOREACH(i, items, iterator) {
Iterator iter;
Item *j, *candidate_item = NULL;
+int number = 0;
+if (!i->glob)
+continue;
if (i->type != IGNORE_DIRECTORY_PATH)
continue;
-HASHMAP_FOREACH(j, items, iter) {
+ORDERED_HASHMAP_FOREACH(j, items, iter) {
+number++;
+if (j == i)
+continue;
if (j->type != CREATE_DIRECTORY && j->type !=
TRUN
Re: [systemd-devel] systemd-networkd and bonding config
> You can use "options bonding max_bonds=0" to disable the creation of > bond0. > That's exactly what I needed: # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin) MII Status: up MII Polling Interval (ms): 1000 Up Delay (ms): 5000 Down Delay (ms): 5000 Slave Interface: wlan0 MII Status: up Speed: Unknown Duplex: Unknown Link Failure Count: 0 Permanent HW addr: c0:cb:38:01:f0:f5 Slave queue ID: 0 Slave Interface: eth1 MII Status: going down Speed: 10 Mbps Duplex: half Link Failure Count: 1 Permanent HW addr: 3c:4a:92:00:4c:5b Slave queue ID: 0 There's only one bond interface and also the MAC address is the right one. pgpLXS8DxVp_J.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/4] Document the new parameter CowJournal
From: Goffredo Baroncelli Document: - the new parameter CowJournal in journald.conf - the new options --cow-journal and --no-cow-journal for systemd-journal-remote. Signed-off-by: Goffredo Baroncelli --- man/journald.conf.xml | 56 ++ man/systemd-journal-remote.xml | 34 + 2 files changed, 90 insertions(+) diff --git a/man/journald.conf.xml b/man/journald.conf.xml index 364b58f..9be19b8 100644 --- a/man/journald.conf.xml +++ b/man/journald.conf.xml @@ -362,6 +362,62 @@ /dev/console. + +CowJournal= + + Controls the "no copy on write" attribute for the +journal file. + If CowJournal=no this attribute is set. + If CowJournal=yes this attribute is reset. + + + For the BTRFS filesystem the "no copy on write" attribute disables + the COW behavior and the checksum feature ; this leads to a faster + journal operations. Instead if this attribute is not set, the COW + behavior and the checksum feature are enabled but the performances are + slower. + + BTRFS uses the checksums to detect a corrupted file; the checksums + are also used to automatically correct the file if a good copy is + available (as in a RAID1 BTRFS filesystems). Without checksums, BTRFS + is not able to detect and to repair a corrupted file. + + In case of a BTRFS filesystem without redundancy (i.e. single + disk), it is safe tCowJournal=no because in any case + there is no a good copy available to correct the file. + + Refer to man pages such as + btrfs + 5 and + chattr + 1 + for more details. + + + + + + +CowJournal= + +Controls the COW/NOCOW attribute for the journal file. +If CowJournal=no the journal file has the NOCOW +flags set. +For the BTRFS filesystem this means that the COW behaviour (Copy +On Write) is disable but also the checksum protection is also disabled. +In this case journal operations are faster, but the journal file is not +protected by the filesystem checksums. +If CowJournal=yes the journal file has the NOCOW +flag unset, and it is protected by the BTRFS checksum but the +perfomance are slower. +If the the journal file is corrupted on the disk and a good copy +(raid mirror) is available, the checksum are used by BTRFS to rebuild +the file content during a SCRUB process. If the checksum is not +available, the SCRUB process is unable the repair of the journal file. +In case of a single volume filesystem (no RAID), it is safe to have +NoCowJournal=yes. + + diff --git a/man/systemd-journal-remote.xml b/man/systemd-journal-remote.xml index 2687662..b14f4e3 100644 --- a/man/systemd-journal-remote.xml +++ b/man/systemd-journal-remote.xml @@ -258,6 +258,40 @@ +--cow-journal +--no-cow-journal + + Controls the "no copy on write" attribute for the +journal file. + If --no-cow-journal is passed, this attribute is set. + If --cow-journal is passed, this attribute is reset. + + + For the BTRFS filesystem the "no copy on write" attribute disables + the COW behavior and the checksum feature ; this leads to a faster + journal operations. Instead if this attribute is not set, the COW + behavior and the checksum feature are enabled but the performances are + slower. + + BTRFS uses the checksums to detect a corrupted file; the checksums + are also used to automatically correct the file if a good copy is + available (as in a RAID1 BTRFS filesystems). Without checksums, BTRFS + is not able to detect and to repair a corrupted file. + + In case of a BTRFS filesystem without redundancy (i.e. single + disk), it is safe to pass --no-cow-journal because in any case + there is no a good copy available to correct the file. + + Refer to man pages such as + btrfs + 5 and + chattr + 1 + for more details. + + + + --seal --no-seal -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/4] Add BTRFS COW journal option
From: Goffredo Baroncelli
The commit 11689d2a force the NOCOW flag of the journal files. This was needed
because systemd-journald has very poor perfomance when the filesytem is
BTRFS due to its the COW behavior.
However removing the COW behavior, the journal file also lost the
btrfs checksum protection, and this disables the BTRFS capability to rebuild a
corrupted file [1] in a RAID filesystem.
This patch adds the option "CowJournal" to the journald.conf to disable/enable
the NOCOW flag for the journal file.
[1] http://en.wikipedia.org/wiki/Data_scrubbing#Btrfs
Signed-off-by: Goffredo Baroncelli
---
src/journal/journal-file.c | 34 +-
src/journal/journal-file.h | 3 +++
src/journal/journald-gperf.gperf | 1 +
src/journal/journald-server.c| 8
src/journal/journald-server.h| 2 ++
src/journal/journald.conf| 1 +
src/journal/sd-journal.c | 2 +-
7 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 2845e05..db0fa35 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -2529,6 +2529,7 @@ int journal_file_open(
mode_t mode,
bool compress,
bool seal,
+bool allow_cow_journal,
JournalMetrics *metrics,
MMapCache *mmap_cache,
JournalFile *template,
@@ -2558,6 +2559,7 @@ int journal_file_open(
f->mode = mode;
f->flags = flags;
+f->allow_cow_journal = allow_cow_journal;
f->prot = prot_from_flags(flags);
f->writable = (flags & O_ACCMODE) != O_RDONLY;
#if defined(HAVE_LZ4)
@@ -2603,16 +2605,19 @@ int journal_file_open(
if (f->last_stat.st_size == 0 && f->writable) {
-/* Before we write anything, turn off COW logic. Given
- * our write pattern that is quite unfriendly to COW
- * file systems this should greatly improve
- * performance on COW file systems, such as btrfs, at
- * the expense of data integrity features (which
- * shouldn't be too bad, given that we do our own
- * checksumming). */
-r = chattr_fd(f->fd, true, FS_NOCOW_FL);
-if (r < 0)
-log_warning_errno(errno, "Failed to set file
attributes: %m");
+if (!f->allow_cow_journal) {
+/* Before we write anything, turn off COW logic. Given
+ * our write pattern that is quite unfriendly to COW
+ * file systems this should greatly improve
+ * performance on COW file systems, such as btrfs, at
+ * the expense of data integrity features (which
+ * shouldn't be too bad, given that we do our own
+ * checksumming). */
+r = chattr_fd(f->fd, true, FS_NOCOW_FL);
+if (r < 0)
+log_warning_errno(errno,
+"Failed to set file attributes: %m");
+}
/* Let's attach the creation time to the journal file,
* so that the vacuuming code knows the age of this
@@ -2773,7 +2778,7 @@ int journal_file_rotate(JournalFile **f, bool compress,
bool seal) {
* we archive them */
old_file->defrag_on_close = true;
-r = journal_file_open(old_file->path, old_file->flags, old_file->mode,
compress, seal, NULL, old_file->mmap, old_file, &new_file);
+r = journal_file_open(old_file->path, old_file->flags, old_file->mode,
compress, seal, old_file->allow_cow_journal, NULL, old_file->mmap, old_file,
&new_file);
journal_file_close(old_file);
*f = new_file;
@@ -2786,6 +2791,7 @@ int journal_file_open_reliably(
mode_t mode,
bool compress,
bool seal,
+bool allow_cow_journal,
JournalMetrics *metrics,
MMapCache *mmap_cache,
JournalFile *template,
@@ -2796,7 +2802,8 @@ int journal_file_open_reliably(
_cleanup_free_ char *p = NULL;
r = journal_file_open(fname, flags, mode, compress, seal,
- metrics, mmap_cache, template, ret);
+ allow_cow_journal, metrics, mmap_cache,
+ template, ret);
if (r != -EBADMSG && /* corrupted */
r != -ENODATA && /* truncated */
r != -EHOSTDOWN && /* other machine */
@@ -2838,7 +2845,8 @@ int journal_file_open_reliably(
log_warning("File %s corrupted or uncleanly shut down, renaming and
replacing.", fname);
return journal_file_open(fname, flags, mode, compress, seal,
-
[systemd-devel] [PATCH 3/4] Update the tests
From: Goffredo Baroncelli
Update the tests due to the new interface journal_file_open() and
journal_file_open_reliably().
Signed-off-by: Goffredo Baroncelli
---
src/journal/test-journal-flush.c| 2 +-
src/journal/test-journal-interleaving.c | 11 +++
src/journal/test-journal-stream.c | 6 +++---
src/journal/test-journal-verify.c | 6 +++---
src/journal/test-journal.c | 17 +++--
5 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/src/journal/test-journal-flush.c b/src/journal/test-journal-flush.c
index 914ca0b..6d5d4d1 100644
--- a/src/journal/test-journal-flush.c
+++ b/src/journal/test-journal-flush.c
@@ -37,7 +37,7 @@ int main(int argc, char *argv[]) {
assert_se(mkdtemp(dn));
fn = strappend(dn, "/test.journal");
-r = journal_file_open(fn, O_CREAT|O_RDWR, 0644, false, false, NULL,
NULL, NULL, &new_journal);
+r = journal_file_open(fn, O_CREAT|O_RDWR, 0644, false, false, false,
NULL, NULL, NULL, &new_journal);
assert_se(r >= 0);
r = sd_journal_open(&j, 0);
diff --git a/src/journal/test-journal-interleaving.c
b/src/journal/test-journal-interleaving.c
index 3c70601..e58d2b7 100644
--- a/src/journal/test-journal-interleaving.c
+++ b/src/journal/test-journal-interleaving.c
@@ -52,7 +52,7 @@ noreturn static void log_assert_errno(const char *text, int
eno, const char *fil
static JournalFile *test_open(const char *name) {
JournalFile *f;
-assert_ret(journal_file_open(name, O_RDWR|O_CREAT, 0644, true, false,
NULL, NULL, NULL, &f));
+assert_ret(journal_file_open(name, O_RDWR|O_CREAT, 0644, true, false,
false, NULL, NULL, NULL, &f));
return f;
}
@@ -208,7 +208,8 @@ static void test_sequence_numbers(void) {
assert_se(chdir(t) >= 0);
assert_se(journal_file_open("one.journal", O_RDWR|O_CREAT, 0644,
-true, false, NULL, NULL, NULL, &one) == 0);
+true, false, false, NULL, NULL,
+NULL, &one) == 0);
append_number(one, 1, &seqnum);
printf("seqnum=%"PRIu64"\n", seqnum);
@@ -225,7 +226,8 @@ static void test_sequence_numbers(void) {
memcpy(&seqnum_id, &one->header->seqnum_id, sizeof(sd_id128_t));
assert_se(journal_file_open("two.journal", O_RDWR|O_CREAT, 0644,
-true, false, NULL, NULL, one, &two) == 0);
+true, false, false, NULL, NULL,
+one, &two) == 0);
assert_se(two->header->state == STATE_ONLINE);
assert_se(!sd_id128_equal(two->header->file_id, one->header->file_id));
@@ -256,7 +258,8 @@ static void test_sequence_numbers(void) {
seqnum = 0;
assert_se(journal_file_open("two.journal", O_RDWR, 0,
-true, false, NULL, NULL, NULL, &two) == 0);
+true, false, false, NULL, NULL,
+NULL, &two) == 0);
assert_se(sd_id128_equal(two->header->seqnum_id, seqnum_id));
diff --git a/src/journal/test-journal-stream.c
b/src/journal/test-journal-stream.c
index 3996e77..3377480 100644
--- a/src/journal/test-journal-stream.c
+++ b/src/journal/test-journal-stream.c
@@ -90,9 +90,9 @@ int main(int argc, char *argv[]) {
assert_se(mkdtemp(t));
assert_se(chdir(t) >= 0);
-assert_se(journal_file_open("one.journal", O_RDWR|O_CREAT, 0666, true,
false, NULL, NULL, NULL, &one) == 0);
-assert_se(journal_file_open("two.journal", O_RDWR|O_CREAT, 0666, true,
false, NULL, NULL, NULL, &two) == 0);
-assert_se(journal_file_open("three.journal", O_RDWR|O_CREAT, 0666,
true, false, NULL, NULL, NULL, &three) == 0);
+assert_se(journal_file_open("one.journal", O_RDWR|O_CREAT, 0666, true,
false, false, NULL, NULL, NULL, &one) == 0);
+assert_se(journal_file_open("two.journal", O_RDWR|O_CREAT, 0666, true,
false, false, NULL, NULL, NULL, &two) == 0);
+assert_se(journal_file_open("three.journal", O_RDWR|O_CREAT, 0666,
true, false, false, NULL, NULL, NULL, &three) == 0);
for (i = 0; i < N_ENTRIES; i++) {
char *p, *q;
diff --git a/src/journal/test-journal-verify.c
b/src/journal/test-journal-verify.c
index 9da120c..71155e4 100644
--- a/src/journal/test-journal-verify.c
+++ b/src/journal/test-journal-verify.c
@@ -55,7 +55,7 @@ static int raw_verify(const char *fn, const char
*verification_key) {
JournalFile *f;
int r;
-r = journal_file_open(fn, O_RDONLY, 0666, true, !!verification_key,
NULL, NULL, NULL, &f);
+r = journal_file_open(fn, O_RDONLY, 0666, true, !!verification_key,
false, NULL, NULL, NULL, &f);
if (r < 0)
return r;
@@ -88,7 +88,7 @@ int main(int argc, char *argv[]) {
log_info("Generating...");
[systemd-devel] [RFC][PATCH] Add option to enable COW for journal file
Hi All, the enclosed patches add an option to the journald.conf file to allow a COW behavior for the journal files. The commit 11689d2a force the NOCOW flag of the journal files. This was needed because systemd-journald has very poor performance when the filesytem is BTRFS due to its the COW behavior. However removing the COW behavior, the journal file also lost the btrfs checksum protection, and this disables the BTRFS capability to rebuild a corrupted file [1] in a RAID filesystem. So this limits one of the biggest benefit of BTRFS. This patch adds the option "CowJournal" to the journald.conf to disable/enable the NOCOW flag for the journal file, allowing to revert to the old behavior. These patches are tagged as RFC, because I am not sure about the naming of the option (now "CowJournal"). I ask some feedback. Comments are welcome. [1] http://en.wikipedia.org/wiki/Data_scrubbing#Btrfs BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/4] Update journal-remote
From: Goffredo Baroncelli
Update the journal-remote due to the update of the parameters of
the functions journal_file_open()/journal_file_open_reliably().
Moreover two options are added to systemd-journal-remote:
--cow-journal and --no-cow-journal to
unset/set the "no copy on write" attribute.
Signed-off-by: Goffredo Baroncelli
---
src/journal-remote/journal-remote.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/journal-remote/journal-remote.c
b/src/journal-remote/journal-remote.c
index 8f32a9a..5ccd237 100644
--- a/src/journal-remote/journal-remote.c
+++ b/src/journal-remote/journal-remote.c
@@ -64,6 +64,7 @@ static char* arg_listen_https = NULL;
static char** arg_files = NULL;
static int arg_compress = true;
static int arg_seal = false;
+static int arg_cow_journal = false;
static int http_socket = -1, https_socket = -1;
static char** arg_gnutls_log = NULL;
@@ -200,6 +201,7 @@ static int open_output(Writer *w, const char* host) {
r = journal_file_open_reliably(output,
O_RDWR|O_CREAT, 0640,
arg_compress, arg_seal,
+ arg_cow_journal,
&w->metrics,
w->mmap,
NULL, &w->journal);
@@ -1149,6 +1151,8 @@ static void help(void) {
" --listen-https=ADDRListen for HTTPS connections at
ADDR\n"
" -o --output=FILE|DIR Write output to FILE or
DIR/external-*.journal\n"
" --compress[=BOOL] XZ-compress the output journal
(default: yes)\n"
+ " --cow-journal[=BOOL] Enable/Disable the COW behaviour\n"
+ "for the journal file (default:
no)\n"
" --seal[=BOOL] Use event sealing (default: no)\n"
" --key=FILENAME SSL key in PEM format (default:\n"
"\"" PRIV_KEY_FILE "\")\n"
@@ -1179,6 +1183,7 @@ static int parse_argv(int argc, char *argv[]) {
ARG_CERT,
ARG_TRUST,
ARG_GNUTLS_LOG,
+ARG_COW_JOURNAL,
};
static const struct option options[] = {
@@ -1192,6 +1197,7 @@ static int parse_argv(int argc, char *argv[]) {
{ "output", required_argument, NULL, 'o' },
{ "split-mode", required_argument, NULL, ARG_SPLIT_MODE },
{ "compress", optional_argument, NULL, ARG_COMPRESS },
+{ "cow-journal", optional_argument, NULL, ARG_COW_JOURNAL },
{ "seal", optional_argument, NULL, ARG_SEAL },
{ "key", required_argument, NULL, ARG_KEY },
{ "cert", required_argument, NULL, ARG_CERT },
@@ -1347,6 +1353,20 @@ static int parse_argv(int argc, char *argv[]) {
break;
+case ARG_COW_JOURNAL:
+if (optarg) {
+r = parse_boolean(optarg);
+if (r < 0) {
+log_error("Failed to parse
--allow-cow-journal= parameter.");
+return -EINVAL;
+}
+
+arg_cow_journal = !!r;
+} else
+arg_cow_journal = true;
+
+break;
+
case ARG_SEAL:
if (optarg) {
r = parse_boolean(optarg);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On 5 March 2015 at 17:07, James Hogarth wrote: > On 5 March 2015 at 15:10, Lennart Poettering wrote: >> >> >> Right before switch rooting systemd will kill all remaining processes >> of the initrd, including the strace, hence the strace logs aren't that >> useful either, they end before the transition. >> >> Please boot with "systemd.log_level=debug systemd.log_target=kmsg" on >> the kernel cmdline, which ensures the logs go to the kernel log >> buffer. And then please provide the output this generates here. >> >> Also see: >> >> http://freedesktop.org/wiki/Software/systemd/Debugging/ >> >> > > Thanks Lennart - good point about the strace being killed before the > interesting bit... > > This makes it annoyingly tricky to see what is happening as the > systemd-219 binary gets loaded... > > Screenshot has been attached to the bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1185604#c22 > > Doesn't show much though - just a SEGV reported by pid1 that > immediately results in execution being halted. > > Tried to put together a reduced testcase via a yum installroot style > container to switch-root into to see what that behaviour is like and > do see a segfault - not certain if this is the same being seen during > the fedup switch-root though... > > Any ideas to get a better grasp on this? So it's actually slightly more complicated than I had originally thought (thanks #fedora-qa) after a brief chat with wwoods. The path taken in the process is the initrd used by fedup is built from the newer Fedora release (ie in the present testing this contains systemd-219). This starts up and then carries out a switch-root to the actual system which in this case has systemd-216. The reason for this is to simplify finding out where mount points are for a clean upgrade - it's been felt the easiest way is to just 'ask' the actual system to do this. After the mount points are all up switch-root is used to switch back to the initrd setup so that the upgrades can be carried out on teh non-running system... so we have a systemd-216 to 219 transition here. This naturally means that the serialization/deserialization needs to be forwards *and* backwards compatible between 216 and 219 for this to work. From the logs that I've pulled (see the various attachments in https://bugzilla.redhat.com/show_bug.cgi?id=1185604 for them) it would appear the 219 -> 216 process is fine but then switching back from 216 -> 219 is failing with the associated segfault. There appears to be a couple of options here: 1) Try to get a workable reduced test case or better debugging from the 216 -> 219 transition to work out why that is failing. 2) Have some sort of generator or call or similar that allows the systemd-newer in the initrd to parse the unit files and fstab of the installed system and carry out any mounting itself rather than using switch-root to the installed system and asking it to do so. This would then eliminate the jumping backwards and forwards between systemd versions during the upgrade process. Any thoughts on either of these options to try to get a way forwards... or is there any additional debugging or diagnostics that I can provide to help? Cheers, James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
2015-03-05 11:58 GMT+01:00 : > From: Harald Hoyer > > The speedup is significant > > Original libtool > $ ccache -C && make clean && time make -j4 > […] > real6m4.104s > user13m49.234s > sys7m37.864s > > Original libtool + dolt > $ ccache -C && make clean && time make -j4 > […] > real2m24.869s > user7m30.198s > sys1m17.813s Hm, the speedup is nowhere near as significant here: without dolt (make): real 4m2.749s user 3m9.304s sys 0m19.032s with dolt (make): real 3m33.756s user 2m59.476s sys 0m17.632s without dolt (make -j6): real 1m42.001s user 5m3.680s sys 0m26.608s with dolt (make -j6) real 1m35.267s user 4m50.956s sys 0m24.724s libtool version is 2.4.2. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote: > 2015-03-05 11:58 GMT+01:00 : > > From: Harald Hoyer > > > > The speedup is significant > > > > Original libtool > > $ ccache -C && make clean && time make -j4 > > […] > > real6m4.104s > > user13m49.234s > > sys7m37.864s > > > > Original libtool + dolt > > $ ccache -C && make clean && time make -j4 > > […] > > real2m24.869s > > user7m30.198s > > sys1m17.813s > > Hm, the speedup is nowhere near as significant here: > without dolt (make): > real 4m2.749s > user 3m9.304s > sys 0m19.032s > > with dolt (make): > real 3m33.756s > user 2m59.476s > sys 0m17.632s > > without dolt (make -j6): > real 1m42.001s > user 5m3.680s > sys 0m26.608s > > with dolt (make -j6) > real 1m35.267s > user 4m50.956s > sys 0m24.724s > > > libtool version is 2.4.2. That's more what I'd expect with current versions of libtool, which has supposedly fixed many of the issues that motivated the creation of dolt in the first place. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
On Thu, Mar 5, 2015 at 9:58 PM, wrote: > On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote: >> 2015-03-05 11:58 GMT+01:00 : >> > From: Harald Hoyer >> > >> > The speedup is significant >> > >> > Original libtool >> > $ ccache -C && make clean && time make -j4 >> > […] >> > real6m4.104s >> > user13m49.234s >> > sys7m37.864s >> > >> > Original libtool + dolt >> > $ ccache -C && make clean && time make -j4 >> > […] >> > real2m24.869s >> > user7m30.198s >> > sys1m17.813s >> >> Hm, the speedup is nowhere near as significant here: >> without dolt (make): >> real 4m2.749s >> user 3m9.304s >> sys 0m19.032s >> >> with dolt (make): >> real 3m33.756s >> user 2m59.476s >> sys 0m17.632s >> >> without dolt (make -j6): >> real 1m42.001s >> user 5m3.680s >> sys 0m26.608s >> >> with dolt (make -j6) >> real 1m35.267s >> user 4m50.956s >> sys 0m24.724s >> >> >> libtool version is 2.4.2. > > That's more what I'd expect with current versions of libtool, which has > supposedly fixed many of the issues that motivated the creation of dolt > in the first place. Maybe it was a regression in libtool from 2.4.2 <-> 2.4.5? I have 2.4.5 here: make -j6, libtool real4m53.924s user11m4.323s sys 0m54.880s make -j6, dolt real1m58.653s user6m20.523s sys 0m28.920s -- Lucas De Marchi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
On Thu, Mar 05, 2015 at 10:33:19PM -0300, Lucas De Marchi wrote: > On Thu, Mar 5, 2015 at 9:58 PM, wrote: > > On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote: > >> 2015-03-05 11:58 GMT+01:00 : > >> > From: Harald Hoyer > >> > > >> > The speedup is significant > >> > > >> > Original libtool > >> > $ ccache -C && make clean && time make -j4 > >> > […] > >> > real6m4.104s > >> > user13m49.234s > >> > sys7m37.864s > >> > > >> > Original libtool + dolt > >> > $ ccache -C && make clean && time make -j4 > >> > […] > >> > real2m24.869s > >> > user7m30.198s > >> > sys1m17.813s > >> > >> Hm, the speedup is nowhere near as significant here: > >> without dolt (make): > >> real 4m2.749s > >> user 3m9.304s > >> sys 0m19.032s > >> > >> with dolt (make): > >> real 3m33.756s > >> user 2m59.476s > >> sys 0m17.632s > >> > >> without dolt (make -j6): > >> real 1m42.001s > >> user 5m3.680s > >> sys 0m26.608s > >> > >> with dolt (make -j6) > >> real 1m35.267s > >> user 4m50.956s > >> sys 0m24.724s > >> > >> > >> libtool version is 2.4.2. > > > > That's more what I'd expect with current versions of libtool, which has > > supposedly fixed many of the issues that motivated the creation of dolt > > in the first place. > > Maybe it was a regression in libtool from 2.4.2 <-> 2.4.5? I have 2.4.5 here: > > make -j6, libtool > real4m53.924s > user11m4.323s > sys 0m54.880s > > make -j6, dolt > real1m58.653s > user6m20.523s > sys 0m28.920s Interesting. How easily can you try 2.4.2? - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
On 03/05/2015 05:33 PM, Lucas De Marchi wrote: On Thu, Mar 5, 2015 at 9:58 PM, wrote: On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote: 2015-03-05 11:58 GMT+01:00 : From: Harald Hoyer The speedup is significant Original libtool $ ccache -C && make clean && time make -j4 […] real6m4.104s user13m49.234s sys7m37.864s Original libtool + dolt $ ccache -C && make clean && time make -j4 […] real2m24.869s user7m30.198s sys1m17.813s Hm, the speedup is nowhere near as significant here: without dolt (make): real 4m2.749s user 3m9.304s sys 0m19.032s with dolt (make): real 3m33.756s user 2m59.476s sys 0m17.632s without dolt (make -j6): real 1m42.001s user 5m3.680s sys 0m26.608s with dolt (make -j6) real 1m35.267s user 4m50.956s sys 0m24.724s libtool version is 2.4.2. That's more what I'd expect with current versions of libtool, which has supposedly fixed many of the issues that motivated the creation of dolt in the first place. Maybe it was a regression in libtool from 2.4.2 <-> 2.4.5? I have 2.4.5 here: We saw noticeable slowdowns in Yocto after upgrading as well. http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1f53edeaf9ea59dd55459a6d5a93829fb4983839 There were a number of patches submitted and evidently 2.6 is back to previous speeds. make -j6, libtool real4m53.924s user11m4.323s sys 0m54.880s make -j6, dolt real1m58.653s user6m20.523s sys 0m28.920s ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
On Thu, Mar 5, 2015 at 10:37 PM, wrote: > On Thu, Mar 05, 2015 at 10:33:19PM -0300, Lucas De Marchi wrote: >> On Thu, Mar 5, 2015 at 9:58 PM, wrote: >> > On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote: >> >> 2015-03-05 11:58 GMT+01:00 : >> >> > From: Harald Hoyer >> >> > >> >> > The speedup is significant >> >> > >> >> > Original libtool >> >> > $ ccache -C && make clean && time make -j4 >> >> > […] >> >> > real6m4.104s >> >> > user13m49.234s >> >> > sys7m37.864s >> >> > >> >> > Original libtool + dolt >> >> > $ ccache -C && make clean && time make -j4 >> >> > […] >> >> > real2m24.869s >> >> > user7m30.198s >> >> > sys1m17.813s >> >> >> >> Hm, the speedup is nowhere near as significant here: >> >> without dolt (make): >> >> real 4m2.749s >> >> user 3m9.304s >> >> sys 0m19.032s >> >> >> >> with dolt (make): >> >> real 3m33.756s >> >> user 2m59.476s >> >> sys 0m17.632s >> >> >> >> without dolt (make -j6): >> >> real 1m42.001s >> >> user 5m3.680s >> >> sys 0m26.608s >> >> >> >> with dolt (make -j6) >> >> real 1m35.267s >> >> user 4m50.956s >> >> sys 0m24.724s >> >> >> >> >> >> libtool version is 2.4.2. >> > >> > That's more what I'd expect with current versions of libtool, which has >> > supposedly fixed many of the issues that motivated the creation of dolt >> > in the first place. >> >> Maybe it was a regression in libtool from 2.4.2 <-> 2.4.5? I have 2.4.5 >> here: >> >> make -j6, libtool >> real4m53.924s >> user11m4.323s >> sys 0m54.880s >> >> make -j6, dolt >> real1m58.653s >> user6m20.523s >> sys 0m28.920s > > Interesting. How easily can you try 2.4.2? I just did it. Same speed as with dolt. -- Lucas De Marchi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is there a plan for NIC teaming support ?
В Thu, 05 Mar 2015 05:41:55 +0100 Branko пишет: > I have a need to put my NICs in "RAID0" so to speak, but according to > materials I have found on net I can't use NIC bonding driver because I > would need LACP (IEEE whatever) aware L2 switch, so I was refered to > teaming driver, which should be ( if those folks is to be believed) > replacing bond driver in future. > Linux bonding driver supports LACP (mode 4) > Since systemd doesn't support teaming ( teaming module + libeteam), I > had to scotchstape it together under systemd and it was major PITA. > > libteam doesn't seem to complicated to be included as a module in > systemd, which should take away most of the headaches... > > > > ___ > 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
