[systemd-devel] [PATCHv3] use systemd.debug on the kernel command line, not debug
From: Greg KH gre...@linuxfoundation.org
If the kernel is started with debug, that's for the kernel to switch
into debug mode. We should rely on a namespace for our options, like
everything else (with the exception of quiet). Some people want to
only debug the kernel, not systemd, and the opposite as well so make
everyone happy.
Signed-off-by: Greg KH gre...@linuxfoundation.org
Signed-off-by: Hannes Reinecke h...@suse.de
---
man/kernel-command-line.xml | 4 ++--
src/core/main.c | 19 ++-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index dbfec61..19da7a3 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -126,10 +126,10 @@
/varlistentry
varlistentry
-termvarnamedebug/varname/term
+termvarnamesystemd.debug/varname/term
listitem
paraParameter understood by
-both the kernel and the system
+the system
and service manager to control
console log verbosity. For
details, see
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee..bbacfd1 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -374,6 +374,15 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
} else
log_warning(Environment variable name '%s' is not
valid. Ignoring., value);
+} else if (streq(key, systemd.debug) !value) {
+
+/* Log to kmsg, the journal socket will fill up before the
+ * journal is started and tools running during that time
+ * will block with every log message for for 60 seconds,
+ * before they give up. */
+log_set_max_level(LOG_DEBUG);
+log_set_target(detect_container(NULL) 0 ? LOG_TARGET_CONSOLE
: LOG_TARGET_KMSG);
+
} else if (!streq(key, systemd.restore_state)
!streq(key, systemd.gpt_auto)
(startswith(key, systemd.) || startswith(key,
rd.systemd.))) {
@@ -409,6 +418,7 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
Set
default log error output for services\n
systemd.setenv=ASSIGNMENTSet
an environment variable for all spawned processes\n
systemd.restore_state=0|1
Restore backlight/rfkill state at boot\n);
+ systemd.debug
Enable debugging output\n);
}
} else if (streq(key, quiet) !value) {
@@ -416,15 +426,6 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
if (arg_show_status == _SHOW_STATUS_UNSET)
arg_show_status = SHOW_STATUS_AUTO;
-} else if (streq(key, debug) !value) {
-
-/* Log to kmsg, the journal socket will fill up before the
- * journal is started and tools running during that time
- * will block with every log message for for 60 seconds,
- * before they give up. */
-log_set_max_level(LOG_DEBUG);
-log_set_target(detect_container(NULL) 0 ? LOG_TARGET_CONSOLE
: LOG_TARGET_KMSG);
-
} else if (!in_initrd() !value) {
unsigned i;
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] libsystemd-network: Support setting DHCP client initial delay
Section 4.4.1 in RFC 2131 says that a DHCP client SHOULD wait a
random time between one and ten seconds to desynchronize DHCP
clients on startup. This is supported such that the application
can optionally set an initial delay of approximately two and eight
seconds or leave the initial value unset relying only on any
machine specific randomness chosen for the main loop.
The maximum delay of slightly more than eight seconds was chosen
as it's more convenient to compute in addition to following RFC
2131 in spirit with a sensible margin towards the 17 years passed
since the exact wording of the document. The two second initial
delay variant was added to include a more neutral timeout hopefully
good enough on a very busy network. By default no initial delay is
added, as the implementation is geared towards maximum speed.
Thanks to Ted Lemon and to Jayson Vantul pointing out the reasons
having DHCP initial delay support.
---
src/libsystemd-network/sd-dhcp-client.c | 28 +++-
src/systemd/sd-dhcp-client.h| 9 +
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/src/libsystemd-network/sd-dhcp-client.c
b/src/libsystemd-network/sd-dhcp-client.c
index 06b2d1c..eb84708 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -37,6 +37,7 @@ struct sd_dhcp_client {
DHCPState state;
sd_event *event;
int event_priority;
+enum sd_dhcp_client_initial_delay delay;
sd_event_source *timeout_resend;
int index;
int fd;
@@ -167,6 +168,15 @@ int sd_dhcp_client_set_mac(sd_dhcp_client *client,
return 0;
}
+int sd_dhcp_client_set_initial_delay(sd_dhcp_client *client,
+ enum sd_dhcp_client_initial_delay delay) {
+assert_return(client, -EINVAL);
+
+client-delay = delay;
+
+return 0;
+}
+
int sd_dhcp_client_get_lease(sd_dhcp_client *client, sd_dhcp_lease **ret) {
assert_return(client, -EINVAL);
assert_return(ret, -EINVAL);
@@ -542,6 +552,7 @@ error:
static int client_initialize_events(sd_dhcp_client *client,
sd_event_io_handler_t io_callback) {
+usec_t delay = 0;
int r;
assert(client);
@@ -560,10 +571,25 @@ static int client_initialize_events(sd_dhcp_client
*client,
client-timeout_resend = sd_event_source_unref(client-timeout_resend);
+if (IN_SET(client-state, DHCP_STATE_INIT, DHCP_STATE_INIT_REBOOT)) {
+switch (client-delay) {
+case DHCP_INITIAL_DELAY_DEFAULT:
+break;
+
+case DHCP_INITIAL_DELAY_LOW:
+delay = random_u32() 0x1f;
+break;
+
+case DHCP_INITIAL_DELAY_MAX:
+delay = random_u32() 0x7f;
+break;
+}
+}
+
r = sd_event_add_time(client-event,
client-timeout_resend,
CLOCK_MONOTONIC,
- 0, 0,
+ delay, 0,
client_timeout_resend, client);
if (r 0)
goto error;
diff --git a/src/systemd/sd-dhcp-client.h b/src/systemd/sd-dhcp-client.h
index a60bb58..e5e8550 100644
--- a/src/systemd/sd-dhcp-client.h
+++ b/src/systemd/sd-dhcp-client.h
@@ -36,6 +36,12 @@ enum {
DHCP_EVENT_EXPIRED = 4,
};
+enum sd_dhcp_client_initial_delay {
+DHCP_INITIAL_DELAY_DEFAULT = 0,
+DHCP_INITIAL_DELAY_LOW = 2,
+DHCP_INITIAL_DELAY_MAX = 8,
+};
+
typedef struct sd_dhcp_client sd_dhcp_client;
typedef void (*sd_dhcp_client_cb_t)(sd_dhcp_client *client, int event,
@@ -50,6 +56,9 @@ int sd_dhcp_client_set_request_address(sd_dhcp_client *client,
int sd_dhcp_client_set_index(sd_dhcp_client *client, int interface_index);
int sd_dhcp_client_set_mac(sd_dhcp_client *client,
const struct ether_addr *addr);
+int sd_dhcp_client_set_initial_delay(sd_dhcp_client *client,
+ enum sd_dhcp_client_initial_delay delay);
+
int sd_dhcp_client_get_lease(sd_dhcp_client *client, sd_dhcp_lease **ret);
int sd_dhcp_client_stop(sd_dhcp_client *client);
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd and After=network.target
On Wednesday 02 April 2014 at 12:00:07, Umut Tezduyar Lindskog wrote: Hi Ivan, On Wed, Apr 2, 2014 at 11:41 AM, Ivan Shapovalov intelfx...@gmail.com wrote: Hello all, I've noticed that systemd-networkd.service (ordered Before=network.target) finishes its startup before the connection is established/failed. Because of this, some networking daemons ordered After=network.target (like openvpn) are prone to failures when they attempt to connect at startup. Please take a look at http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/. It is explained there what network.target actually does. What you are expecting is a phase where interfaces up and configured. There has been some work coming up for this, 020d59000f86b3d98be763eaee6a2671f0427e46. Thanks, Umut Thanks for the link, got it. I think that for my usecase (a single interface) it is in fact usable, so I'll craft a wait-online unit using NM's one as a reference. Are there any pitfalls? -- Ivan Shapovalov / intelfx / Is this intended, or is this a bug, or have I overlooked some piece of configuration? Thanks, -- Ivan Shapovalov / intelfx / (Sent from my phone. Havoc may be wreaked on the formatting.) 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] sd-rtnl: broken test cases
Hi,
I am trying to fix the broken test cases which was working
previously . With the new refactorization and I tryied to fix them with
the attached paatch does not work . Not sure I am doing something wrong
or sd-rtnl is broken.
--
Thanks !
Susant
From 51e8b0a3d18f892c2e0bb86ca86fab99562700b8 Mon Sep 17 00:00:00 2001
From: Susant Sahani sus...@redhat.com
Date: Thu, 3 Apr 2014 13:35:56 +0530
Subject: [PATCH] sd-rtnl: fix broken test cases and add support for tunnel
This patch fixes the broken test-cases for sd-rtnl and add
support for ipip and sit tunnel
---
src/libsystemd/sd-rtnl/rtnl-types.c | 37 +
src/test/test-rtnl-manual.c | 8
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c b/src/libsystemd/sd-rtnl/rtnl-types.c
index 29ee5bc..ed1aacd 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -30,6 +30,9 @@
#include linux/if_addr.h
#include linux/if.h
+#include linux/ip.h
+#include linux/if_tunnel.h
+
#include macro.h
#include util.h
@@ -98,12 +101,40 @@ static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
#endif
};
+static const NLType rtnl_link_info_data_ipip_tunnel_types[IFLA_IPTUN_MAX + 1] = {
+[IFLA_IPTUN_LINK] = { .type = NLA_U32 },
+[IFLA_IPTUN_LOCAL] = { .type = NLA_U32 },
+[IFLA_IPTUN_REMOTE] = { .type = NLA_U32 },
+[IFLA_IPTUN_TTL]= { .type = NLA_U8 },
+[IFLA_IPTUN_TOS]= { .type = NLA_U8 },
+[IFLA_IPTUN_PMTUDISC] = { .type = NLA_U8 },
+};
+
+static const NLType rtnl_link_info_data_ipip6_tunnel_types[IFLA_IPTUN_MAX + 1] = {
+[IFLA_IPTUN_LINK] = { .type = NLA_U32 },
+[IFLA_IPTUN_LOCAL] = { .type = NLA_U32 },
+[IFLA_IPTUN_REMOTE] = { .type = NLA_U32 },
+[IFLA_IPTUN_TTL]= { .type = NLA_U8 },
+[IFLA_IPTUN_TOS]= { .type = NLA_U8 },
+[IFLA_IPTUN_PMTUDISC] = { .type = NLA_U8 },
+[IFLA_IPTUN_FLAGS] = { .type = NLA_U16 },
+[IFLA_IPTUN_PROTO] = { .type = NLA_U8 },
+/*
+[IFLA_IPTUN_6RD_PREFIX] = { .len = sizeof(struct in6_addr) },
+[IFLA_IPTUN_6RD_RELAY_PREFIX] = { .type = NLA_U32 },
+[IFLA_IPTUN_6RD_PREFIXLEN] = { .type = NLA_U16 },
+[IFLA_IPTUN_6RD_RELAY_PREFIXLEN] = { .type = NLA_U16 },
+*/
+};
+
typedef enum NLUnionLinkInfoData {
NL_UNION_LINK_INFO_DATA_BOND,
NL_UNION_LINK_INFO_DATA_BRIDGE,
NL_UNION_LINK_INFO_DATA_VLAN,
NL_UNION_LINK_INFO_DATA_VETH,
NL_UNION_LINK_INFO_DATA_MACVLAN,
+NL_UNION_LINK_INFO_DATA_IPIP_TUNNEL,
+NL_UNION_LINK_INFO_DATA_IPIP6_TUNNEL,
_NL_UNION_LINK_INFO_DATA_MAX,
_NL_UNION_LINK_INFO_DATA_INVALID = -1
} NLUnionLinkInfoData;
@@ -117,6 +148,8 @@ static const char* const nl_union_link_info_data_table[_NL_UNION_LINK_INFO_DATA_
[NL_UNION_LINK_INFO_DATA_VLAN] = vlan,
[NL_UNION_LINK_INFO_DATA_VETH] = veth,
[NL_UNION_LINK_INFO_DATA_MACVLAN] = macvlan,
+[NL_UNION_LINK_INFO_DATA_IPIP_TUNNEL] = ipip_tunnel,
+[NL_UNION_LINK_INFO_DATA_IPIP6_TUNNEL] = ipip6_tunnel,
};
DEFINE_STRING_TABLE_LOOKUP(nl_union_link_info_data, NLUnionLinkInfoData);
@@ -132,6 +165,10 @@ static const NLTypeSystem rtnl_link_info_data_type_systems[_NL_UNION_LINK_INFO_D
.types = rtnl_link_info_data_veth_types },
[NL_UNION_LINK_INFO_DATA_MACVLAN] = { .max = ELEMENTSOF(rtnl_link_info_data_macvlan_types) - 1,
.types = rtnl_link_info_data_macvlan_types },
+[NL_UNION_LINK_INFO_DATA_IPIP_TUNNEL] = { .max = ELEMENTSOF(rtnl_link_info_data_ipip_tunnel_types) - 1,
+ .types = rtnl_link_info_data_ipip_tunnel_types },
+[NL_UNION_LINK_INFO_DATA_IPIP6_TUNNEL] = { .max = ELEMENTSOF(rtnl_link_info_data_ipip6_tunnel_types) - 1,
+ .types = rtnl_link_info_data_ipip6_tunnel_types },
};
static const NLTypeSystemUnion rtnl_link_info_data_type_system_union = {
diff --git a/src/test/test-rtnl-manual.c b/src/test/test-rtnl-manual.c
index e76fb81..2a77bf7 100644
--- a/src/test/test-rtnl-manual.c
+++ b/src/test/test-rtnl-manual.c
@@ -84,10 +84,10 @@ static int test_tunnel_configure(sd_rtnl *rtnl) {
assert_se(sd_rtnl_message_new_link(rtnl, m, RTM_NEWLINK, 0) = 0);
assert_se(m);
-assert_se(sd_rtnl_message_append_string(m, IFLA_IFNAME, eth0) = 0);
+assert_se(sd_rtnl_message_append_string(m, IFLA_IFNAME, ipip-tunnel) = 0);
assert_se(sd_rtnl_message_append_u32(m, IFLA_MTU, 1234)= 0);
-assert_se(sd_rtnl_message_open_container(m, IFLA_LINKINFO) = 0);
+
Re: [systemd-devel] [PATCH] libsystemd-network: Support setting DHCP client initial delay
On Thu, Apr 3, 2014 at 9:28 AM, Patrik Flykt patrik.fl...@linux.intel.com wrote: Section 4.4.1 in RFC 2131 says that a DHCP client SHOULD wait a random time between one and ten seconds to desynchronize DHCP clients on startup. This is supported such that the application can optionally set an initial delay of approximately two and eight seconds or leave the initial value unset relying only on any machine specific randomness chosen for the main loop. The maximum delay of slightly more than eight seconds was chosen as it's more convenient to compute in addition to following RFC 2131 in spirit with a sensible margin towards the 17 years passed since the exact wording of the document. The two second initial delay variant was added to include a more neutral timeout hopefully good enough on a very busy network. As discussed on G+, there is no gain in setting the minimum above 0, all we would care about is the range between min and max. By default no initial delay is added, as the implementation is geared towards maximum speed. Thanks to Ted Lemon and to Jayson Vantul pointing out the reasons having DHCP initial delay support. Hm, so I'm definitely open to adding this sort of thing should it prove to be a problem in some scenario (it is a SHOULD in the RFC after all). However, I'm wondering if this really can be an issue. If the initial DISCOVER really does flood the network and the packets get dropped (or the answer does not get back in time), then we will just resend the DISCOVER message after a (randomized) hold-off, so the follow up DISCOVER(s) will no longer be in sync across the network. Even if the DHCP server takes some seconds to recover from the initial flood, we will just keep sending DISCOVER's at increasing intervals (with increasingly random delays), so even in the absolute worst case we will recover within tens of seconds (and we really don't care how slow this is in the worst case, as it should be extremely rare). Or am I missing something here? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Thu, Apr 3, 2014 at 12:27 AM, Greg KH gre...@linuxfoundation.org wrote:
If the kernel is started with debug, that's for the kernel to switch
into debug mode. We should rely on a namespace for our options, like
everything else (with the exception of quiet).
Just a quick note, we do in fact read a lot of kernel parameters in
addition to 'debug' and 'quiet'. What springs to mind is 'init=',
'root=', 'rootflags=', 'rootfs=', 'ro', 'rw', and 'ip=' (there are
probably more, but these are the ones I added myself). My
understanding was that reusing the kernel commandline options, in a
consistent way, is generally ok. But I may of course have gotten the
wrong end of the stick here.
Some people want to
only debug the kernel, not systemd, and the opposite as well so make
everyone happy.
I asked this before, but I guess this is the correct forum, so I'll
repeat myself:
My understanding is that currently we have systemd.log_level= which
affects only systemd, and loglevel= which affects only the kernel.
Moreover, debug currently implies systemd.log_level=debug
loglevel=debug (and as far as I know it will also increase the debug
output of other system-level processes, but these don't log much and
anyway not via the kernel, so let's ignore those).
This proposal is about making debug equivalent to loglevel=debug
and hence not affect systemd at all.
Is the rationale for this, simply a matter of preference, i.e., is the
claim simply that we believe most users would benefit more from the
'kernel only' compared to 'all low-level stuff' behavior? If that's
the case, I don't have an opinion on the patch, so I'll leave it to
those who do :)
Or is there actually a bug going on here? My impression from reading
related discussions was that systemd.log_level=debug loglevel=debug
triggers some bug (so in particular debug now triggers the bug). It
was not clear to me whether boot itself hangs, or if log-in becomes
impossible. Either way, I'm not able to reproduce it, so if anyone has
any more info on this, that would be useful.
Cheers,
Tom
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee8d5cd..291b18519388 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -416,7 +416,7 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
if (arg_show_status == _SHOW_STATUS_UNSET)
arg_show_status = SHOW_STATUS_AUTO;
-} else if (streq(key, debug) !value) {
+} else if (streq(key, systemd.debug) !value) {
/* Log to kmsg, the journal socket will fill up before the
* journal is started and tools running during that time
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen t...@jklm.no wrote: Is the rationale for this, simply a matter of preference, i.e., is the claim simply that we believe most users would benefit more from the 'kernel only' compared to 'all low-level stuff' behavior? If that's the case, I don't have an opinion on the patch, so I'll leave it to those who do :) Ok, I may care a bit, so I'll add my two cents: I suppose the general use-case here (i.e., not seen from the point of view of either a kernel or a systemd developer, but trying to imagine an end-user), is when 'boot is broken'. In that case, it makes a lot of sense to me to have a simple switch to give all the relevant debug info about the boot process. There are basically two things that may be broken: the kernel or systemd (or the initrd if that's !=systemd), and the end-user probably doesn't care much for the distinction. I'd therefore think it makes the most sense for debug to trigger debugging of all these things. I'm sure there are ways to see this to justify the opposite view though... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
Hi On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen t...@jklm.no wrote: Or is there actually a bug going on here? My impression from reading related discussions was that systemd.log_level=debug loglevel=debug triggers some bug (so in particular debug now triggers the bug). It was not clear to me whether boot itself hangs, or if log-in becomes impossible. Either way, I'm not able to reproduce it, so if anyone has any more info on this, that would be useful. There was a bug there which triggered the assertions. However, it has been fixed in -git for quite some time, so with -git systemd will _not_ log an unreasonable amount of information. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] LXC not working with systemd 209 or later
Hello, I have a number of LXC containers that have been working with systemd for some time. I have just tried to perform some upgrades, taking them from 204 to 212 (actually they are scripted rebuilds rather than upgrades). I have found that they do not work properly with any systemd versions 209 or later. I have read that 209 was a massive new release. Nothing else is changed except for the version of systemd and replacing a container's systemd 209, or later, with 208 fixes the problem and allows it to work correctly. I have read the release announcement for 209 and there is a lot there. I don't know which of the changes would be responsible for impacting the booting of a container. I would appreciate some guidance to help me investigate and resolve this problem. Until I do, I am stuck on 208. The Journal for 208 has more entries than the one for 209. 208 http://pastebin.com/XFtjyhcb 209 http://pastebin.com/q8S4fnrX I am running on ArchLinux 3.13.7-1-ARCH #1 SMP PREEMPT Mon Mar 24 20:06:08 CET 2014 x86_64 GNU/Linux Many thanks in advance. John ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] use systemd.debug on the kernel command line, not debug
'Twas brillig, and Greg KH at 03/04/14 02:02 did gyre and gimble:
+} else if (streq(key, systemd.debug) !value) {
Just as a small not to user typos, perhaps we should also check for
system.debug? It's a bit of a namespace crime, but it might avoid some
unneeded round trips requesting logs from users.
While it's now practically impossible for me to type the word system
_without_ putting a d on the end, many people triaging boot bugs at a
distro level will be advising users to edit their command prompt and
append debug systemd.debug and send in their logs which could easily
be misread by novice users, especially if they are totally unaware of
what systemd is (they may never even have heard the name before) - not
everyone who needs to collect debug information is a developer after all.
Just a small thought.
Cheers
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
Am 03.04.2014 11:36, schrieb David Herrmann: On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen t...@jklm.no wrote: Or is there actually a bug going on here? My impression from reading related discussions was that systemd.log_level=debug loglevel=debug triggers some bug (so in particular debug now triggers the bug). It was not clear to me whether boot itself hangs, or if log-in becomes impossible. Either way, I'm not able to reproduce it, so if anyone has any more info on this, that would be useful. There was a bug there which triggered the assertions. However, it has been fixed in -git for quite some time, so with -git systemd will _not_ log an unreasonable amount of information. Let me quote Linus from http://www.spinics.net/lists/kernel/msg1716484.html: No, we very much expose /proc/cmdline for a reason. System services are *supposed* to parse it, because it gives a unified way for people to pass in various flags. [...] And yes, that does include quiet and debug. Parsing them and doing something sane with them is not a bug, it's a feature. The original complaint was that the systemd debug output was so excessive that the system became unusable and the debug output unreadable. If what Hermann said above is true and that problem has been fixed, then the debug output is sane now and everything is fine. In that case, there is nothing to do. (In fact, the problem was already identified and fixed before this whole discussion started.) Is there anything else I am missing here? (Adding Linus and Greg to CC to see if there actually is something that I am missing.) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On 03.04.2014 00:27, Greg KH wrote: If the kernel is started with debug, that's for the kernel to switch into debug mode. We should rely on a namespace for our options, like everything else (with the exception of quiet). Some people want to only debug the kernel, not systemd, and the opposite as well so make everyone happy. Allow me to propose an alternative to 'debug' and 'systemd.debug'. When I debug boot issues and add 'debug' to the kernel command line, I do it by editing the command line through the boot loader and I might do it several times in a row, so I want the option to be short. I imagine that's a common workflow and is one of the reasons everybody wants to claim 'debug'. I suggest we return the 'debug' option to the kernel folk and add a new option 'dbg' with a string of single letter arguments. For example, 'dbg=ki' (k for kernel, i for init) would activate debugging in the kernel and the init system. Further, r could be added for initrd debugging and 'dbg' on it's own could default to 'dbg=kri'. The new option would be short, flexible, and extensible, 'debug' could still be used by kernel developers as they are used to, and it's trivial to implement. Wouldn't that make everyone happy? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
Am 12.02.2014 21:19, schrieb Lennart Poettering: On Wed, 12.02.14 20:05, Reindl Harald (h.rei...@thelounge.net) wrote: maybe systemd-upstream should consider slow down development and spend more energy in quality and stability Well, firstly, it's hardly your business how we spend our time looks like it's also not Linus business http://www.spinics.net/lists/kernel/msg1716484.html __ From: Linus Torvalds torvalds@ Date: Wed, 2 Apr 2014 16:13:27 -0700 It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem. 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] [PATCHv3] use systemd.debug on the kernel command line, not debug
'Twas brillig, and Hannes Reinecke at 03/04/14 07:52 did gyre and gimble: systemd.restore_state=0|1 Restore backlight/rfkill state at boot\n); + systemd.debug Enable debugging output\n); Line above the change line should have the ); removed... Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
'Twas brillig, and Florian Albrechtskirchinger at 03/04/14 11:53 did gyre and gimble: On 03.04.2014 00:27, Greg KH wrote: If the kernel is started with debug, that's for the kernel to switch into debug mode. We should rely on a namespace for our options, like everything else (with the exception of quiet). Some people want to only debug the kernel, not systemd, and the opposite as well so make everyone happy. Allow me to propose an alternative to 'debug' and 'systemd.debug'. When I debug boot issues and add 'debug' to the kernel command line, I do it by editing the command line through the boot loader and I might do it several times in a row, so I want the option to be short. I imagine that's a common workflow and is one of the reasons everybody wants to claim 'debug'. I suggest we return the 'debug' option to the kernel folk and add a new option 'dbg' with a string of single letter arguments. For example, 'dbg=ki' (k for kernel, i for init) would activate debugging in the kernel and the init system. Further, r could be added for initrd debugging and 'dbg' on it's own could default to 'dbg=kri'. I think this is a reasonable suggestion inline with the spirit of finding a compromise. You would first have to get agreement in principle from both sides that merging patches to support this would be OK. I would suggest that instead of an argument you make dbg a general purpose debug namesapce prefix. So, dbg.k or dbg.kernel works on the kernel side, and dbg.i or dbg.init works on the systemd side with dbg.r and dbg.rd works on the the dracut side. Wouldn't that make everyone happy? I doubt it. People would still disagree on what colour to make the argument text ;) Overall in this issue, I think one has to have a bit of pragmatism. I agree in principle that debug should be a generic term, but really there are bigger fights to fight and wasting energy on this battle really seems counter productive to the bigger picture. I think in this case, there is a little prior art to using debug on the kernel where dracut used a namespaced version rd.debug for it's debugging, so following that pattern systemd.debug seems logical enough. I know it would be nice to have one argument to turn all debugging on, but ultimately I feel there are bigger fish to fry than points of principle here. As far as I understand it none of the future plans really revolve around this, so I say just change it and move on with making things awesome and don't waste time on this point of principle. We can still know we're right without actually implementing it :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv3] use systemd.debug on the kernel command line, not debug
On 04/03/2014 01:02 PM, Colin Guthrie wrote: 'Twas brillig, and Hannes Reinecke at 03/04/14 07:52 did gyre and gimble: systemd.restore_state=0|1 Restore backlight/rfkill state at boot\n); + systemd.debug Enable debugging output\n); Line above the change line should have the ); removed... Indeed. Serves me right for not having tested them. Sorry for this. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: smooth transition from ipv4ll to dhcp address
Applied. Thanks!
Cheers,
Tom
On Wed, Apr 2, 2014 at 9:31 PM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
Currently when both ipv4ll and dhcp are enabled, ipv4ll
address (if one has been claimed) is removed when dhcp
address is aquired. This is not the best thing to do
since there might be clients unaware of the removal
trying to communicate.
This patch provides a smooth transition between ipv4ll
and dhcp. If ipv4ll address was claimed [1] before dhcp,
address is marked as deprecated. Deprecated address is still
a valid address and packets can be received on it but address
cannot be selected as a source address. If dhcp lease cannot
be extended, then ipv4ll address is marked as valid again.
[1] If there is no collision, claiming IPv4LL takes between 4 to
7 seconds.
---
TODO |1 -
man/systemd.network.xml |5 +-
src/libsystemd-network/sd-ipv4ll.c|6 +++
src/libsystemd/sd-rtnl/rtnl-message.c | 50 +
src/libsystemd/sd-rtnl/rtnl-types.c |2 +-
src/libsystemd/sd-rtnl/rtnl-types.h |1 +
src/libsystemd/sd-rtnl/test-rtnl.c|2 +
src/network/networkd-address.c| 96
+++--
src/network/networkd-link.c | 94
src/network/networkd.h|4 ++
src/systemd/sd-ipv4ll.h | 12 +++--
src/systemd/sd-rtnl.h |3 ++
12 files changed, 253 insertions(+), 23 deletions(-)
diff --git a/TODO b/TODO
index 2d56e81..4ff69ff 100644
--- a/TODO
+++ b/TODO
@@ -665,7 +665,6 @@ Features:
- add reduced [Link] support to .network files
- add IPv4LL tests (inspire by DHCP)
- add Scope= parsing option for [Network]
- - have smooth transition from LL to routable address, without
disconnecting clients.
* sd-network:
- make sure ipv4ll and dhcp clients can handle changing mac addresses
while running
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index f3b3b31..f49de17 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -192,8 +192,9 @@
termvarnameIPv4LL=/varname/term
listitem
paraA boolean. When true,
enables IPv4 link-local support.
-If literalDHCP=/literal
is also true, IPv4 link-local
-address will be removed upon
acquiring a DHCP lease.
+If literalDHCP=/literal
is also true, acquiring DHCP address
+will deprecate previously
acquired IPv4 link-local address or
+stop acquiring process if
there hasn't been one acquired before.
/para
/listitem
/varlistentry
diff --git a/src/libsystemd-network/sd-ipv4ll.c
b/src/libsystemd-network/sd-ipv4ll.c
index a201139..81fe85b 100644
--- a/src/libsystemd-network/sd-ipv4ll.c
+++ b/src/libsystemd-network/sd-ipv4ll.c
@@ -481,6 +481,12 @@ error:
return r;
}
+bool sd_ipv4ll_is_running(sd_ipv4ll *ll) {
+assert_return(ll, -EINVAL);
+
+return ll-state != IPV4LL_STATE_INIT;
+}
+
#define HASH_KEY
SD_ID128_MAKE(df,04,22,98,3f,ad,14,52,f9,87,2e,d1,9c,70,e2,f2)
int sd_ipv4ll_start (sd_ipv4ll *ll) {
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 4ace94c..e5854de 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -286,6 +286,19 @@ int sd_rtnl_message_new_addr(sd_rtnl *rtnl,
sd_rtnl_message **ret,
return 0;
}
+int sd_rtnl_message_new_addr_update(sd_rtnl *rtnl, sd_rtnl_message **ret,
+ int index, unsigned char family) {
+int r;
+
+r = sd_rtnl_message_new_addr(rtnl, ret, RTM_NEWADDR, index, family);
+if (r 0)
+return r;
+
+(*ret)-hdr-nlmsg_flags |= NLM_F_REPLACE;
+
+return 0;
+}
+
sd_rtnl_message *sd_rtnl_message_ref(sd_rtnl_message *m) {
if (m)
assert_se(REFCNT_INC(m-n_ref) = 2);
@@ -559,6 +572,24 @@ int sd_rtnl_message_append_ether_addr(sd_rtnl_message
*m, unsigned short type, c
return 0;
}
+int sd_rtnl_message_append_cache_info(sd_rtnl_message *m, unsigned short
type, const struct ifa_cacheinfo *info) {
+int r;
+
+assert_return(m, -EINVAL);
+assert_return(!m-sealed, -EPERM);
+assert_return(info, -EINVAL);
+
+r = message_attribute_has_type(m, type, NLA_CACHE_INFO);
+if (r 0)
+return r;
+
+
Re: [systemd-devel] [PATCH] networkd: drop routes when lease expires
Applied. Thanks!
Cheers,
Tom
On Tue, Apr 1, 2014 at 10:55 PM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
---
src/network/networkd-link.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 973755a..4e0fe0a 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -579,8 +579,11 @@ static int link_set_mtu(Link *link, uint32_t mtu) {
static int dhcp_lease_lost(Link *link) {
_cleanup_address_free_ Address *address = NULL;
+_cleanup_route_free_ Route *route_gw = NULL;
+_cleanup_route_free_ Route *route = NULL;
struct in_addr addr;
struct in_addr netmask;
+struct in_addr gateway;
unsigned prefixlen;
int r;
@@ -593,8 +596,27 @@ static int dhcp_lease_lost(Link *link) {
if (r = 0) {
sd_dhcp_lease_get_address(link-dhcp_lease, addr);
sd_dhcp_lease_get_netmask(link-dhcp_lease, netmask);
+sd_dhcp_lease_get_router(link-dhcp_lease, gateway);
prefixlen = net_netmask_to_prefixlen(netmask);
+r = route_new_dynamic(route_gw);
+if (r = 0) {
+route_gw-family = AF_INET;
+route_gw-dst_addr.in = gateway;
+route_gw-dst_prefixlen = 32;
+route_gw-scope = RT_SCOPE_LINK;
+
+route_drop(route_gw, link, route_drop_handler);
+}
+
+r = route_new_dynamic(route);
+if (r = 0) {
+route-family = AF_INET;
+route-in_addr.in = gateway;
+
+route_drop(route, link, route_drop_handler);
+}
+
address-family = AF_INET;
address-in_addr.in = addr;
address-prefixlen = prefixlen;
--
1.7.10.4
___
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 v4] use systemd.debug on the kernel command line, not debug
From: Greg KH gre...@linuxfoundation.org
If the kernel is started with debug, that's for the kernel to switch
into debug mode. We should rely on a namespace for our options, like
everything else (with the exception of quiet). Some people want to
only debug the kernel, not systemd, and the opposite as well so make
everyone happy.
Signed-off-by: Greg KH gre...@linuxfoundation.org
Signed-off-by: Hannes Reinecke h...@suse.de
---
man/kernel-command-line.xml | 4 ++--
src/core/main.c | 21 +++--
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index dbfec61..19da7a3 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -126,10 +126,10 @@
/varlistentry
varlistentry
-termvarnamedebug/varname/term
+termvarnamesystemd.debug/varname/term
listitem
paraParameter understood by
-both the kernel and the system
+the system
and service manager to control
console log verbosity. For
details, see
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee..2ca038c 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -374,6 +374,15 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
} else
log_warning(Environment variable name '%s' is not
valid. Ignoring., value);
+} else if (streq(key, systemd.debug) !value) {
+
+/* Log to kmsg, the journal socket will fill up before the
+ * journal is started and tools running during that time
+ * will block with every log message for for 60 seconds,
+ * before they give up. */
+log_set_max_level(LOG_DEBUG);
+log_set_target(detect_container(NULL) 0 ? LOG_TARGET_CONSOLE
: LOG_TARGET_KMSG);
+
} else if (!streq(key, systemd.restore_state)
!streq(key, systemd.gpt_auto)
(startswith(key, systemd.) || startswith(key,
rd.systemd.))) {
@@ -408,7 +417,8 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
systemd.default_standard_error=null|tty|syslog|syslog+console|kmsg|kmsg+console|journal|journal+console\n
Set
default log error output for services\n
systemd.setenv=ASSIGNMENTSet
an environment variable for all spawned processes\n
- systemd.restore_state=0|1
Restore backlight/rfkill state at boot\n);
+ systemd.restore_state=0|1
Restore backlight/rfkill state at boot\n
+ systemd.debug
Enable debugging output\n);
}
} else if (streq(key, quiet) !value) {
@@ -416,15 +426,6 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
if (arg_show_status == _SHOW_STATUS_UNSET)
arg_show_status = SHOW_STATUS_AUTO;
-} else if (streq(key, debug) !value) {
-
-/* Log to kmsg, the journal socket will fill up before the
- * journal is started and tools running during that time
- * will block with every log message for for 60 seconds,
- * before they give up. */
-log_set_max_level(LOG_DEBUG);
-log_set_target(detect_container(NULL) 0 ? LOG_TARGET_CONSOLE
: LOG_TARGET_KMSG);
-
} else if (!in_initrd() !value) {
unsigned i;
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-udevd seems to kill mount.ntfs started in rules scripts?
More of my porting from F16 to F20.
I have the following in /etc/udev/rules.d
ACTION==add, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
ACTION==remove, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
This run the ntb_mount_usb script as expected.
The script on the ADD action ends up doing:
mount -t ntfs -o uid=onelan,gid=onelan,noatime,noexec ${DEVNAME} /my-mount-
point
I have had the script do ps afx and systemd-cgls and see the
mount.ntfs process is running.
├─systemd-udevd.service
│ ├─ 409 /usr/lib/systemd/systemd-udevd
│ ├─14863 /usr/lib/systemd/systemd-udevd
│ ├─14867 /usr/lib/systemd/systemd-udevd
│ ├─14868 /usr/lib/systemd/systemd-udevd
│ ├─14869 /usr/lib/systemd/systemd-udevd
│ ├─14876 /bin/bash /usr/local/onelan/ntb/bin/ntb_mount_usb
│ ├─14886 /sbin/mount.ntfs /dev/sdb1 /data/data/external/USB_Memory_Stick -...
│ └─14890 systemd-cgls
But as soon as the script exits the mount.ntfs process is killed off by
something?
systemd-udevd maybe?
How should I be doing this?
Barry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv3] use systemd.debug on the kernel command line, not debug
On Thu, Apr 03, 2014 at 08:52:06AM +0200, Hannes Reinecke wrote: From: Greg KH gre...@linuxfoundation.org If the kernel is started with debug, that's for the kernel to switch into debug mode. We should rely on a namespace for our options, like everything else (with the exception of quiet). Some people want to only debug the kernel, not systemd, and the opposite as well so make everyone happy. Signed-off-by: Greg KH gre...@linuxfoundation.org NEVER add this line to a patch from someone who did not add it themselves, as it means something. Come on, you know better Hannes... greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug
On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: From: Greg KH gre...@linuxfoundation.org If the kernel is started with debug, that's for the kernel to switch into debug mode. We should rely on a namespace for our options, like everything else (with the exception of quiet). Some people want to only debug the kernel, not systemd, and the opposite as well so make everyone happy. Signed-off-by: Greg KH gre...@linuxfoundation.org Again, I never added this line :( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd seems to kill mount.ntfs started in rules scripts?
Am 03.04.2014 17:13, schrieb Barry Scott: But as soon as the script exits the mount.ntfs process is killed off by something? systemd-udevd maybe? From man udev's section on RUN: This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. Instead of using RUN, use SYSTEMD_WANTS to start a .mount or .service unit that does your job. In the remove case, use RUN+=/usr/bin/systemctl stop --no-block foo.mount or similar. (Not that I think this is a good idea at all: Your volume will be unmounted after it has been remove already - you are asking for data corruption.) 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] systemd-udevd seems to kill mount.ntfs started in rules scripts?
2014-04-03 17:13 GMT+02:00 Barry Scott barry.sc...@onelan.co.uk:
More of my porting from F16 to F20.
I have the following in /etc/udev/rules.d
ACTION==add, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
ACTION==remove, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
[..]
But as soon as the script exits the mount.ntfs process is killed off by
something? systemd-udevd maybe?
Long running process should not be run from udev rules. If udev is run
under systemd it will kill such processes after a timeout (I think it
was 120 secs)
How should I be doing this?
You could use something like udevil or udisks-glue.
If you want to do it via udev/systemd, use SYSTEMD_WANTS
ACTION==add, SUBSYSTEM==block, SUBSYSTEMS==usb, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=foo.service
Then write a foo.service which does the actual mount.
You can pass additional information to the service if you use a template
--
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-udevd seems to kill mount.ntfs started in rules scripts?
2014-04-03 17:27 GMT+02:00 Thomas Bächler tho...@archlinux.org: Am 03.04.2014 17:13, schrieb Barry Scott: But as soon as the script exits the mount.ntfs process is killed off by something? systemd-udevd maybe? From man udev's section on RUN: This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. Instead of using RUN, use SYSTEMD_WANTS to start a .mount or .service unit that does your job. In the remove case, use RUN+=/usr/bin/systemctl stop --no-block foo.mount or similar. I wouldn't do that. If you need that, simply bind the .service to the device via BindsTo. -- 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] LXC not working with systemd 209 or later
Hi, On Thu, 03 Apr 2014 11:25:27 +0100 John Lane syst...@jelmail.com wrote: Hello, I have a number of LXC containers that have been working with systemd for some time. I have just tried to perform some upgrades, taking them from 204 to 212 (actually they are scripted rebuilds rather than upgrades). You have to tell exactly what you are doing. Just calling lxc-archlinux in a loop? I have found that they do not work properly with any systemd versions 209 or later. I have read that 209 was a massive new release. What do you mean by do not work properly? Also, FWIW: Host: -hermes-11:37-cur_work$ systemctl --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR Container: [appuser@appserver1 ~]$ systemd-detect-virt lxc [appuser@appserver1 ~]$ uname -a Linux appserver1 3.13.8-1-ARCH #1 SMP PREEMPT Tue Apr 1 12:19:51 CEST 2014 x86_64 GNU/Linux [appuser@appserver1 ~]$ systemctl --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR [appuser@appserver1 ~]$ journalctl PRIORITY=3 -- Logs begin at Thu 2014-04-03 10:24:09 EDT, end at Thu 2014-04-03 11:27:50 EDT [appuser@appserver1 ~]$ journalctl PRIORITY=4 -- Logs begin at Thu 2014-04-03 10:24:09 EDT, end at Thu 2014-04-03 11:27:50 EDT Cheers, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-rtnl: broken test cases
On Thu, Apr 3, 2014 at 10:13 AM, Susant Sahani sus...@redhat.com wrote:
I am trying to fix the broken test cases which was working previously .
With the new refactorization and I tryied to fix them with the attached
paatch does not work . Not sure I am doing something wrong or sd-rtnl is
broken.
Thanks! I forgot to fix up this stuff. I had to fix up your patch as
seen below to make the tests pass again.
Feel free to ask if the reasoning behind any of the changes is unclear.
Cheers,
Tom
commit 9295158ea6b04cd7fc0ac6083d4a40c9b733821a
Author: Tom Gundersen t...@jklm.no
Date: Thu Apr 3 18:06:45 2014 +0200
sd-rtnl: fixup manual tests
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
index b7aa499..27b7d04 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -101,30 +101,19 @@ static const NLType
rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
#endif
};
-static const NLType
rtnl_link_info_data_ipip_tunnel_types[IFLA_IPTUN_MAX + 1] = {
-[IFLA_IPTUN_LINK] = { .type = NLA_U32 },
-[IFLA_IPTUN_LOCAL] = { .type = NLA_U32 },
-[IFLA_IPTUN_REMOTE] = { .type = NLA_U32 },
-[IFLA_IPTUN_TTL]= { .type = NLA_U8 },
-[IFLA_IPTUN_TOS]= { .type = NLA_U8 },
-[IFLA_IPTUN_PMTUDISC] = { .type = NLA_U8 },
-};
-
-static const NLType
rtnl_link_info_data_ipip6_tunnel_types[IFLA_IPTUN_MAX + 1] = {
-[IFLA_IPTUN_LINK] = { .type = NLA_U32 },
-[IFLA_IPTUN_LOCAL] = { .type = NLA_U32 },
-[IFLA_IPTUN_REMOTE] = { .type = NLA_U32 },
-[IFLA_IPTUN_TTL]= { .type = NLA_U8 },
-[IFLA_IPTUN_TOS]= { .type = NLA_U8 },
-[IFLA_IPTUN_PMTUDISC] = { .type = NLA_U8 },
-[IFLA_IPTUN_FLAGS] = { .type = NLA_U16 },
-[IFLA_IPTUN_PROTO] = { .type = NLA_U8 },
-/*
-[IFLA_IPTUN_6RD_PREFIX] = { .len = sizeof(struct in6_addr) },
-[IFLA_IPTUN_6RD_RELAY_PREFIX] = { .type = NLA_U32 },
-[IFLA_IPTUN_6RD_PREFIXLEN] = { .type = NLA_U16 },
+static const NLType rtnl_link_info_data_iptun_types[IFLA_IPTUN_MAX + 1] = {
+[IFLA_IPTUN_LINK]= { .type = NLA_U32 },
+[IFLA_IPTUN_LOCAL] = { .type = NLA_U32 },
+[IFLA_IPTUN_REMOTE] = { .type = NLA_U32 },
+[IFLA_IPTUN_TTL] = { .type = NLA_U8 },
+[IFLA_IPTUN_TOS] = { .type = NLA_U8 },
+[IFLA_IPTUN_PMTUDISC]= { .type = NLA_U8 },
+[IFLA_IPTUN_FLAGS] = { .type = NLA_U16 },
+[IFLA_IPTUN_PROTO] = { .type = NLA_U8 },
+[IFLA_IPTUN_6RD_PREFIX] = { .type = NLA_IN_ADDR },
+[IFLA_IPTUN_6RD_RELAY_PREFIX]= { .type = NLA_U32 },
+[IFLA_IPTUN_6RD_PREFIXLEN] = { .type = NLA_U16 },
[IFLA_IPTUN_6RD_RELAY_PREFIXLEN] = { .type = NLA_U16 },
-*/
};
typedef enum NLUnionLinkInfoData {
@@ -134,7 +123,7 @@ typedef enum NLUnionLinkInfoData {
NL_UNION_LINK_INFO_DATA_VETH,
NL_UNION_LINK_INFO_DATA_MACVLAN,
NL_UNION_LINK_INFO_DATA_IPIP_TUNNEL,
-NL_UNION_LINK_INFO_DATA_IPIP6_TUNNEL,
+NL_UNION_LINK_INFO_DATA_SIT_TUNNEL,
_NL_UNION_LINK_INFO_DATA_MAX,
_NL_UNION_LINK_INFO_DATA_INVALID = -1
} NLUnionLinkInfoData;
@@ -142,33 +131,34 @@ typedef enum NLUnionLinkInfoData {
const char *nl_union_link_info_data_to_string(NLUnionLinkInfoData p) _const_;
NLUnionLinkInfoData nl_union_link_info_data_from_string(const char *p) _pure_;
+/* these strings must match the .kind entries in the kernel */
static const char* const
nl_union_link_info_data_table[_NL_UNION_LINK_INFO_DATA_MAX] = {
[NL_UNION_LINK_INFO_DATA_BOND] = bond,
[NL_UNION_LINK_INFO_DATA_BRIDGE] = bridge,
[NL_UNION_LINK_INFO_DATA_VLAN] = vlan,
[NL_UNION_LINK_INFO_DATA_VETH] = veth,
[NL_UNION_LINK_INFO_DATA_MACVLAN] = macvlan,
-[NL_UNION_LINK_INFO_DATA_IPIP_TUNNEL] = ipip_tunnel,
-[NL_UNION_LINK_INFO_DATA_IPIP6_TUNNEL] = ipip6_tunnel,
+[NL_UNION_LINK_INFO_DATA_IPIP_TUNNEL] = ipip,
+[NL_UNION_LINK_INFO_DATA_SIT_TUNNEL] = sit,
};
DEFINE_STRING_TABLE_LOOKUP(nl_union_link_info_data, NLUnionLinkInfoData);
static const NLTypeSystem
rtnl_link_info_data_type_systems[_NL_UNION_LINK_INFO_DATA_MAX] = {
-[NL_UNION_LINK_INFO_DATA_BOND] ={ .max =
ELEMENTSOF(rtnl_link_info_data_bond_types) - 1,
- .types =
rtnl_link_info_data_bond_types },
-[NL_UNION_LINK_INFO_DATA_BRIDGE] = { .max =
ELEMENTSOF(rtnl_link_info_data_bridge_types) - 1,
- .types =
rtnl_link_info_data_bridge_types },
-[NL_UNION_LINK_INFO_DATA_VLAN] ={ .max =
ELEMENTSOF(rtnl_link_info_data_vlan_types) - 1,
-
[systemd-devel] fsck.vfat in /usr/sbin
Over at Gentoo, we have started installing fsck.vfat in /usr/sbin rather than /sbin. Don't ask me why; I don't maintain our dosfstools package. ^_^ This works ok with the fsck binary from util-linux since we have it configured to search in /usr/sbin via the --enable-fs-paths-extra configure option. It also searches $PATH as a fallback. However, systemd-fsck only looks in /sbin. Can we change this to match util-linux? I could probably hack together a patch if necessary. Gentoo bug report: https://bugs.gentoo.org/show_bug.cgi?id=506654 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd seems to kill mount.ntfs started in rules scripts?
2014-04-03 17:13 GMT+02:00 Barry Scott barry.sc...@onelan.co.uk: How should I be doing this? As I don't know if your script is meant to mount arbitrary removable drives, if you just want to mount a specific device, the simplest solution is to just add it to /etc/fstab. Use somehting like UUID or LABEL to identify it, and make sure to use auto + nofail. systemd will automatically mount the device -- 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
[systemd-devel] auditd.service and RefuseManualStop
Hi, Seems the upstream audit package includes this unit: [Unit] Description=Security Auditing Service DefaultDependencies=no After=local-fs.target Conflicts=shutdown.target Before=sysinit.target shutdown.target RefuseManualStop=yes [Service] ExecStart=/sbin/auditd -n ## To use augenrules, copy this file to /etc/systemd/system/auditd.service ## and uncomment the next line and delete/comment out the auditctl line. ## Then copy existing rules to /etc/audit/rules.d/ ## Not doing this last step can cause loss of existing rules #ExecStartPost=-/sbin/augenrules --load ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target Obviously, the RefuseManualStop here makes it impossible to stop this service when the package is uninstalled. Failed to issue method call: Operation refused, unit auditd.service may be requested by dependency only. Technically we can call systemctl stop *after* the unit file has disappeared (and possibly the daemon reloaded) and systemd will apparently tidy up the processes in the cgroup, but this seems wrong and dirty (a slightly less dirty approach would be to add a temporary dropin file to override RefuseManualStop, do a reload and then stop it, then remove the dropin file, but this also feels somewhat cumbersome). Alternatively we can do systemctl kill in this case prior to uninstall and that will work (systemctl kill does not respect RefuseManualStop). I also tried using systemctl stop with --force and --ignore-dependences but neither overrode the RefuseManualStop=yes directive (unsurprisingly) There are also problems restarting the daemon on upgrade but perhaps this should be generally avoided for audit? Anyway, just wanted to discuss the best approach here. Perhaps the upstream unit could be tweaked? Perhaps RefuseManualStop is overkill? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Proper use of the Session.Unlock method call
Hi, There are plenty people who have some kind of automatic session unlocking set up. Examples are: BT phone proximity, USB-drive being plugged in, etc. This is normally done via DBus `ScreenSaver.SetActive(false)` call, but this interface is not well-documented and, actually, it seems that this call is intended only for screen saver disabling and is not meant for session unlocking. This is exactly the way the guys from KDE decided to interpret the interface: they take any possibility to unlock a session without entering the user's password to be a bug.[1] When presented with a number of convincing arguments in favour of some kind of auto-unlock functionality, their answer now is “KDE session manager is going to respect logind's Lock/Unlock signals, so do your unlocking stuff through logind”. So, my question is this: what is the intended use of the `Session.Unlock` call, is it acceptable to employ this method to achieve this kind of auto-unlocking functionality? Here is how I see it: * User attaches his USB-drive. * Special udev invokes a helper. * The helper looks inside the drive and determines the owner. * Checks the owner configuration, performs the drive authentication. * If everything is fine, it enumerates all the sessions of this user (proper multi-session!) * and unlocks them. The issue here is that the `Session.Unlock` method is privileged, so I'm not sure yet how to go with that. In case of udev everything is OK as it's running as root, but this is not always the case. So, `pkexec`? Or maybe something completely different? [1]: https://bugs.kde.org/show_bug.cgi?id=314989 -- Кирилл Елагин ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LXC not working with systemd 209 or later
On 03/04/14 16:40, Leonid Isaev wrote: Hi, On Thu, 03 Apr 2014 11:25:27 +0100 John Lane syst...@jelmail.com wrote: Hello, I have a number of LXC containers that have been working with systemd for some time. I have just tried to perform some upgrades, taking them from 204 to 212 (actually they are scripted rebuilds rather than upgrades). You have to tell exactly what you are doing. Just calling lxc-archlinux in a loop? I am not sure what you mean by Just calling lxc-archlinux in a loop. I build a container using a script that is similar to, but not the lxc-archlinux template. It uses the Arch tools mkarchroot and pacman to install a collection of packages and then performs various setup tasks and creates appropriate configuration. Here is the LXC config produced: # Use autodev to be compatible with systemd lxc.autodev = 1 lxc.hook.autodev = /srv/lxc/testcontainer/autodev # hostname lxc.utsname = testcontainer # # network # if the network is not defined then the container # will be able to use the host's network lxc.network.type = veth #lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.hwaddr = DE:AD:BE:EF:CA:FE # restrict capabilities (security) see man capabilities lxc.cap.drop = sys_module #lxc.cap.drop = sys_admin # only explicit device access lxc.cgroup.devices.deny = a # # Memory Devices lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 1:7 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 1:9 rwm # # Terminals lxc.tty = 1 lxc.pts = 1024 lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 136:* rwm # # root filesystem lxc.rootfs = /srv/lxc/testcontainer # bind mount the host's pacman cache so container uses the same cache # rather than wasting time downloading packages already downloaded. lxc.mount.entry = /var/cache/pacman/pkg /srv/lxc/testcontainer/var/cache/pacman/pkg none rw,bind 0 0 This works fine with 208 but not with 209 so, I guess I am doing something that was correct for 208 but the goal-posts have been moved by 209. I have found that they do not work properly with any systemd versions 209 or later. I have read that 209 was a massive new release. What do you mean by do not work properly? What I find is that the login prompt never results in a prompt. I enter the correct user/password and it takes an age before redisplaying the login prompt. If apply 208 before starting the container then it works as expected. I can get into the container with lxc-attach. I'm a bit in the dark as the journal isn't showing me anything (or I don't know where to look). The thing I did notice was the 209 journal contained less than the 208 one which would suggest that 209 is not starting some services that 208 does (see linked pastes). I am looking into that but was hoping there might be an obvious pointer from the list - some things that have changed in 209 that might affect LXC and that I could perhaps look into more. Also, FWIW: Host: -hermes-11:37-cur_work$ systemctl --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR Container: [appuser@appserver1 ~]$ systemd-detect-virt lxc [appuser@appserver1 ~]$ uname -a Linux appserver1 3.13.8-1-ARCH #1 SMP PREEMPT Tue Apr 1 12:19:51 CEST 2014 x86_64 GNU/Linux [appuser@appserver1 ~]$ systemctl --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR [appuser@appserver1 ~]$ journalctl PRIORITY=3 -- Logs begin at Thu 2014-04-03 10:24:09 EDT, end at Thu 2014-04-03 11:27:50 EDT [appuser@appserver1 ~]$ journalctl PRIORITY=4 -- Logs begin at Thu 2014-04-03 10:24:09 EDT, end at Thu 2014-04-03 11:27:50 EDT Host: $ systemctl --version systemd 211 +PAM -LIBWRAP -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR Container: $ sudo lxc-attach -n testcontainer # systemd-detect-virt lxc # systemctl --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR # journalctl PRIORITY=3 -- Logs begin at Thu 2014-04-03 18:27:22 BST, end at Thu 2014-04-03 18:27:23 BST. -- # journalctl PRIORITY=4 -- Logs begin at Thu 2014-04-03 18:27:22 BST, end at Thu 2014-04-03 18:27:23 BST. -- That one had 212, but I get the same effect with 209, 210, 211 and 212. Cheers, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug
On Thu, Apr 03, 2014 at 08:18:26AM -0700, Greg KH wrote: On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: From: Greg KH gre...@linuxfoundation.org If the kernel is started with debug, that's for the kernel to switch into debug mode. We should rely on a namespace for our options, like everything else (with the exception of quiet). Some people want to only debug the kernel, not systemd, and the opposite as well so make everyone happy. Signed-off-by: Greg KH gre...@linuxfoundation.org Again, I never added this line :( That being said, your modification of my original patch looks correct, thanks for doing that. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power
While it is cool to be neat and clean all the time, this task can wait if we are on battery. --- units/systemd-tmpfiles-clean.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/units/systemd-tmpfiles-clean.service.in b/units/systemd-tmpfiles-clean.service.in index a5b5acb..06bb21f 100644 --- a/units/systemd-tmpfiles-clean.service.in +++ b/units/systemd-tmpfiles-clean.service.in @@ -16,6 +16,7 @@ ConditionDirectoryNotEmpty=|/usr/lib/tmpfiles.d ConditionDirectoryNotEmpty=|/usr/local/lib/tmpfiles.d ConditionDirectoryNotEmpty=|/etc/tmpfiles.d ConditionDirectoryNotEmpty=|/run/tmpfiles.d +ConditionACPower=true [Service] Type=oneshot -- 1.8.4.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LXC not working with systemd 209 or later
On Thu, 03 Apr 2014 18:53:48 +0100 John Lane syst...@jelmail.com wrote: On 03/04/14 16:40, Leonid Isaev wrote: Hi, On Thu, 03 Apr 2014 11:25:27 +0100 John Lane syst...@jelmail.com wrote: Hello, I have a number of LXC containers that have been working with systemd for some time. I have just tried to perform some upgrades, taking them from 204 to 212 (actually they are scripted rebuilds rather than upgrades). You have to tell exactly what you are doing. Just calling lxc-archlinux in a loop? I am not sure what you mean by Just calling lxc-archlinux in a loop. I build a container using a script that is similar to, but not the lxc-archlinux template. It uses the Arch tools mkarchroot and pacman to install a collection of packages and then performs various setup tasks and creates appropriate configuration. Here is the LXC config produced: # Use autodev to be compatible with systemd lxc.autodev = 1 lxc.hook.autodev = /srv/lxc/testcontainer/autodev # hostname lxc.utsname = testcontainer # # network # if the network is not defined then the container # will be able to use the host's network lxc.network.type = veth #lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.hwaddr = DE:AD:BE:EF:CA:FE # restrict capabilities (security) see man capabilities lxc.cap.drop = sys_module #lxc.cap.drop = sys_admin # only explicit device access lxc.cgroup.devices.deny = a # # Memory Devices lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 1:7 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 1:9 rwm # # Terminals lxc.tty = 1 lxc.pts = 1024 lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 136:* rwm # # root filesystem lxc.rootfs = /srv/lxc/testcontainer # bind mount the host's pacman cache so container uses the same cache # rather than wasting time downloading packages already downloaded. lxc.mount.entry = /var/cache/pacman/pkg /srv/lxc/testcontainer/var/cache/pacman/pkg none rw,bind 0 0 This works fine with 208 but not with 209 so, I guess I am doing something that was correct for 208 but the goal-posts have been moved by 209. Well, few obvious questions: 1. Have you tried booting and logging in the container with systemd-nspawn? Also, look at the --link-journal option for log debugging. 2. What does the autodev hook do and why do you need it? 3. How do you mount API filesystems into the container (your config doesn't have /sys and /proc entries)? Try putting the fstab generated by the archlinux template (because that one I tested and it works). 4. AFAIU, lxc-start calls /sbin/init (which points to systemd). I'm not sure if this will work, but try replacing container init with a script that calls systemd --log-target=console --log-level=debug... I have found that they do not work properly with any systemd versions 209 or later. I have read that 209 was a massive new release. What do you mean by do not work properly? What I find is that the login prompt never results in a prompt. I enter the correct user/password and it takes an age before redisplaying the login prompt. If apply 208 before starting the container then it works as expected. I can get into the container with lxc-attach. I'm a bit in the dark as the journal isn't showing me anything (or I don't know where to look). The thing I did notice was the 209 journal contained less than the 208 one which would suggest that 209 is not starting some services that 208 does (see linked pastes). I am looking into that but was hoping there might be an obvious pointer from the list - some things that have changed in 209 that might affect LXC and that I could perhaps look into more. I am not sure that this particular issue is systemd's fault because I just created a working container on a fresh/stock arch install (with community/lxc) using the template (to test the patches which I sent to lxc-devel). HTH, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] typo in tty-ask-password-agent.c ?
Hello, I think I may have found an error in systemd source, in tty-ask-password-agent.c, fuction wall_tty_block : r = get_ctty_devnr(0, devnr); if (r 0) return -r; shouldn’t be return -r be return r ? Regards, Simon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On 03.04.2014 15:48, Colin Guthrie wrote: 'Twas brillig, and Florian Albrechtskirchinger at 03/04/14 11:53 did gyre and gimble: I suggest we return the 'debug' option to the kernel folk and add a new option 'dbg' with a string of single letter arguments. For example, 'dbg=ki' (k for kernel, i for init) would activate debugging in the kernel and the init system. Further, r could be added for initrd debugging and 'dbg' on it's own could default to 'dbg=kri'. I think this is a reasonable suggestion inline with the spirit of finding a compromise. You would first have to get agreement in principle from both sides that merging patches to support this would be OK. Of course. I figured, I would start with the presumably easier side first ;) I would suggest that instead of an argument you make dbg a general purpose debug namesapce prefix. So, dbg.k or dbg.kernel works on the kernel side, and dbg.i or dbg.init works on the systemd side with dbg.r and dbg.rd works on the the dracut side. Style-wise I tend to agree, but I was going for brevity first and foremost. Wouldn't that make everyone happy? I doubt it. People would still disagree on what colour to make the argument text ;) Everyone is a big crowd, should have said more people, then maybe… Overall in this issue, I think one has to have a bit of pragmatism. I agree in principle that debug should be a generic term, but really there are bigger fights to fight and wasting energy on this battle really seems counter productive to the bigger picture. Agreed. I'm only mildly interested because of the fresh memory of typing 'debug rd.debug ...' repeatedly over a day. Would have been nice to have - not worth fighting anyone, though. I think in this case, there is a little prior art to using debug on the kernel where dracut used a namespaced version rd.debug for it's debugging, so following that pattern systemd.debug seems logical enough. It's definitely logical, but that's not my point at all. I know it would be nice to have one argument to turn all debugging on, but ultimately I feel there are bigger fish to fry than points of principle here. Both you and Tom Gundersen raised the point of assisting end-users with boot issues. 'dbg' (as suggested, shorthand for 'dbg=kri') is as concise and simple as it gets. As far as I understand it none of the future plans really revolve around this, so I say just change it and move on with making things awesome and don't waste time on this point of principle. I'm not going to push it, but if anyone (important) wants me to, I'm still willing to bring it up on LKML and write patches. Otherwise I'll move on. Good day. Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tty-ask-password-agent: return negative errno
Return negative errno in wall_tty_block(). get_ctty_devnr() already
returns a negative errno in case of failure, no need to negate it again.
Reported-by: Simon hw...@odai.homelinux.net
---
src/tty-ask-password-agent/tty-ask-password-agent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 1d067af..3203474 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -432,7 +432,7 @@ static int wall_tty_block(void) {
r = get_ctty_devnr(0, devnr);
if (r 0)
-return -r;
+return r;
if (asprintf(p, /run/systemd/ask-password-block/%u:%u,
major(devnr), minor(devnr)) 0)
return -ENOMEM;
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power
On Thu, Apr 03, 2014 at 03:42:08PM -0300, Cristian Rodríguez wrote: While it is cool to be neat and clean all the time, this task can wait if we are on battery. What if I connect my laptop to AC only when it sleeps? This will never run. I also don't think couple stats() and rm's have any measurable impact on battery. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power
On Thu, 3 Apr 2014 21:26:23 +0200 Tomasz Torcz to...@pipebreaker.pl wrote: On Thu, Apr 03, 2014 at 03:42:08PM -0300, Cristian Rodríguez wrote: While it is cool to be neat and clean all the time, this task can wait if we are on battery. What if I connect my laptop to AC only when it sleeps? This will never run. I agree that cleaning /tmp and /run is a low-priority task, but what if there are custom *.conf files in /etc/tmpfiles.d? AFAIU, these will not be run as well, but may be needed. And in the past, the difference in AC-powered and BAT-powered behavior in pm-utils and Upower has created _lots_ of confusion. I also don't think couple stats() and rm's have any measurable impact on battery. Stock tmpfiles.d clean routine applies only to tmpfs (by default) filesystems. On a battery-powered system, they are most likely clean due to small uptime. -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power
On Thu, Apr 3, 2014 at 11:51 PM, Leonid Isaev lis...@umail.iu.edu wrote: On a battery-powered system, they are most likely clean due to small uptime. I can't agree. Nowadays battery-powered systems tend to have huge uptimes due to being mostly suspended and rarely powered-off/rebooted. Anyway, I think Tomasz is right, impact here is hardly measurable, and those, who worry about those three rm's are free to override the unit file. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Thu, Apr 3, 2014 at 12:03 PM, Florian Albrechtskirchinger falbrechtskirchin...@gmail.com wrote: Both you and Tom Gundersen raised the point of assisting end-users with boot issues. 'dbg' (as suggested, shorthand for 'dbg=kri') is as concise and simple as it gets. -1 on this because it moves in the opposite direction of namespace clarity. systemd should not use both more verbose, namespaced versions of kernel options and abbreviated, non-namespaced versions of the same. At least do sd.dbg or similar; we already use sd as a namespace prefix elsewhere. With respect to the main change suggested in this thread, I'm a +1 for systemd.debug, especially because it's consistent with log level options. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power
-1 on adding ConditionACPower=true I frequently only plug in my laptop after putting it to sleep and then disconnect it before waking it up again. It'd be possible to run cleanup less frequently when on battery, but that would just delay the work and increase the impact (which is pretty negligible right now) when it happens. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add Mir to the list of session types
Add Mir to the list of session types. This is implemented for LightDM
in lp:~robert-ancell/lightdm/xdg-session-desktop [1].
[1]
https://code.launchpad.net/~robert-ancell/lightdm/xdg-session-desktop/+merge/214108
---
man/pam_systemd.xml | 5 +++--
man/sd_session_is_active.xml | 6 +++---
src/login/logind-session.c | 1 +
src/login/logind-session.h | 1 +
src/systemd/sd-login.h | 2 +-
5 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/man/pam_systemd.xml b/man/pam_systemd.xml
index 3022cdb..f973899 100644
--- a/man/pam_systemd.xml
+++ b/man/pam_systemd.xml
@@ -145,8 +145,9 @@
variable takes precedence. One of
literalunspecified/literal,
literaltty/literal,
-literalx11/literal or
-literalwayland/literal. See
+literalx11/literal,
+literalwayland/literal or
+literalmir/literal. See
citerefentryrefentrytitlesd_session_get_type/refentrytitlemanvolnum3/manvolnum/citerefentry
for details about the session
type./para/listitem
/varlistentry
diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml
index ddb2bee..8696f40 100644
--- a/man/sd_session_is_active.xml
+++ b/man/sd_session_is_active.xml
@@ -201,9 +201,9 @@
be used to determine the type of the session
identified by the specified session identifier. The
returned string is one of literalx11/literal,
-literalwayland/literal, literaltty/literal or
-literalunspecified/literal and needs to be freed
-with the libc
+literalwayland/literal, literalmir/literal,
+literaltty/literal or literalunspecified/literal and
+needs to be freed with the libc
citerefentryrefentrytitlefree/refentrytitlemanvolnum3/manvolnum/citerefentry
call after use./para
diff --git a/src/login/logind-session.c b/src/login/logind-session.c
index 4ca6b5d..b4fd349 100644
--- a/src/login/logind-session.c
+++ b/src/login/logind-session.c
@@ -1117,6 +1117,7 @@ static const char* const
session_type_table[_SESSION_TYPE_MAX] = {
[SESSION_TTY] = tty,
[SESSION_X11] = x11,
[SESSION_WAYLAND] = wayland,
+[SESSION_MIR] = mir,
};
DEFINE_STRING_TABLE_LOOKUP(session_type, SessionType);
diff --git a/src/login/logind-session.h b/src/login/logind-session.h
index c9af5eb..7ecc9f0 100644
--- a/src/login/logind-session.h
+++ b/src/login/logind-session.h
@@ -55,6 +55,7 @@ typedef enum SessionType {
SESSION_TTY,
SESSION_X11,
SESSION_WAYLAND,
+SESSION_MIR,
_SESSION_TYPE_MAX,
_SESSION_TYPE_INVALID = -1
} SessionType;
diff --git a/src/systemd/sd-login.h b/src/systemd/sd-login.h
index a4ca231..776733a 100644
--- a/src/systemd/sd-login.h
+++ b/src/systemd/sd-login.h
@@ -138,7 +138,7 @@ int sd_session_get_seat(const char *session, char **seat);
/* Determine the (PAM) service name this session was registered by. */
int sd_session_get_service(const char *session, char **service);
-/* Determine the type of this session, i.e. one of tty, x11 or
unspecified. */
+/* Determine the type of this session, i.e. one of tty, x11,
wayland, mir or unspecified. */
int sd_session_get_type(const char *session, char **type);
/* Determine the class of this session, i.e. one of user, greeter
or lock-screen. */
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv3] use systemd.debug on the kernel command line, not debug
On 04/03/2014 05:17 PM, Greg KH wrote: On Thu, Apr 03, 2014 at 08:52:06AM +0200, Hannes Reinecke wrote: From: Greg KH gre...@linuxfoundation.org If the kernel is started with debug, that's for the kernel to switch into debug mode. We should rely on a namespace for our options, like everything else (with the exception of quiet). Some people want to only debug the kernel, not systemd, and the opposite as well so make everyone happy. Signed-off-by: Greg KH gre...@linuxfoundation.org NEVER add this line to a patch from someone who did not add it themselves, as it means something. Come on, you know better Hannes... Sorry. Won't happen again. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
