Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container

2014-10-10 Thread Tom Gundersen 
On Fri, Oct 10, 2014 at 12:13 AM, James Lott ja...@lottspot.com wrote:
 Trying to start up an openvpn connection yields the following error:

 Thu Oct  9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun:
 Operation not permitted (errno=1)

 As requested by Lennart, attached you will find an strace of the openvpn
 process as it attempts to setup the connection. Please let me know if there's
 anything else I can provide to be helpful, and thanks again for the help!

Thanks. So to open /dev/net/tun you need either to have CAP_NET_ADMIN
(which depends on how you start nspawn, e.g. passing --network-veth
will give you this) or the tun device must be created persistently by
someone else and openvpn must have the right uid/gid to take control
of it.

Which setup are you using? Could you send the commandline you used to
invoke nspawn and the openvpn config file you are using? (And also the
same for whatever method you are using to create the persistent tun
netdev, if this is what you do).

Cheers,

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

Re: [systemd-devel] [question] networkd: Any support for hooks?

2014-10-10 Thread Tom Gundersen 
On Fri, Oct 10, 2014 at 3:38 AM, Cameron Norman
camerontnor...@gmail.com wrote:
 udev was indeed my first thought for ethtool, however how would the ethtool
 commands be hooked in on containers? Or is ethtool not relevant there?

In a container you'll either have devices that you have moved in from
the outside (these should be configured (by udev) before moving them
inside), or virtual devices that are created from inside the container
(which should be just created in the right way in the first place
without the need to change their settings after they appear), so in
general I would say that ethtool is not relevant in containers.

Cheers,

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

Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container

2014-10-10 Thread James Lott 
I am using a setup which retains the CAP_NET_ADMIN capability inside the 
container and allows openvpn to setup the device. No persistent devices are 
involved. Below, I have included a snippet from a shell session which shows 
the command used to invoke nspawn and then the openvpn command executed within 
the container which fails. 

[root@host01 ~]# systemctl status lanvpn | grep -A1 CGroup
   CGroup: /system.slice/lanvpn.service
   `-2169 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD 
/home/lanvpn
[root@host01 ~]# ssh lanvpn
Last login: Thu Oct  9 15:01:42 2014 from host01.lottspot.vpn
[root@lanvpn ~]# openvpn --config /etc/openvpn/vpngate.conf | tail -n2
Thu Oct  9 23:40:45 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun: 
Operation not permitted (errno=1)
Thu Oct  9 23:40:45 2014 Exiting due to fatal error

This same VPN configuration will successfully connect within the host 
environment.

[root@lanvpn ~]# exit
logout
Connection to lanvpn closed.
[root@host01 ~]# curl icanhazip.com
23.243.158.241
[root@host01 ~]# openvpn --daemon --config 
/home/lanvpn/etc/openvpn/vpngate.conf 
[root@host01 ~]# curl icanhazip.com
111.255.23.34

On Friday 10 October 2014 08:12:02 you wrote:
 On Fri, Oct 10, 2014 at 12:13 AM, James Lott ja...@lottspot.com wrote:
  Trying to start up an openvpn connection yields the following error:
  
  Thu Oct  9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun:
  Operation not permitted (errno=1)
  
  As requested by Lennart, attached you will find an strace of the openvpn
  process as it attempts to setup the connection. Please let me know if
  there's anything else I can provide to be helpful, and thanks again for
  the help!
 Thanks. So to open /dev/net/tun you need either to have CAP_NET_ADMIN
 (which depends on how you start nspawn, e.g. passing --network-veth
 will give you this) or the tun device must be created persistently by
 someone else and openvpn must have the right uid/gid to take control
 of it.
 
 Which setup are you using? Could you send the commandline you used to
 invoke nspawn and the openvpn config file you are using? (And also the
 same for whatever method you are using to create the persistent tun
 netdev, if this is what you do).
 
 Cheers,
 
 Tom

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

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

2014-10-10 Thread Jóhann B. Guðmundsson 


On 10/09/2014 11:35 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Oct 09, 2014 at 01:41:24AM +0200, Lennart Poettering wrote:

The ExecStart=/bin/true we just add because current systemd versions
refuse to run service units that have no ExecStart= set. It is on the
TODO list to allow services also when they have no ExecStart= but with
an ExecStop=, but this has not been implemented yet.

Isn't this it:

commit 96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1
Author: Lennart Poettering lenn...@poettering.net
Date:   Thu Aug 21 18:50:42 2014 +0200

 service: allow services of Type=oneshot that specify no ExecStart= commands
 
 This is useful for services that simply want to run something on

 shutdown, but not at bootup. They should only set ExecStop= but leave
 ExecStart= unset.

Confused,
Zbyszek


Yeah this was a weird commit and arguably this should be reverted unless 
Lennart explain why we need this in the first place.


Users should be able to install their units into the shutdown target and 
use existing ( After/Before ) ordering and an simply ExecStart to 
start unit(s) and have them executed in expected order during the 
shutdown sequence.


If they cannot something bigger is broken and need fixing.

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

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

2014-10-10 Thread Lennart Poettering 
On Fri, 10.10.14 05:57, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Thu, Oct 09, 2014 at 07:01:11PM +0530, Susant Sahani wrote:
  CID 1237543 (#1 of 1): Unchecked return value from library
  (CHECKED_RETURN)
  ---
   src/socket-proxy/socket-proxyd.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/src/socket-proxy/socket-proxyd.c 
  b/src/socket-proxy/socket-proxyd.c
  index ff2b24f..3041903 100644
  --- a/src/socket-proxy/socket-proxyd.c
  +++ b/src/socket-proxy/socket-proxyd.c
  @@ -125,7 +125,7 @@ static int connection_create_pipes(Connection *c, int 
  buffer[2], size_t *sz) {
   return -errno;
   }
   
  -fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
  +(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
   
   r = fcntl(buffer[0], F_GETPIPE_SZ);
   if (r  0) {
 For the sake of ML archives...
 
 this was pushed by David.

So, according to the archives David actually did post a message where
he said he merged it:

http://lists.freedesktop.org/archives/systemd-devel/2014-October/023822.html

There appears to be something really wrong with mail delivery on fdo
currently, a couple of messages never got delivered to me, and I
checked with Kay and Daniel and they didn't get them either, thoug
they show up in the archives.

Usually I pinged Tollef about things like this, but I am not entirely
sure who to ping these days...

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] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

2014-10-10 Thread Lennart Poettering 
On Thu, 09.10.14 20:28, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

 
 On 10/09/2014 02:26 PM, Lennart Poettering wrote:
 On Thu, 09.10.14 12:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
 
 On 10/08/2014 11:41 PM, Lennart Poettering wrote:
 TODO list to allow services also when they have no ExecStart= but with
 an ExecStop=, but this has not been implemented yet.
 What's the usecase for this behaviour?
 Precisely cases like the one described earlier in this thread: when
 you want to run something only at shutdown, properly ordered against
 other units that are also shut down.
 
 To me that already works just fine.
 
 [Unit]
 Description=My Shutdown Test
 Before=shutdown.target
 DefaultDependencies=no
 
 [Service]
 Type=oneshot
 ExecStart=/bin/systemd-cat -t SHUTDOWN /bin/echo Systemd shutdown test-2
 
 [Install]
 WantedBy=shutdown.target


It's not that easy. Note that in systemd we have the rule that if two
units are ordered against each other, and one is started and one is
stopped the stop will always be executed first, the start second,
regardless if the actual ordering is After= or Before=. Now, this
means unless you want to run your code only after some other service
shut down, everything is good. But if you want your code to run before
some other unit is shut down, then you cannot express this with a
service that is started at shutdown.

Thus the recommended way to implement services that are execute right
at the appropriate place in the shutdown order is to make it a service
that is a NOP at start, and only contains ExecStop=.

It's not particularly pretty, but not that bad either. And better than
the other options we saw...

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] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

2014-10-10 Thread Lennart Poettering 
On Fri, 10.10.14 01:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Thu, Oct 09, 2014 at 01:41:24AM +0200, Lennart Poettering wrote:
  The ExecStart=/bin/true we just add because current systemd versions
  refuse to run service units that have no ExecStart= set. It is on the
  TODO list to allow services also when they have no ExecStart= but with
  an ExecStop=, but this has not been implemented yet.
 Isn't this it:
 
 commit 96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1
 Author: Lennart Poettering lenn...@poettering.net
 Date:   Thu Aug 21 18:50:42 2014 +0200
 
 service: allow services of Type=oneshot that specify no ExecStart= 
 commands
 
 This is useful for services that simply want to run something on
 shutdown, but not at bootup. They should only set ExecStop= but leave
 ExecStart= unset.

Oh! Indeed! I am getting old! I start getting forgetful!

Lennart

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

[systemd-devel] [PATCH] kdbus: fix buffer overflow in bus_get_owner_kdbus() function

2014-10-10 Thread Lukasz Skalski 
Commit 710fc9779b7c (kdbus repo) introduced attaching items[]
instead of name[] in kdbus_cmd_conn_info struct. Commit 581fe6c81
(systemd repo) caught up with this change, but item size was not
properly calculated.

---
 src/libsystemd/sd-bus/bus-control.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/libsystemd/sd-bus/bus-control.c 
b/src/libsystemd/sd-bus/bus-control.c
index dbd94fc..7b106a3 100644
--- a/src/libsystemd/sd-bus/bus-control.c
+++ b/src/libsystemd/sd-bus/bus-control.c
@@ -398,7 +398,7 @@ static int bus_get_owner_kdbus(
 struct kdbus_cmd_conn_info *cmd;
 struct kdbus_conn_info *conn_info;
 struct kdbus_item *item;
-size_t size;
+size_t size, l;
 uint64_t m, id;
 int r;
 
@@ -410,13 +410,12 @@ static int bus_get_owner_kdbus(
 cmd = alloca0_align(size, 8);
 cmd-id = id;
 } else {
-size_t item_size = KDBUS_ITEM_HEADER_SIZE + strlen(name) + 1;
-
-size = offsetof(struct kdbus_cmd_conn_info, items) + item_size;
+l = strlen(name) + 1;
+size = offsetof(struct kdbus_cmd_conn_info, items) + 
KDBUS_ITEM_SIZE(l);
 cmd = alloca0_align(size, 8);
-cmd-items[0].size = item_size;
+cmd-items[0].size = KDBUS_ITEM_HEADER_SIZE + l;
 cmd-items[0].type = KDBUS_ITEM_NAME;
-strcpy(cmd-items[0].str, name);
+memcpy(cmd-items[0].str, name, l);
 }
 
 cmd-size = size;
-- 
1.9.3

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

Re: [systemd-devel] [PATCH] kdbus: fix buffer overflow in bus_get_owner_kdbus() function

2014-10-10 Thread Daniel Mack 
On 10/10/2014 12:29 PM, Lukasz Skalski wrote:
 Commit 710fc9779b7c (kdbus repo) introduced attaching items[]
 instead of name[] in kdbus_cmd_conn_info struct. Commit 581fe6c81
 (systemd repo) caught up with this change, but item size was not
 properly calculated.

Thanks for spotting this!

Applied.


 
 ---
  src/libsystemd/sd-bus/bus-control.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)
 
 diff --git a/src/libsystemd/sd-bus/bus-control.c 
 b/src/libsystemd/sd-bus/bus-control.c
 index dbd94fc..7b106a3 100644
 --- a/src/libsystemd/sd-bus/bus-control.c
 +++ b/src/libsystemd/sd-bus/bus-control.c
 @@ -398,7 +398,7 @@ static int bus_get_owner_kdbus(
  struct kdbus_cmd_conn_info *cmd;
  struct kdbus_conn_info *conn_info;
  struct kdbus_item *item;
 -size_t size;
 +size_t size, l;
  uint64_t m, id;
  int r;
  
 @@ -410,13 +410,12 @@ static int bus_get_owner_kdbus(
  cmd = alloca0_align(size, 8);
  cmd-id = id;
  } else {
 -size_t item_size = KDBUS_ITEM_HEADER_SIZE + strlen(name) + 1;
 -
 -size = offsetof(struct kdbus_cmd_conn_info, items) + 
 item_size;
 +l = strlen(name) + 1;
 +size = offsetof(struct kdbus_cmd_conn_info, items) + 
 KDBUS_ITEM_SIZE(l);
  cmd = alloca0_align(size, 8);
 -cmd-items[0].size = item_size;
 +cmd-items[0].size = KDBUS_ITEM_HEADER_SIZE + l;
  cmd-items[0].type = KDBUS_ITEM_NAME;
 -strcpy(cmd-items[0].str, name);
 +memcpy(cmd-items[0].str, name, l);
  }
  
  cmd-size = size;
 

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

Re: [systemd-devel] [RFC 19/25] mount-setup: skip relabelling when SELinux and SMACK not supported

2014-10-10 Thread Lennart Poettering 
On Thu, 18.09.14 15:24, Emil Renner Berthing (syst...@esmil.dk) wrote:

 This is also the only place where FTW_ACTIONRETVAL is used, so
 this makes systemd compile without SELinux or SMACK support
 when the standard library doesn't support this extension.

I applied this one. It's probably a good idea to avoid building this
bit of code if neither selinux nor SMACK are enabled. I generally
don't like littering code with #ifdefs so much, but for this one I
couldn't think of a better way.

 ---
  src/core/mount-setup.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
 index 23a66d2..8e91217 100644
 --- a/src/core/mount-setup.c
 +++ b/src/core/mount-setup.c
 @@ -351,6 +351,7 @@ int mount_cgroup_controllers(char ***join_controllers) {
  return 0;
  }
  
 +#if defined(HAVE_SELINUX) || defined(HAVE_SMACK)
  static int nftw_cb(
  const char *fpath,
  const struct stat *sb,
 @@ -372,6 +373,7 @@ static int nftw_cb(
  
  return FTW_CONTINUE;
  };
 +#endif
  
  int mount_setup(bool loaded_policy) {
  int r;
 @@ -384,6 +386,7 @@ int mount_setup(bool loaded_policy) {
  return r;
  }
  
 +#if defined(HAVE_SELINUX) || defined(HAVE_SMACK)
  /* Nodes in devtmpfs and /run need to be manually updated for
   * the appropriate labels, after mounting. The other virtual
   * API file systems like /sys and /proc do not need that, they
 @@ -402,6 +405,7 @@ int mount_setup(bool loaded_policy) {
  log_info(Relabelled /dev and /run in %s.,
   format_timespan(timespan, sizeof(timespan), 
 after_relabel - before_relabel, 0));
  }
 +#endif
  
  /* Create a few default symlinks, which are normally created
   * by udevd, but some scripts might need them before we start
 -- 
 2.1.0
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 


Lennart

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

Re: [systemd-devel] [RFC 21/25] make sure basename that doesn't alter it's argument

2014-10-10 Thread Lennart Poettering 
On Thu, 18.09.14 15:24, Emil Renner Berthing (syst...@esmil.dk) wrote:

What's the rationale here? The GNU version of basename() appears a lot
more useful than the POSIX. I am find with switching to the POSIX
version of libc calls if both have more or less equivalent
functionality or they are used very seldom only, but in this case the
GNU logic seems so much more useful and we use the call all the
time. 

 ---
  src/core/execute.c  |  6 +++---
  src/core/load-fragment.c|  2 +-
  src/core/manager.c  |  2 +-
  src/core/unit.c |  4 ++--
  src/delta/delta.c   | 14 +++---
  src/journal/journalctl.c|  2 +-
  src/locale/localectl.c  |  2 +-
  src/login/logind-inhibit.c  |  2 +-
  src/login/logind-seat.c |  2 +-
  src/login/logind-session.c  |  2 +-
  src/nspawn/nspawn.c |  2 +-
  src/shared/cgroup-show.c|  4 ++--
  src/shared/conf-files.c |  4 ++--
  src/shared/install.c| 14 +++---
  src/shared/path-util.c  |  8 
  src/shared/path-util.h  |  5 +
  src/shared/util.c   |  4 ++--
  src/shared/utmp-wtmp.c  |  2 +-
  src/systemctl/systemctl.c   | 12 ++--
  src/sysv-generator/sysv-generator.c |  4 ++--
  src/test/test-install.c | 18 +-
  src/test/test-path-util.c   |  8 
  22 files changed, 68 insertions(+), 55 deletions(-)
 
 diff --git a/src/core/execute.c b/src/core/execute.c
 index e73eb8e..77724ce 100644
 --- a/src/core/execute.c
 +++ b/src/core/execute.c
 @@ -912,7 +912,7 @@ static void rename_process_from_path(const char *path) {
  /* This resulting string must fit in 10 chars (i.e. the length
   * of /sbin/init) to look pretty in /bin/ps */
  
 -p = basename(path);
 +p = path_basename(path);
  if (isempty(p)) {
  rename_process((...));
  return;
 @@ -1331,13 +1331,13 @@ static int exec_child(ExecCommand *command,
  return err;
  }
  
 -err = setup_output(context, STDOUT_FILENO, socket_fd, 
 basename(command-path), params-unit_id, params-apply_tty_stdin);
 +err = setup_output(context, STDOUT_FILENO, socket_fd, 
 path_basename(command-path), params-unit_id, params-apply_tty_stdin);
  if (err  0) {
  *error = EXIT_STDOUT;
  return err;
  }
  
 -err = setup_output(context, STDERR_FILENO, socket_fd, 
 basename(command-path), params-unit_id, params-apply_tty_stdin);
 +err = setup_output(context, STDERR_FILENO, socket_fd, 
 path_basename(command-path), params-unit_id, params-apply_tty_stdin);
  if (err  0) {
  *error = EXIT_STDERR;
  return err;
 diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
 index 0620882..61db112 100644
 --- a/src/core/load-fragment.c
 +++ b/src/core/load-fragment.c
 @@ -3322,7 +3322,7 @@ static int open_follow(char **filename, FILE **_f, Set 
 *names, char **_final) {
  /* Add the file name we are currently looking at to
   * the names of this unit, but only if it is a valid
   * unit name. */
 -name = basename(*filename);
 +name = path_basename(*filename);
  
  if (unit_name_is_valid(name, TEMPLATE_VALID)) {
  
 diff --git a/src/core/manager.c b/src/core/manager.c
 index 88d660d..22a9c89 100644
 --- a/src/core/manager.c
 +++ b/src/core/manager.c
 @@ -1217,7 +1217,7 @@ int manager_load_unit_prepare(
  return sd_bus_error_setf(e, SD_BUS_ERROR_INVALID_ARGS, Path 
 %s is not absolute., path);
  
  if (!name)
 -name = basename(path);
 +name = path_basename(path);
  
  t = unit_name_to_type(name);
  
 diff --git a/src/core/unit.c b/src/core/unit.c
 index def5c36..c14859e 100644
 --- a/src/core/unit.c
 +++ b/src/core/unit.c
 @@ -2170,7 +2170,7 @@ static const char *resolve_template(Unit *u, const char 
 *name, const char*path,
  assert(p);
  
  if (!name)
 -name = basename(path);
 +name = path_basename(path);
  
  if (!unit_name_is_template(name)) {
  *p = NULL;
 @@ -2941,7 +2941,7 @@ UnitFileState unit_get_unit_file_state(Unit *u) {
  if (u-unit_file_state  0  u-fragment_path)
  u-unit_file_state = unit_file_get_state(
  u-manager-running_as == SYSTEMD_SYSTEM ? 
 UNIT_FILE_SYSTEM : UNIT_FILE_USER,
 -NULL, basename(u-fragment_path));
 +NULL, path_basename(u-fragment_path));
  
  return u-unit_file_state;
  }
 diff --git a/src/delta/delta.c b/src/delta/delta.c
 index 91f8592..cb049e8 100644
 ---

Re: [systemd-devel] [RFC 00/25] Compile against the musl libc

2014-10-10 Thread Lennart Poettering 
On Thu, 18.09.14 21:21, Emil Renner Berthing (syst...@esmil.dk) wrote:

 Hi Tom,
 
 On 18 September 2014 18:29, Tom Gundersen t...@jklm.no wrote:
  In general, I don't think we should add patches for the sole purpose
  of non-glibc compatibility. You would in most cases be much better
  served by adding the missing functionality to your libc, rather than
  to each of the project requiring the functionality.
 
 Thank you for looking through these. The problem is that musl is aiming
 at making a lean and efficient posix libc, not a glibc clone. So stuff
 like parse_printf_format and canonicalize_file_name is not a fix, but
 unnecessary bloat. So it seems I'm stuck between a rock and a hard place.

Well, bloat is a misleading term here. canonicalize_file_name() you
can implement via a macro hence costs pretty much nothing. And
parse_printf_format() is genuinely useful, that's why we make use of
it. It's also something that can only be reasonably implemented at the
same place your printf() implementaton is maintained, since it needs
to stay compatible with that.

In general I think it's a very weird approach to have a non-useful
libc and then claim things would be less bloated because every user of
a variety of useful GNU APIs is supposed to reimplement everything
from scracth, so that we have a multitude of different, crappy
implementations in a variety of projects, instead of a single one in
the libc. Your overall footprint will be larger. 

Also, the entire dance around POSIX is awesome and what we thrive
for, and GNU is bad is just nonsense. It shows that your libc was
created for religious reasons, not for practical ones. If you want to
create something useful, create something useful, but don't cut off
useful functionality people use just because it was introduced by GNU,
not by POSIX. The POSIX API alone does not cover many many things
anyway. POSIX doesn't know epoll, pivot_root(), memfd, fanotify,
inotify and all those other Linux-specific syscalls, that solve real
problems. Don't tell me musl refuses to support those too? Or is Linux
good, just GNU bad, hence Linux extensions are well supported, just
not the ones from GNU?

We will not take part in this game. Yes, we tend to gravitate more
towards POSIX interfaces, if both a GNU and a POSIX version exists and
both are equivalent in their functionality. But also: we will make use
of GNU extensions and of Linux extensions if they are useful. And
since these ultimately are part of the Linux API, that is the right
thing to do.

Anyway, regardless what the goal of the patches people sent us are and
whether we sympasize with them, we'll always merge the ones that make
sense to us. We are not married to GNU, but we are married to the idea
that we will rely on good APIs exposed in the generally accepted Linux
API which is the one glibc exposes.

Hope that makes sense,

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 service for kinit

2014-10-10 Thread Lennart Poettering 
On Wed, 17.09.14 12:44, Günther J. Niederwimmer (g...@gjn.priv.at) wrote:

 Hello,
 
 I have a problem with kinit (krb5)
 before on my old system this works with a cron file
 
 @reboot root /usr/bin/sleep 120  /usr/bin/kinit -k host/.
 
 now with systemd I can't say why, the extra characters don't work
 @reboot
 
 Is there a way to configure this with systemd ?

cron is an independent project. Please ask the cron project for
help. systemd does not read crontabs and is not involved in executing
cron's commands.

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] fstab-generator: Honor mount.usr*= on kernel command line

2014-10-10 Thread Tobias Hunger 
Thanks to everybody for taking the time to review this (and to explain
git over email to me!).

I know all of you -- and especially Lennart -- are pressed for time
with that LibreOffice merge:-)

Best Regards,
Tobias

On Fri, Oct 10, 2014 at 12:57 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 09.10.14 21:37, Tobias Hunger (tobias.hun...@gmail.com) wrote:

 This allows to configure boot loader entries for systems where the
 root and usr filesystems are in different subvolumes (or even on
 different drives).

 Thanks! Applied!

 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] [question] networkd: Any support for hooks?

2014-10-10 Thread Zbigniew Jędrzejewski-Szmek 
On Thu, Oct 09, 2014 at 07:24:07AM +0200, Marcel Holtmann wrote:
 For the wpa_supplicant, we are going to fix that one with a proper daemon 
 soon.
Interesting. Can you shed some light on this?

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

[systemd-devel] [PATCH] bus-proxyd: fix compatibility with old dbus-1

2014-10-10 Thread Lukasz Skalski 
'ListQueuedOwners' method should return 'NameHasNoOwner' error
if chosen name is not available on bus.

---
 src/bus-proxyd/bus-proxyd.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index 4f44825..52498f3 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -733,6 +733,7 @@ static int process_driver(sd_bus *a, sd_bus *b, 
sd_bus_message *m) {
 struct kdbus_cmd_free cmd_free;
 struct kdbus_cmd_name *name;
 _cleanup_strv_free_ char **owners = NULL;
+_cleanup_bus_error_free_ sd_bus_error error = 
SD_BUS_ERROR_NULL;
 char *arg0;
 int err = 0;
 
@@ -743,6 +744,14 @@ static int process_driver(sd_bus *a, sd_bus *b, 
sd_bus_message *m) {
 if (!service_name_is_valid(arg0))
 return synthetic_reply_method_errno(m, -EINVAL, NULL);
 
+r = sd_bus_get_owner(a, arg0, 0, NULL);
+if (r == -ESRCH || r == -ENXIO) {
+sd_bus_error_setf(error, 
SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get owners of name '%s': no such 
name., arg0);
+return synthetic_reply_method_errno(m, r, error);
+}
+if (r  0)
+return synthetic_reply_method_errno(m, r, NULL);
+
 cmd.flags = KDBUS_NAME_LIST_QUEUED;
 r = ioctl(a-input_fd, KDBUS_CMD_NAME_LIST, cmd);
 if (r  0)
-- 
1.9.3

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

Re: [systemd-devel] Should user mode linux register with machined?

2014-10-10 Thread Lennart Poettering 
On Wed, 17.09.14 10:24, Richard Weinberger (richard.weinber...@gmail.com) wrote:

 On Wed, Sep 17, 2014 at 1:09 AM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Tue, Sep 16, 2014 at 05:31:05PM +0200, Thomas Meyer wrote:
  Hi,
 
  I wrote a small patch for user-mode linux to register with machined by
  calling CreateMachine. Is this a good idea to do so?
  Yes, this sounds useful. After all is just another mechanism of
  virtualization, and in this case can be treated similarly to
  containers and vms.
 
 I still want a sane reason and a usecase for that.
 Can someone please educate me? :-)
 
 Please note that also qemu does not register itself to systemd.
 libvirt does. I think going down this path makes also sense for UML
 as libvirt has a UML driver too.
 qemu and the UML ELF image are the low level building blocks.
 Managers like libvirt should register the virtual machines created by
 LXC, UML, qemu, etc.. to systemd.

It's a bit more complex. While UML, qemu, kvm, currently don't, LXC,
systemd-nspawn and libvirt-lxc all do talk directly to machined. (Note
that LXC and libvirt-lxc are separate codebases, the latter is *not* a
wrapper around the former).

So, dunno, it really is up to how you intend UML to be used. If UML
shall be nice and useful without libvirt, then it's worth doing the
registration natively, but it's also OK to just leave this to libvirt,
if that's your primary envisioned usecase...

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] Should user mode linux register with machined?

2014-10-10 Thread Richard Weinberger 
Lennart,

Am 10.10.2014 um 18:44 schrieb Lennart Poettering:
 It's a bit more complex. While UML, qemu, kvm, currently don't, LXC,
 systemd-nspawn and libvirt-lxc all do talk directly to machined. (Note
 that LXC and libvirt-lxc are separate codebases, the latter is *not* a
 wrapper around the former).
 
 So, dunno, it really is up to how you intend UML to be used. If UML
 shall be nice and useful without libvirt, then it's worth doing the
 registration natively, but it's also OK to just leave this to libvirt,
 if that's your primary envisioned usecase...

What is the benefit of this registration?
I boot all day long UML and qemu-kvm VMs without registering them to systemd,
so I don't really know what I'm missing. :-)
But if there is a nice use case I'll happily add the registration to UML.

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

Re: [systemd-devel] Bug? /dev/disk/by-path symlinks disappear for iSCSI targets

2014-10-10 Thread Lee Duncan 
Ping?

I will submit a patch that fixes this regression for SCSI, but I suspect
other transports will have problems, too, since the by-path links will
now be missing.


On 10/07/2014, I wrote:
 Date: Tue, 07 Oct 2014 21:21:11 +0500
 From: Lee Duncan ldun...@suse.com
 To: systemd-devel@lists.freedesktop.org
 Subject: [systemd-devel] Bug? /dev/disk/by-path symlinks disappear for
   iSCSI   targets
 Message-ID: 543412f7.1060...@suse.com
 Content-Type: text/plain; charset=utf-8
 
 Hi:
 
 I am debugging a problem where the symlinks in /dev/disk/by-path
 disappeared for iSCSI target devices.
 
 It looks like it's from systemd/udev commit
 e98bbfd2074e2b1079b7059341eac25741baf319
 
  udev: path_id - suppress ID_PATH for devices with an unknown parent device 
 type
 
 I believe the worry was that if you allowed pathnames based on a
 parent bus that did not supply unique IDs, then you could end up with
 duplicate paths, since this references a bug:
 
 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1321816
 
 But, looking at the code, this change seems to have assumed SCSI was
 not a supported parent. I am not aware of any cases where SCSI has
 given duplicate names to devices
 
 Before submitting a patch to fix this for SCSI, I wanted to make sure
 I understood the intent correctly.
 
 Thank you for your help.
 

-- 
Lee Duncan

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

[systemd-devel] Request for clarification of use implementation of new (systemd = v214) network-pre.target

2014-10-10 Thread PGNd 
systemd v214 introduced the new network-related target, network-pre.target.

It cleanly provides a convenient and timley pre-network state trigger for 
Before= use in unit ordering.

As originally conceived, and currently implemented, it's of particular use for 
secure, early init of firewalls,


http://lists.freedesktop.org/archives/systemd-commits/2014-June/006332.html
commit a4a878d04045b46fa9783664e3643a890b356790
Author: Lennart Poettering lennart at poettering.net
Date:   Wed Jun 11 11:33:02 2014 +0200

units: introduce network-pre.target as place to hook in 
firewalls
...

This target, specifically, started interest/discussion in its correct use for 
shorewall

SW 4.6.4+' systemd service files' Before=/After= dependency on 
'network.target' -- should that be 'network-pre.target' and 
'network-online.target'?
http://comments.gmane.org/gmane.comp.security.shorewall/31879

It was pointed out later in that same thread,

http://permalink.gmane.org/gmane.comp.security.shorewall/31885

that not all distros have currently, nor in the immediate future, plans for 
up-to-date systemd.

openSUSE, e.g., has available, /or will use, v210 for openSUSE versions 13.1, 
13.2  Factory.

Reviewing the commit implementing network-pre.target, above, it looks 
relatively simple, and was suggested in #systemd to apply the change as a patch 
to existing systemd implementation.

To that end, I raised a request at the distro to do so,

https://bugzilla.suse.com/show_bug.cgi?id=900505
Bug 900505 - Base:System/systemd: Bug Request to add upstream's patch 
to include v214's new 'network-pre.target' for early/secure pre-network 
dependency activation of firewall services

Atm in that discussion, there's some confusion.  If there's any possibilty of 
participation from here at/about that bug to help clarify what can/should be 
done, it'd be appreciated.

At the very least, it'd be helpful to get some specific clarification here re:

(1) Can the aforementioned patch be safely/cleanly applied to a v210 tree?
(2) Is systemd-networkd service required to be active to correctly 
support/detect network state on system startup, and properly trigger 
network-pre.target at the right time?  It does not appear to be required for 
either network.target, or network-online.target ...
(3) This

https://wiki.archlinux.org/index.php/systemd-networkd

but not these


http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html 
http://www.freedesktop.org/software/systemd/man/systemd.network.html

explicitly states that 

 ...
This service (systemd-networkd) can run alongside your usual network 
management tool
... 

IIUC, that suggests that systemd-networkd can be started in a detect-only mode, 
e.g., if no .network or .netdev are specified, leaving network  interface 
startup to ohter mechanisms (not theat I see the benefit in doing so; 
nonetheless ...).  Is that correct?

Thanks.

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

Re: [systemd-devel] Request for clarification of use implementation of new (systemd = v214) network-pre.target

2014-10-10 Thread Tom Gundersen 
On Fri, Oct 10, 2014 at 7:14 PM, PGNd d...@pgnd.us wrote:
 (2) [systemd-networkd] does not appear to be required for either 
 network.target, or network-online.target ...

Correct.

The point of network-pre.target is that whatever network manager you
are using must be ordered After= it, so that your firewall setup can
be ordered Before= it and be set up correctly before any network
connectivity is established. This applies the same to NetworkManager,
systemd-networkd, or anything else.

 (3) This [...] suggests that systemd-networkd can be started in a detect-only 
 mode, e.g., if no .network or .netdev are specified, leaving network  
 interface startup to ohter mechanisms (not theat I see the benefit in doing 
 so; nonetheless ...).  Is that correct?

Yes.

Cheers,

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

Re: [systemd-devel] Request for clarification of use implementation of new (systemd = v214) network-pre.target

2014-10-10 Thread Andrei Borzenkov 
В Fri, 10 Oct 2014 10:14:47 -0700
PGNd d...@pgnd.us пишет:

 systemd v214 introduced the new network-related target, network-pre.target.
 
 It cleanly provides a convenient and timley pre-network state trigger for 
 Before= use in unit ordering.
 
 As originally conceived, and currently implemented, it's of particular use 
 for secure, early init of firewalls,
 
   
 http://lists.freedesktop.org/archives/systemd-commits/2014-June/006332.html
   commit a4a878d04045b46fa9783664e3643a890b356790
   Author: Lennart Poettering lennart at poettering.net
   Date:   Wed Jun 11 11:33:02 2014 +0200
 
   units: introduce network-pre.target as place to hook in 
 firewalls
   ...
 
 This target, specifically, started interest/discussion in its correct use for 
 shorewall
 
   SW 4.6.4+' systemd service files' Before=/After= dependency on 
 'network.target' -- should that be 'network-pre.target' and 
 'network-online.target'?
   http://comments.gmane.org/gmane.comp.security.shorewall/31879
 
 It was pointed out later in that same thread,
 
   http://permalink.gmane.org/gmane.comp.security.shorewall/31885
 
 that not all distros have currently, nor in the immediate future, plans for 
 up-to-date systemd.
 
 openSUSE, e.g., has available, /or will use, v210 for openSUSE versions 
 13.1, 13.2  Factory.
 
 Reviewing the commit implementing network-pre.target, above, it looks 
 relatively simple, and was suggested in #systemd to apply the change as a 
 patch to existing systemd implementation.
 
 To that end, I raised a request at the distro to do so,
 
   https://bugzilla.suse.com/show_bug.cgi?id=900505
   Bug 900505 - Base:System/systemd: Bug Request to add upstream's patch 
 to include v214's new 'network-pre.target' for early/secure pre-network 
 dependency activation of firewall services
 
 Atm in that discussion, there's some confusion.  If there's any possibilty of 
 participation from here at/about that bug to help clarify what can/should be 
 done, it'd be appreciated.
 
 At the very least, it'd be helpful to get some specific clarification here re:
 
 (1) Can the aforementioned patch be safely/cleanly applied to a v210 tree?

I'd say yes, all that it does is adding couple of dependencies to
existing targets. Actually, for openSUSE the only relevant one is
network.target

Note that commit has some seemingly unrelated changes.

 (2) Is systemd-networkd service required to be active to correctly 
 support/detect network state on system startup, and properly trigger 
 network-pre.target at the right time?  It does not appear to be required for 
 either network.target, or network-online.target ...

No. As explained in accompanying documentation patch,
network-pre.target must be pulled in by consumer - if service wants to
be started before network it is expected to say so by using
Wants=network-pre.target, Before=network-pre.target.

Of course, any actual implementation of networking (like
systemd-networkd.service) must also be ordered *after*
network-pre.target. Above commit alone does not do it for openSUSE
specific services (like wicked).

 (3) This
 
   https://wiki.archlinux.org/index.php/systemd-networkd
 
 but not these
 
   
 http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html 
   http://www.freedesktop.org/software/systemd/man/systemd.network.html
 
 explicitly states that 
 
...
   This service (systemd-networkd) can run alongside your usual network 
 management tool
   ... 
 
 IIUC, that suggests that systemd-networkd can be started in a detect-only 
 mode, e.g., if no .network or .netdev are specified, leaving network  
 interface startup to ohter mechanisms (not theat I see the benefit in doing 
 so; nonetheless ...).  Is that correct?
 

May be, but this is irrelevant.

 Thanks.
 
 ___
 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] [question] networkd: Any support for hooks?

2014-10-10 Thread Dale R. Worley 
 From: Tom Gundersen t...@jklm.no

 What we do, however, is to expose the configuration state using the
 sd-network C API, which external programs can watch and react on (see
 how timesyncd and resolved currently works).

In a situation where one wants to do what a hook does, having a
separate daemon program that watches for an event and then invokes the
hook when the event happens is not a good solution -- it replaces the
hook with an entire daemon.

I am not experienced, but from what little I know about systemd, the
natural way would seem to be to write a new unit file with the
appropriate dependencies.  The event that should call the hook is when
some unit finishes starting, and then the new unit would then be
started.  The new unit's ExecStart command would be the desired
invocation of the hook.

Does that make sense?  If it does, it might be useful to write a
beginner's guide on how to construct and insert such a unit into a
system.

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

Re: [systemd-devel] [PATCH] bus-proxyd: fix compatibility with old dbus-1

2014-10-10 Thread Daniel Mack 
On 10/10/2014 04:42 PM, Lukasz Skalski wrote:
 'ListQueuedOwners' method should return 'NameHasNoOwner' error
 if chosen name is not available on bus.

Applied, thanks!

 
 ---
  src/bus-proxyd/bus-proxyd.c | 9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
 index 4f44825..52498f3 100644
 --- a/src/bus-proxyd/bus-proxyd.c
 +++ b/src/bus-proxyd/bus-proxyd.c
 @@ -733,6 +733,7 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m) {
  struct kdbus_cmd_free cmd_free;
  struct kdbus_cmd_name *name;
  _cleanup_strv_free_ char **owners = NULL;
 +_cleanup_bus_error_free_ sd_bus_error error = 
 SD_BUS_ERROR_NULL;
  char *arg0;
  int err = 0;
  
 @@ -743,6 +744,14 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m) {
  if (!service_name_is_valid(arg0))
  return synthetic_reply_method_errno(m, -EINVAL, 
 NULL);
  
 +r = sd_bus_get_owner(a, arg0, 0, NULL);
 +if (r == -ESRCH || r == -ENXIO) {
 +sd_bus_error_setf(error, 
 SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get owners of name '%s': no such 
 name., arg0);
 +return synthetic_reply_method_errno(m, r, error);
 +}
 +if (r  0)
 +return synthetic_reply_method_errno(m, r, NULL);
 +
  cmd.flags = KDBUS_NAME_LIST_QUEUED;
  r = ioctl(a-input_fd, KDBUS_CMD_NAME_LIST, cmd);
  if (r  0)
 

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

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-10-10 Thread Anatol Pomozov 
Hi

On Fri, Sep 12, 2014 at 1:09 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
 On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen t...@jklm.no wrote:
 On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez
 mcg...@do-not-panic.com wrote:
 On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen t...@jklm.no wrote:
 How about simply introducing a new flag to finit_module() to indicate
 that the caller does not care about asynchronicity. We could then pass
 this from udev, but existing scripts calling modprobe/insmod will not
 be affected.

 Do you mean that you *do want asynchronicity*?

 Precisely, udev would opt-in, but existing scripts etc would not.

 Sure that's the other alternative that Tejun was mentioning.

 But isn't finit_module() taking a long time a serious problem given
 that it means no other module can be loaded in parallel?

 Indeed but having a desire to make the init() complete fast is
 different than the desire to have the combination of both init and
 probe fast synchronously.

 I guess no one is arguing that probe should somehow be required to be
 fast, but rather:

 If userspace wants init to be fast and let
 probe be async then userspace has no option but to deal with the fact
 that async probe will be async, and it should then use other methods
 to match any dependencies if its doing that itself.

 Correct. And this therefore likely needs to be opt-in behaviour per
 finit_module() invocation to avoid breaking old assumptions.

 Sure.

 For example
 networking should not kick off after a network driver is loaded but
 rather one the device creeps up on udev. We should be good with
 networking dealing with this correctly today but not sure about other
 subsystems. depmod should be able to load the required modules in
 order and if bus drivers work right then probe of the remnant devices
 should happen asynchronously. The one case I can think of that is a
 bit different is modules-load.d things but those *do not rely on the
 timeout*, but are loaded prior to a service requirement. Note though
 that if those modules had probe and they then run async'd then systemd
 service would probably need to consider that the requirements may not
 be there until later. If this is not carefully considered that could
 introduce regression to users of modules-load.d when async probe is
 fully deployed. The same applies to systemd making assumptions of kmod
 loading a module and a dependency being complete as probe would have
 run it before.

 Yeah, these all needs to be considered when deciding whether or not to
 enable async in each specific case.

 Yes and come to think of it I'd recommend opting out of async
 functionality for modules-load.d given that it does *not* hooked with
 the timeout and there is a good chances its users likely do want to
 wait for probe to run at this point.

 Given this I also am inclined now for the per module request to be
 async or not (default) from userspace. The above would be a good
 example starting use case.

 I believe one concern here lies in on whether or not userspace
 is properly equipped to deal with the requirements on module loading
 doing async probing and that possibly failing. Perhaps systemd might
 think all userspace is ready for that but are we sure that's the case?

 There almost certainly are custom things out there relying on the
 synchronous behaviour, but if we make it opt-in we should not have a
 problem.


We recently discussed this timeout module loading issue in Arch IRC
and here are few more ideas:

1) Why not to make the timeout configurable through config file? There
is already udev.conf you can put config option there. Thus people with
modprobe issues can easily fix the problem. And then decrease
default timeout back to 30 seconds. I agree that long module loading
(more than 30 secs) is abnormal and should be investigated by driver
authors.

2) Could you add 'echo w  /proc/sysrq-trigger' to udev code right
before killing the modprobe thread? sysrq will print information
about stuck threads (including modprobe itself) this will make
debugging easier. e.g. dmesg here
https://bugs.archlinux.org/task/40454 says nothing where the threads
were stuck.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-10-10 Thread Tom Gundersen 
On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov
anatol.pomo...@gmail.com wrote:
 1) Why not to make the timeout configurable through config file? There
 is already udev.conf you can put config option there. Thus people with
 modprobe issues can easily fix the problem. And then decrease
 default timeout back to 30 seconds. I agree that long module loading
 (more than 30 secs) is abnormal and should be investigated by driver
 authors.

We can already configure this either on the udev or kernel
commandline, is that not sufficient (I don't object to also adding it
to the config file, just asking)?

 2) Could you add 'echo w  /proc/sysrq-trigger' to udev code right
 before killing the modprobe thread? sysrq will print information
 about stuck threads (including modprobe itself) this will make
 debugging easier. e.g. dmesg here
 https://bugs.archlinux.org/task/40454 says nothing where the threads
 were stuck.

Are the current warnings (in udev git) sufficient (should tell you
which module is taking long, but still won't tell you which kernel
thread of course)?

Cheers,

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