[systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Samuli Suominen
First, some history, we have within Gentoo been pushing changes to
uClibc head for functions that are used
by the udev code of systemd, that were prior to that, only in glibc.
I assume this is the way you want to see things integrated, to not carry
uClibc specific hacks in systemd's code.

However, sometime after 204, unconditional use of locale_t was applied
to src/shared/util.h, and that same header
is used also in udev parts of the systemd build, and that is something
we can't change in uClibc to keep on supporting
NLS-less builds of it.

File src/shared/util.h is using locale_t which isn't used by the
strictly udev parts of the systemd code, I propose to move
this to a different header, so it is only used where it's actually required.

I'm attaching the patch we are currently using to workaround the
problem, not because it should be applied in systemd's code,
but only to demonstrate the part of the header that should get it's own
header, only to demonstrate the problem we
are having.

This is the *only* patch we are carrying for udev currently, otherwise
uClibc builds work fine, so please at least consider what
I just said.

- Samuli

Fix building with uClibc, since if NLS is disabled, locale_t is missing, and if it's enabled,
we still can't be sure the glibc way of using locale_t works for uClibc

Thanks to Mike Frysinger for the patch

--- src/shared/util.h
+++ src/shared/util.h
@@ -849,6 +849,7 @@
 _r_;\
 })
 
+#ifndef __UCLIBC__
 struct _locale_struct_ {
 locale_t saved_locale;
 locale_t new_locale;
@@ -874,6 +875,9 @@
  }  \
  !_saved_locale_.quit; }) ; \
  _saved_locale_.quit = true)
+#else
+#define RUN_WITH_LOCALE(mask, loc)
+#endif
 
 bool id128_is_valid(const char *s) _pure_;
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Samuli Suominen
I can work on a patch that creates the new header, if this is something
you'd be willing to consider.

On 08/04/14 09:04, Samuli Suominen wrote:
 First, some history, we have within Gentoo been pushing changes to
 uClibc head for functions that are used
 by the udev code of systemd, that were prior to that, only in glibc.
 I assume this is the way you want to see things integrated, to not carry
 uClibc specific hacks in systemd's code.

 However, sometime after 204, unconditional use of locale_t was applied
 to src/shared/util.h, and that same header
 is used also in udev parts of the systemd build, and that is something
 we can't change in uClibc to keep on supporting
 NLS-less builds of it.

 File src/shared/util.h is using locale_t which isn't used by the
 strictly udev parts of the systemd code, I propose to move
 this to a different header, so it is only used where it's actually required.

 I'm attaching the patch we are currently using to workaround the
 problem, not because it should be applied in systemd's code,
 but only to demonstrate the part of the header that should get it's own
 header, only to demonstrate the problem we
 are having.

 This is the *only* patch we are carrying for udev currently, otherwise
 uClibc builds work fine, so please at least consider what
 I just said.

 - Samuli



 ___
 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] Two git trees

2014-04-08 Thread Kevin Wilson
Hello,

Why are there two git trees:
one in
git://anongit.freedesktop.org/systemd/systemd
and the second in
https://github.com/systemd/systemd.git
It seems to me that the first one is the primary one, and there
are cases when the second tree is not yet synchronized with the
first one (which might be confusing)

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


Re: [systemd-devel] Two git trees

2014-04-08 Thread Kirill Elagin
The description of repo on GitHub says “Mirror of git://
anongit.freedesktop.org/systemd/systemd”.
That is, it's a mirror. I don't know how exactly it is synchronised, but,
since it is a mirror,
it might be out of date sometimes.


--
Кирилл Елагин


On Tue, Apr 8, 2014 at 10:52 AM, Kevin Wilson wkev...@gmail.com wrote:

 Hello,

 Why are there two git trees:
 one in
 git://anongit.freedesktop.org/systemd/systemd
  and the second in
 https://github.com/systemd/systemd.git
 It seems to me that the first one is the primary one, and there
 are cases when the second tree is not yet synchronized with the
 first one (which might be confusing)

 Regards,
 Kevin

 ___
 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 1/1] networkd: Introduce ipip tunnel

2014-04-08 Thread Jóhann B. Guðmundsson


On 04/08/2014 03:22 AM, Susant Sahani wrote:

file: ipip.netdev
--
[NetDev]
Name=ipip-tun
Kind=ipip

[Tunnel]
Local=192.168.8.102
Remote=10.4.4.4
TTL=64
MTUBytes=1480

file: ipip.network
--
[Match]
Name=eth0

[Network]
Tunnel=ipip-tun


I think this is worse from previous example since now you have moved 
the  network definitions out from the network file and into the net 
device file.


The best way to define this from my pov is like this since the tunnel is 
the network device type aka Kind=tunnel and the mode is the operation 
mode of that tunnel


||tunnel0|.netdev|

|[NetDev]
Name=|||tunnel0|
Kind=tunnel

||[Match]
Name=enp2s0

.network

[Network]
|||# one of the following|
Mode=ipip | gre | sit | isatap | vti --
Address=192.168.0.15/24
Gateway=192.168.0.1|


Or

|tunnel0.netdev|

|[NetDev]
Name=|||tunnel0|
Kind=tunnel

||[Match]
Name=enp2s0

.network

[Network]
|||# one of the following|
Mode=ipip | gre | sit | isatap | vti --
||DHCP=yes|


or if you want to be consistent with how it's done with bridging you 
would swap the Mode= in the [Network] section to Tunnel=|ipip | gre | 
sit | isatap | vti|


JBG

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


[systemd-devel] [PATCH] Removed duplicate includes

2014-04-08 Thread Bas van den Berg
Signed-off-by: Bas van den Berg b.van.den.berg...@gmail.com
---
 src/journal/journal-remote.c |1 -
 src/shared/util.c|1 -
 2 files changed, 2 deletions(-)

diff --git a/src/journal/journal-remote.c b/src/journal/journal-remote.c
index 4ece14e..035a189 100644
--- a/src/journal/journal-remote.c
+++ b/src/journal/journal-remote.c
@@ -42,7 +42,6 @@
 #include macro.h
 #include strv.h
 #include fileio.h
-#include socket-util.h
 #include microhttpd-util.h
 
 #ifdef HAVE_GNUTLS
diff --git a/src/shared/util.c b/src/shared/util.c
index ffe6624..3901f86 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -83,7 +83,6 @@
 #include gunicode.h
 #include virt.h
 #include def.h
-#include missing.h
 
 int saved_argc = 0;
 char **saved_argv = NULL;
-- 
1.7.9.5

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


[systemd-devel] [PATCH] cgroup: After MemmoryAccounting=yes running scope has no memusage

2014-04-08 Thread Stef Walter
Setting the 'MemoryAccounting' unit property to true, puts the
unit into the right cgroup but does the memory.usage_in_bytes
does not reflect the pages already allocated to the processes
in that cgroup.

This is because the memory.move_charge_at_immigrate needs to be
set before migrating processes to the new cgroup memory
controller path:

https://www.kernel.org/doc/Documentation/cgroups/memory.txt

The attached path sets the memory.move_charge_at_immigrate to
0x01 | 0x02 before migrating processes to a new memory cgroup.
---
 src/core/cgroup.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 3dd4c91..fcdbb07 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -26,6 +26,7 @@
 #include special.h
 #include cgroup-util.h
 #include cgroup.h
+#include fileio.h
 
 void cgroup_context_init(CGroupContext *c) {
 assert(c);
@@ -567,6 +568,8 @@ static const char *migrate_callback(CGroupControllerMask 
mask, void *userdata) {
 
 static int unit_create_cgroups(Unit *u, CGroupControllerMask mask) {
 _cleanup_free_ char *path = NULL;
+_cleanup_free_ char *fs = NULL;
+char c[DECIMAL_STR_MAX(pid_t) + 2];
 int r;
 
 assert(u);
@@ -596,6 +599,16 @@ static int unit_create_cgroups(Unit *u, 
CGroupControllerMask mask) {
 u-cgroup_realized = true;
 u-cgroup_realized_mask = mask;
 
+/* Before migrating actually turn memory migration on */
+if (mask  CGROUP_MEMORY) {
+snprintf(c, sizeof(c), %d\n, 3);
+r = cg_get_path_and_check(memory, u-cgroup_path, 
memory.move_charge_at_immigrate, fs);
+if (r = 0)
+r = write_string_file(fs, c);
+if (r  0)
+log_error(Failed to set 
memory.move_change_at_immigrate on %s: %s, fs, strerror(-r));
+}
+
 /* Then, possibly move things over */
 r = cg_migrate_everywhere(u-manager-cgroup_supported, 
u-cgroup_path, u-cgroup_path, migrate_callback, u);
 if (r  0)
-- 
1.8.5.3

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


Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts

2014-04-08 Thread WANG Chao
On 04/08/14 at 02:14am, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Apr 07, 2014 at 03:10:14PM -0400, Vivek Goyal wrote:
  On Mon, Apr 07, 2014 at 10:07:20PM +0400, Andrey Borzenkov wrote:
   В Mon, 7 Apr 2014 13:40:17 -0400
   Vivek Goyal vgo...@redhat.com пишет:
   

Defining a new target which by default waits for all the local fs target
sounds interesting. Again, I have the question, what will happen to 
local-fs-all.target if some device does not show up and say one of the
mounts specified in /etc/fstab fails.
 It result is different for Requires= and for Wants=. Iff there's a chain
 of Requires= from the failing unit (.device in this case) to the target unit
 it will fail. Otherwise, it'll just be delayed. If, as I suggested above 
 local-fs-all.target
 would have Requires= on the .mount units, then your unit could still have
 Wants=/After=local-fs-all.target, and it'll be started even if some mounts
 fail.
 
What we want is.

- Wait for all devices to show up as specified in /etc/fstab. Run fsck
  on devices. Mount devices to mount points specified.

- If everything is successful, things are fine and local-fs-all.target
  will be reached.

- If some device does not show up, or if fsck fails or mount fails, 
still
  local-fs-all.target should reach so that kdump module can detect that
  failure happened and can take alternative action.
 Alternatively, you can specify a soft depenendency on local-fs-all.target by
 using Wants=local-fs-all.target. I think this is preferable, because we want
 local-fs-all.target to be as similar as possible to local-fs.target, which
 has Requires= on the mount points.

Actually, With current implementation, whether Wants or Requires
depends on if nofail is specified.

 
 With this caveat, this should all be satisfied with my proposal.
 
   You can use OnFailure= to define unit(s) started when
   local-fs-all.target fails. But it sounds like you are not really
   interested in *all* filesystems, but in specific fileststems defined in
   kdump configuration.
  
  Kdump scripts registers with dracut as pre-pivot hook. And I believe
  that in initramfs environments /etc/fstab does not contain all
  filesystems. It prmarily contains root and any file system specified
  on dracut command line using --mount option during initramfs generation.
  
  So my understanding that given the fact that /etc/fstab is minimal in
  initramfs, we should be fine waiting for all the fs specified. 
  
  Given the fact that we run under dracut pre-pivot hook callback, I think
  dracut-pre-pivot.service wil have to create a dependency to run after
  local-fs-all.target is reached.
 Hm, maybe. It would be good to get some input from Harald here.
 This is pretty specialized, so maybe it'd be better to have a separate unit
 positioned before or after or parallel to dracut-pre-pivot.service.
 
  Now I am not sure who will generate local-fs-all.target. 
 It would become a standard unit in systemd, like local-fs.target.
 Mount units would be added to this target by fstab-generator.
 
  If dracut
  generates it then dracut will also specify OnFailure=. Question will
  still remain how dracut modules will communicate to dracut that what
  to run after local-fs-all.target fails.
 
  In fact if dracut is doing all this, we don't have to create a separate
  target. Right now we force nofail so that if mount fails, initrd.target
  is still reached.
  
  If we can create a separate service to just handle failures, then we
  probably should be able to spcify OnFailure=dracut-failure-hander.service
  in right file and as modules to register their failure handler hooks
  there.
  
  Something like create new hook called pre-pivot-failure and modules
  register a hook to handle pre-pivot-failure. Then kdump can get the
  control and handle failure.
  
  And this should allow dracut pre pivot service to specify to launch
  dracut-failure-handler.service upon failure.
  
   
  For example,

  Asssume a user wants to save vmcore to nfs destination. Now for 
whatever 
  reason, nfs target could not be mounted. In that case kdump will still
  like to get control and alternatively save dump to local root fs.

   
   Without knowing details it sounds like RequiresMountsFor is more
   appropriate (and can be set by generator based on actual kdump
   configuration).
  
  I am not sure how is it useful for this case. dracut already generates
  all dependencies and puts them in /etc/fstab. And only entries in
  /etc/fstab should be which dracut wants. So I guess we should be fine
  and not need using RequiresMountsFor.
 
 Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Netconsole NG

2014-04-08 Thread poma
On 08.04.2014 04:03, poma wrote:
 On 07.04.2014 19:55, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Apr 07, 2014 at 05:34:10PM +0200, Lukáš Nykrýn wrote:
 The reason why this was not rewritten a long time ago is that the
 initscript tries to figure some of those values by itself (for
 example the MAC address). But yes, we need to do something with
 netconsole. It is a blocker for my initscripts evil plan.
 Doesn't netconsole figure out most of those settings by itself, and
 others default to sensible values, so if the network card is up
 and has an address configured, only the device and target ip must be given?

 Dne 6.4.2014 17:59, poma napsal(a):

 /etc/sysconfig/netconsole:
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source port
 SRC_PORT=12345
 This should default to empty... Kernel will pick something.


 # Source IP address
 SRC_IP=192.168.1.2
 This should default to empty... Kernel will use configured address,
 since we order after network.target anyway.

 # Source network device
 SRC_DEV=enp1s2
 Maybe this can be made into a instance argument?

 # Destination port
 DST_PORT=12345
 I think this should default to 514/syslog, and can be left unset.

 # Destination IP address
 DST_IP=192.168.1.1

 # Destination ethernet address
 DST_EHA=00:11:22:33:44:55
 This should default to unset. The kernel will query it if not set.

 /usr/lib/systemd/system/netconsole.service:
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole
 This is Fedora/RH specific. But I don't know what the proper path should
 be, so maybe this is OK for now.

 Type=simple
 This is the default... No need to specify.

 RemainAfterExit=yes
 ExecStart=/usr/sbin/modprobe netconsole
 This should be /sbin/modprobe for compatibility with split root.

 netconsole=${SRC_PORT}@${SRC_IP}/${SRC_DEV},${DST_PORT}@${DST_IP}/${DST_EHA}
 ExecStop=/usr/sbin/modprobe -r netconsole
 Ditto.


 [Install]
 WantedBy=multi-user.target
 That's a really late... But I don't see a better place unfortunately.

 The original SysV netconsole service with related config - still in use,
 https://git.fedorahosted.org/cgit/initscripts.git/plain/rc.d/init.d/netconsole
 https://git.fedorahosted.org/cgit/initscripts.git/plain/sysconfig/netconsole

 Feel free to comment.
 Looks like an improvement on status quo.

 Zbyszek

 
 Shall we still leave something for users to configure.
 Thanks for your review.
 

$ cat /usr/lib/systemd/system/netconsole-zbyszek.service
[Unit]
Description=Adds the netconsole module with the configured parameters
After=network.target

[Service]
EnvironmentFile=/etc/sysconfig/netconsole-zbyszek
RemainAfterExit=yes
ExecStart=/sbin/modprobe netconsole netconsole=@/${SRC_DEV},@${DST_IP}/
ExecStop=/sbin/modprobe -r netconsole

[Install]
WantedBy=multi-user.target

~~~

$ cat /etc/sysconfig/netconsole-zbyszek
# This is the EnvironmentFile for the netconsole service. Starting this
# service enables the capture of dmesg output on a destination machine.

# Source network device
SRC_DEV=enp1s2

# Destination IP address
DST_IP=192.168.1.1

~~~

$ dmesg | grep netcon
[   24.361611] netpoll: netconsole: local port 6665
[   24.361764] netpoll: netconsole: local IPv4 address 0.0.0.0
[   24.361893] netpoll: netconsole: interface 'enp1s2'
[   24.362061] netpoll: netconsole: remote port 
[   24.362344] netpoll: netconsole: remote IPv4 address 192.168.1.1
[   24.362635] netpoll: netconsole: remote ethernet address
ff:ff:ff:ff:ff:ff
[   24.362909] netpoll: netconsole: no IP address for enp1s2, aborting
[   24.363186] netconsole: cleaning up

~
This turns out to be a bare minimum, i.e.
# modprobe netconsole netconsole=@/enp1s2,@192.168.1.1/
but that is also squeeze breeze ...
~

$ cat /usr/lib/systemd/system/netconsole-poma.service
[Unit]
Description=Adds the netconsole module with the configured parameters
After=network.target

[Service]
EnvironmentFile=/etc/sysconfig/netconsole-poma
RemainAfterExit=yes
ExecStart=/sbin/modprobe netconsole
netconsole=@${SRC_IP}/${SRC_DEV},@${DST_IP}/
ExecStop=/sbin/modprobe -r netconsole

[Install]
WantedBy=multi-user.target



$ cat /etc/sysconfig/netconsole-poma
# This is the EnvironmentFile for the netconsole service. Starting this
# service enables the capture of dmesg output on a destination machine.

# Source IP address
SRC_IP=192.168.1.2

# Source network device
SRC_DEV=enp1s2

# Destination IP address
DST_IP=192.168.1.1

~~~

$ dmesg | grep netcon
[   23.156730] netpoll: netconsole: local port 6665
[   

Re: [systemd-devel] Netconsole NG

2014-04-08 Thread Tom Gundersen
On Tue, Apr 8, 2014 at 2:10 PM, poma pomidorabelis...@gmail.com wrote:
 On 08.04.2014 04:03, poma wrote:
 On 07.04.2014 19:55, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Apr 07, 2014 at 05:34:10PM +0200, Lukáš Nykrýn wrote:
 The reason why this was not rewritten a long time ago is that the
 initscript tries to figure some of those values by itself (for
 example the MAC address). But yes, we need to do something with
 netconsole. It is a blocker for my initscripts evil plan.
 Doesn't netconsole figure out most of those settings by itself, and
 others default to sensible values, so if the network card is up
 and has an address configured, only the device and target ip must be given?

 Dne 6.4.2014 17:59, poma napsal(a):

 /etc/sysconfig/netconsole:
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source port
 SRC_PORT=12345
 This should default to empty... Kernel will pick something.


 # Source IP address
 SRC_IP=192.168.1.2
 This should default to empty... Kernel will use configured address,
 since we order after network.target anyway.

 # Source network device
 SRC_DEV=enp1s2
 Maybe this can be made into a instance argument?

 # Destination port
 DST_PORT=12345
 I think this should default to 514/syslog, and can be left unset.

 # Destination IP address
 DST_IP=192.168.1.1

 # Destination ethernet address
 DST_EHA=00:11:22:33:44:55
 This should default to unset. The kernel will query it if not set.

 /usr/lib/systemd/system/netconsole.service:
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole
 This is Fedora/RH specific. But I don't know what the proper path should
 be, so maybe this is OK for now.

 Type=simple
 This is the default... No need to specify.

 RemainAfterExit=yes
 ExecStart=/usr/sbin/modprobe netconsole
 This should be /sbin/modprobe for compatibility with split root.

 netconsole=${SRC_PORT}@${SRC_IP}/${SRC_DEV},${DST_PORT}@${DST_IP}/${DST_EHA}
 ExecStop=/usr/sbin/modprobe -r netconsole
 Ditto.


 [Install]
 WantedBy=multi-user.target
 That's a really late... But I don't see a better place unfortunately.

 The original SysV netconsole service with related config - still in use,
 https://git.fedorahosted.org/cgit/initscripts.git/plain/rc.d/init.d/netconsole
 https://git.fedorahosted.org/cgit/initscripts.git/plain/sysconfig/netconsole

 Feel free to comment.
 Looks like an improvement on status quo.

 Zbyszek


 Shall we still leave something for users to configure.
 Thanks for your review.


 $ cat /usr/lib/systemd/system/netconsole-zbyszek.service
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole-zbyszek
 RemainAfterExit=yes
 ExecStart=/sbin/modprobe netconsole netconsole=@/${SRC_DEV},@${DST_IP}/
 ExecStop=/sbin/modprobe -r netconsole

 [Install]
 WantedBy=multi-user.target

 ~~~

 $ cat /etc/sysconfig/netconsole-zbyszek
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source network device
 SRC_DEV=enp1s2

 # Destination IP address
 DST_IP=192.168.1.1

 ~~~

 $ dmesg | grep netcon
 [   24.361611] netpoll: netconsole: local port 6665
 [   24.361764] netpoll: netconsole: local IPv4 address 0.0.0.0
 [   24.361893] netpoll: netconsole: interface 'enp1s2'
 [   24.362061] netpoll: netconsole: remote port 
 [   24.362344] netpoll: netconsole: remote IPv4 address 192.168.1.1
 [   24.362635] netpoll: netconsole: remote ethernet address
 ff:ff:ff:ff:ff:ff
 [   24.362909] netpoll: netconsole: no IP address for enp1s2, aborting
 [   24.363186] netconsole: cleaning up

 ~
 This turns out to be a bare minimum, i.e.
 # modprobe netconsole netconsole=@/enp1s2,@192.168.1.1/
 but that is also squeeze breeze ...
 ~

 $ cat /usr/lib/systemd/system/netconsole-poma.service
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole-poma
 RemainAfterExit=yes
 ExecStart=/sbin/modprobe netconsole
 netconsole=@${SRC_IP}/${SRC_DEV},@${DST_IP}/
 ExecStop=/sbin/modprobe -r netconsole

 [Install]
 WantedBy=multi-user.target

 

 $ cat /etc/sysconfig/netconsole-poma
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source IP address
 SRC_IP=192.168.1.2

 # Source network device
 SRC_DEV=enp1s2

 # Destination IP address
 DST_IP=192.168.1.1

 

Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Apr 08, 2014 at 09:04:37AM +0300, Samuli Suominen wrote:
 File src/shared/util.h is using locale_t which isn't used by the
 strictly udev parts of the systemd code, I propose to move
 this to a different header, so it is only used where it's actually required.
I see the usefulness of disabling localization for lots of people,
e.g. embedded. So what about simply adding a --disable-locale switch,
and then having a patch like what you attached with a conditional
using that, and in addition disabling the installation of .po files?

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


Re: [systemd-devel] Two git trees

2014-04-08 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Apr 08, 2014 at 11:06:44AM +0400, Kirill Elagin wrote:
 The description of repo on GitHub says “Mirror of git://
 anongit.freedesktop.org/systemd/systemd”.
 That is, it's a mirror. I don't know how exactly it is synchronised, but,
 since it is a mirror,
 it might be out of date sometimes.
I think it is synchronized after successful jenkins runs, so it is always 
buildable
and unit tests pass.

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


Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts

2014-04-08 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Apr 08, 2014 at 06:35:03PM +0800, WANG Chao wrote:
 On 04/08/14 at 02:14am, Zbigniew Jędrzejewski-Szmek wrote:
  On Mon, Apr 07, 2014 at 03:10:14PM -0400, Vivek Goyal wrote:
   On Mon, Apr 07, 2014 at 10:07:20PM +0400, Andrey Borzenkov wrote:
В Mon, 7 Apr 2014 13:40:17 -0400
Vivek Goyal vgo...@redhat.com пишет:

 
 Defining a new target which by default waits for all the local fs 
 target
 sounds interesting. Again, I have the question, what will happen to 
 local-fs-all.target if some device does not show up and say one of the
 mounts specified in /etc/fstab fails.
  It result is different for Requires= and for Wants=. Iff there's a chain
  of Requires= from the failing unit (.device in this case) to the target unit
  it will fail. Otherwise, it'll just be delayed. If, as I suggested above 
  local-fs-all.target
  would have Requires= on the .mount units, then your unit could still have
  Wants=/After=local-fs-all.target, and it'll be started even if some mounts
  fail.
  
 What we want is.
 
 - Wait for all devices to show up as specified in /etc/fstab. Run fsck
   on devices. Mount devices to mount points specified.
 
 - If everything is successful, things are fine and local-fs-all.target
   will be reached.
 
 - If some device does not show up, or if fsck fails or mount fails, 
 still
   local-fs-all.target should reach so that kdump module can detect 
 that
   failure happened and can take alternative action.
  Alternatively, you can specify a soft depenendency on local-fs-all.target by
  using Wants=local-fs-all.target. I think this is preferable, because we want
  local-fs-all.target to be as similar as possible to local-fs.target, which
  has Requires= on the mount points.
 
 Actually, With current implementation, whether Wants or Requires
 depends on if nofail is specified.
It is specified for local-fs.target, which doesn't necessarilly influence
local-fs-all.target, and anyway, here we're talking about the relationship
between local-fs-all.target and some dracut units.

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


Re: [systemd-devel] Netconsole NG

2014-04-08 Thread Jóhann B. Guðmundsson


On 04/08/2014 12:25 PM, Tom Gundersen wrote:

This looks like a definitive improvement.


I beg the differ that unit file created/provided is rubbish

I even go so far as saying every line in the [Service] section is a 
sample of what not to do.


Anyone reading this thread should stay away from duplicating what is 
being done in it.


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


Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Lennart Poettering
On Tue, 08.04.14 09:04, Samuli Suominen (ssuomi...@gentoo.org) wrote:

I am sorry, but we are not interested in carrying compat code for exotic
libc's. We have made this clear in the past. The onus is on those libc's
to be compatible with glibc and POSIX and all these things, and systemd
is not the place to deal with the complexity if they don't implement the
same API.

Please work with the uclibc people to add the missing APIs so that they
stay compatible with glibc.

Sorry,

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] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Samuli Suominen

On 08/04/14 18:52, Lennart Poettering wrote:
 On Tue, 08.04.14 09:04, Samuli Suominen (ssuomi...@gentoo.org) wrote:

 I am sorry, but we are not interested in carrying compat code for exotic
 libc's. We have made this clear in the past. The onus is on those libc's
 to be compatible with glibc and POSIX and all these things, and systemd
 is not the place to deal with the complexity if they don't implement the
 same API.

 Please work with the uclibc people to add the missing APIs so that they
 stay compatible with glibc.



Please, read again what I suggested. I didn't suggest for the patch that
I attached to be merged.
I was merely suggesting moving the use of locale_t into it's own header.
As in, moving existing code to a different file and being more specific
where it's used in Makefile.am

The code would be same, just new file introduced, no hacks/compat code
to carry around

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


Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Samuli Suominen

On 08/04/14 15:25, Zbigniew Jędrzejewski-Szmek wrote:
 On Tue, Apr 08, 2014 at 09:04:37AM +0300, Samuli Suominen wrote:
 File src/shared/util.h is using locale_t which isn't used by the
 strictly udev parts of the systemd code, I propose to move
 this to a different header, so it is only used where it's actually required.
 I see the usefulness of disabling localization for lots of people,
 e.g. embedded. So what about simply adding a --disable-locale switch,
 and then having a patch like what you attached with a conditional
 using that, and in addition disabling the installation of .po files?

 Zbyszek

I've seen this proposal shot down earlier in the bugzilla.fd.o, which is why
I suggested merely keeping the existing code and moving it to a more
specific header.

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


Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Cristian Rodríguez

El 08/04/14 03:04, Samuli Suominen escribió:


This is the *only* patch we are carrying for udev currently, otherwise
uClibc builds work fine, so please at least consider what
I just said.


All this locale_t thing is standarized in POSIX 2008, . it is up to 
the particular libc to keep up with standards.


systemd requires glibc, this is known and clear since the beginning.

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


Re: [systemd-devel] Two git trees

2014-04-08 Thread David Timothy Strauss
On Tue, Apr 8, 2014 at 5:30 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 I think it is synchronized after successful jenkins runs, so it is always 
 buildable
 and unit tests pass.

That's my GitHub mirror, not anything on freedesktop.org.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Two git trees

2014-04-08 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Apr 08, 2014 at 11:21:57AM -0700, David Timothy Strauss wrote:
 On Tue, Apr 8, 2014 at 5:30 AM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  I think it is synchronized after successful jenkins runs, so it is always 
  buildable
  and unit tests pass.
 
 That's my GitHub mirror, not anything on freedesktop.org.
https://github.com/systemd/systemd is not yours?

Zbyszek

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


Re: [systemd-devel] [PATCH 1/1] networkd: Introduce ipip tunnel

2014-04-08 Thread Umut Tezduyar Lindskog
Hi,

Few minor suggestions, if you care.

On Tue, Apr 8, 2014 at 5:22 AM, Susant Sahani sus...@redhat.com wrote:
 This patch enables basic ipip tunnel support.
 It works with kernel module ipip

 Example configuration

 file: ipip.netdev
 --
 [NetDev]
 Name=ipip-tun
 Kind=ipip

 [Tunnel]
 Local=192.168.8.102
 Remote=10.4.4.4
 TTL=64
 MTUBytes=1480

 file: ipip.network
 --
 [Match]
 Name=eth0

 [Network]
 Tunnel=ipip-tun
 ---
  Makefile.am   |   7 +-
  src/libsystemd-network/network-internal.c |  33 ++
  src/libsystemd-network/network-internal.h |   3 +
  src/libsystemd/sd-rtnl/rtnl-types.c   |   4 +-
  src/network/networkd-link.c   |  25 -
  src/network/networkd-manager.c|  14 +++
  src/network/networkd-netdev-gperf.gperf   |   4 +
  src/network/networkd-netdev.c | 169 
 +-
  src/network/networkd-network-gperf.gperf  |   1 +
  src/network/networkd-network.c|  37 +++
  src/network/networkd.c|   6 ++
  src/network/networkd.h|  27 +
  12 files changed, 323 insertions(+), 7 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index c51f6ae..60c7016 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -4144,8 +4144,8 @@ systemd_networkd_SOURCES = \
 src/network/networkd.c

  systemd_networkd_LDADD = \
 -   libsystemd-networkd-core.la
 -
 +   libsystemd-networkd-core.la \
 +   -lkmod
  noinst_LTLIBRARIES += \
 libsystemd-networkd-core.la

 @@ -4189,7 +4189,8 @@ test_network_SOURCES = \
 src/network/test-network.c

  test_network_LDADD = \
 -   libsystemd-networkd-core.la
 +   libsystemd-networkd-core.la \
 +   -lkmod

  tests += \
 test-network
 diff --git a/src/libsystemd-network/network-internal.c 
 b/src/libsystemd-network/network-internal.c
 index 3686267..5b41cdb 100644
 --- a/src/libsystemd-network/network-internal.c
 +++ b/src/libsystemd-network/network-internal.c
 @@ -326,3 +326,36 @@ int net_parse_inaddr(const char *address, unsigned char 
 *family, void *dst) {

  return 0;
  }
 +
 +int load_module(struct kmod_ctx *ctx, const char *mod_name) {
 +struct kmod_list *modlist = NULL, *l;
 +int r;
 +
 +assert(ctx);
 +assert(mod_name);
 +
 +r = kmod_module_new_from_lookup(ctx, mod_name, modlist);
 +if (r  0)
 +return r;
 +
 +if (!modlist) {
 +log_error(Failed to find module '%s', mod_name);
 +return -ENOENT;
 +}
 +
 +kmod_list_foreach(l, modlist) {
 +struct kmod_module *mod = kmod_module_get_module(l);
Small optimization but maybe move stuct kmod_module *mod; outside of
the for each.
 +
 +r = kmod_module_probe_insert_module(mod, 0, NULL, NULL, 
 NULL, NULL);
If r is -1 from previous run, we are overriding it here.
 +if (r = 0)
 +r = 0;
 +else
 +r = -1;
 +
 +kmod_module_unref(mod);
 +}
 +
 +kmod_module_unref_list(modlist);
 +
 +return r;
 +}
 diff --git a/src/libsystemd-network/network-internal.h 
 b/src/libsystemd-network/network-internal.h
 index 65cd0d7..28f53b9 100644
 --- a/src/libsystemd-network/network-internal.h
 +++ b/src/libsystemd-network/network-internal.h
 @@ -24,6 +24,7 @@
  #include netinet/ether.h
  #include netinet/in.h
  #include stdbool.h
 +#include libkmod.h

  #include udev.h
  #include condition-util.h
 @@ -65,3 +66,5 @@ int config_parse_ifalias(const char *unit, const char 
 *filename, unsigned line,
  int net_parse_inaddr(const char *address, unsigned char *family, void *dst);

  int net_get_unique_predictable_data(struct udev_device *device, uint8_t 
 result[8]);
 +
 +int load_module(struct kmod_ctx *ctx, const char *mod_name);
 diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c 
 b/src/libsystemd/sd-rtnl/rtnl-types.c
 index 44ac5ec..96467a3 100644
 --- a/src/libsystemd/sd-rtnl/rtnl-types.c
 +++ b/src/libsystemd/sd-rtnl/rtnl-types.c
 @@ -104,8 +104,8 @@ static const NLType 
 rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {

  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_LOCAL]   = { .type = NLA_IN_ADDR },
 +[IFLA_IPTUN_REMOTE]  = { .type = NLA_IN_ADDR },
  [IFLA_IPTUN_TTL] = { .type = NLA_U8 },
  [IFLA_IPTUN_TOS] = { .type = NLA_U8 },
  [IFLA_IPTUN_PMTUDISC]= { .type = NLA_U8 },
 diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
 index 63d253d..848eddd 100644
 --- 

Re: [systemd-devel] Netconsole NG

2014-04-08 Thread poma
On 08.04.2014 14:25, Tom Gundersen wrote:
 On Tue, Apr 8, 2014 at 2:10 PM, poma pomidorabelis...@gmail.com wrote:
 On 08.04.2014 04:03, poma wrote:
 On 07.04.2014 19:55, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Apr 07, 2014 at 05:34:10PM +0200, Lukáš Nykrýn wrote:
 The reason why this was not rewritten a long time ago is that the
 initscript tries to figure some of those values by itself (for
 example the MAC address). But yes, we need to do something with
 netconsole. It is a blocker for my initscripts evil plan.
 Doesn't netconsole figure out most of those settings by itself, and
 others default to sensible values, so if the network card is up
 and has an address configured, only the device and target ip must be given?

 Dne 6.4.2014 17:59, poma napsal(a):

 /etc/sysconfig/netconsole:
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source port
 SRC_PORT=12345
 This should default to empty... Kernel will pick something.


 # Source IP address
 SRC_IP=192.168.1.2
 This should default to empty... Kernel will use configured address,
 since we order after network.target anyway.

 # Source network device
 SRC_DEV=enp1s2
 Maybe this can be made into a instance argument?

 # Destination port
 DST_PORT=12345
 I think this should default to 514/syslog, and can be left unset.

 # Destination IP address
 DST_IP=192.168.1.1

 # Destination ethernet address
 DST_EHA=00:11:22:33:44:55
 This should default to unset. The kernel will query it if not set.

 /usr/lib/systemd/system/netconsole.service:
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole
 This is Fedora/RH specific. But I don't know what the proper path should
 be, so maybe this is OK for now.

 Type=simple
 This is the default... No need to specify.

 RemainAfterExit=yes
 ExecStart=/usr/sbin/modprobe netconsole
 This should be /sbin/modprobe for compatibility with split root.

 netconsole=${SRC_PORT}@${SRC_IP}/${SRC_DEV},${DST_PORT}@${DST_IP}/${DST_EHA}
 ExecStop=/usr/sbin/modprobe -r netconsole
 Ditto.


 [Install]
 WantedBy=multi-user.target
 That's a really late... But I don't see a better place unfortunately.

 The original SysV netconsole service with related config - still in use,
 https://git.fedorahosted.org/cgit/initscripts.git/plain/rc.d/init.d/netconsole
 https://git.fedorahosted.org/cgit/initscripts.git/plain/sysconfig/netconsole

 Feel free to comment.
 Looks like an improvement on status quo.

 Zbyszek


 Shall we still leave something for users to configure.
 Thanks for your review.


 $ cat /usr/lib/systemd/system/netconsole-zbyszek.service
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole-zbyszek
 RemainAfterExit=yes
 ExecStart=/sbin/modprobe netconsole netconsole=@/${SRC_DEV},@${DST_IP}/
 ExecStop=/sbin/modprobe -r netconsole

 [Install]
 WantedBy=multi-user.target

 ~~~

 $ cat /etc/sysconfig/netconsole-zbyszek
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source network device
 SRC_DEV=enp1s2

 # Destination IP address
 DST_IP=192.168.1.1

 ~~~

 $ dmesg | grep netcon
 [   24.361611] netpoll: netconsole: local port 6665
 [   24.361764] netpoll: netconsole: local IPv4 address 0.0.0.0
 [   24.361893] netpoll: netconsole: interface 'enp1s2'
 [   24.362061] netpoll: netconsole: remote port 
 [   24.362344] netpoll: netconsole: remote IPv4 address 192.168.1.1
 [   24.362635] netpoll: netconsole: remote ethernet address
 ff:ff:ff:ff:ff:ff
 [   24.362909] netpoll: netconsole: no IP address for enp1s2, aborting
 [   24.363186] netconsole: cleaning up

 ~
 This turns out to be a bare minimum, i.e.
 # modprobe netconsole netconsole=@/enp1s2,@192.168.1.1/
 but that is also squeeze breeze ...
 ~

 $ cat /usr/lib/systemd/system/netconsole-poma.service
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole-poma
 RemainAfterExit=yes
 ExecStart=/sbin/modprobe netconsole
 netconsole=@${SRC_IP}/${SRC_DEV},@${DST_IP}/
 ExecStop=/sbin/modprobe -r netconsole

 [Install]
 WantedBy=multi-user.target

 

 $ cat /etc/sysconfig/netconsole-poma
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source IP address
 SRC_IP=192.168.1.2

 # Source network device
 SRC_DEV=enp1s2

 # 

Re: [systemd-devel] Netconsole NG

2014-04-08 Thread poma
On 08.04.2014 18:21, Jóhann B. Guðmundsson wrote:
 
 On 04/08/2014 12:10 PM, poma wrote:
 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole-zbyszek
 RemainAfterExit=yes
 ExecStart=/sbin/modprobe netconsole netconsole=@/${SRC_DEV},@${DST_IP}/
 ExecStop=/sbin/modprobe -r netconsole
 
 On popular demand of me providing more detailed criticism than just 
 this is rubbish as well as I got somewhat myself to blame for poorly 
 written unit files given that the best practical of unit writing resides 
 in my head by the experience of migrating so many legacy sysv initscript 
 to native systemd units and driven half way to insanity while doing so.
 
 So let me clarify why I think this is rubbish.
 
 For the first you are using the wrong Type for that unit file as in the 
 build in default which is Type=simple for the purpose of this unit along 
 with RemainAfterExit=yes in it when you should be using Type=oneshot unit
 
 Secondly let me start with EnvironmentFile= in 99.9% times this is 
 entirely unnecessary since what is contains within those environment 
 files are configuration changes to daemon startup for daemons that are 
 so poorly written they dont support reading configuration files on startup.
 
 Now on the 21 century within the systemd universe, administrators are ( 
 supposted to be ) using drop in configuration snippets that contain that 
 administrator overwrite to overcome that daemons lack of reading 
 configuration file in the relvant unit's .d configuration directory that 
 resides under /etc/systemd/systemd/ or better yet developers that 
 maintain and own that component should be rewriting it's daemon to 
 support parsing configuration file(s) at startup.
 
 If you happen to be using the 00.1% components that actually has valid 
 usecase for using EnvironmentFile= definition in type service units 
 these days, then those environment files should reside in a components 
 .d directory under /etc to make them cross distributional not under 
 /etc/sysconfig or under /etc/default and hopefully one day I will have 
 manage to remove all traces and usages of environmental files in 
 /etc/sysconfig in Fedora ( but achieving that is more like David vs 
 Goliath or Jóhann vs Red Hat.) as well as others doing the same in their 
 distribution of choice
 
 Thirdly under no circumstances and I mean NEVER should you be loading 
 and unloading modules from within a systemd unit YES NEVER!!!
 
 If you need for one reason or another to load module you do so by 
 placing .conf configuration snippet in /etc/modules-load.d which tell 
 the system which kernel modules to load but fact is if you actually need 
 to load some module manually like this something is wrong since modules 
 should be automatic loaded by PCI IDs, USB IDs, DMI IDs or similar 
 triggers encoded in the kernel modules themselves these days.
 
 And you place .conf configuration snippet in /etc/modprobe.d which 
 contains which parameters the kernel module uses when loading.
 
 Which leads to that service section being rubbish as well as the 
 existence of that entire unit being o_O since the correct way ( always ) 
 when dealing with module and their option is what I described here above 
 which leads to for netconsole being
 
 /etc/modules-load.d/netconsole.conf
 # Load netconsole.ko at boot
 netconsole
 
 And
 
 /etc/modprobe.d/netconsole.conf
 # load netconsole options
 options netconsole netconsole=@192.168.1.2/enp1s2,@192.168.1.1/
 
 And since you are using netconsole you probably want to increase the 
 logvel as well
 
 /etc/sysctl.d/10-netconsole.conf
 #raising loglevel from 7 to 8
 kernel.printk = 8 4 1 7
 
 JBG

What do you mean? African or European swallow?


poma


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


Re: [systemd-devel] Netconsole NG

2014-04-08 Thread poma
On 08.04.2014 23:45, Jóhann B. Guðmundsson wrote:
 
 On 04/08/2014 09:27 PM, poma wrote:
 In fact, this method has long been known from the
 Lm_sensors - Linux hardware monitoring
 
 It's a well known fact that the internet is good at spreading ignorance 
 and what you just provided was an example of more people doing it wrong 
 which does not make it right.
 
 You can see the same pattern when people cut and paste code left and 
 right to cut corners.
 
 JBG

How do you know so much about swallows?


poma


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


Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts

2014-04-08 Thread Vivek Goyal
On Tue, Apr 08, 2014 at 02:14:33AM +0200, Zbigniew Jędrzejewski-Szmek wrote:

[..]
Defining a new target which by default waits for all the local fs target
sounds interesting. Again, I have the question, what will happen to 
local-fs-all.target if some device does not show up and say one of the
mounts specified in /etc/fstab fails.
 It result is different for Requires= and for Wants=. Iff there's a chain
 of Requires= from the failing unit (.device in this case) to the target unit
 it will fail. Otherwise, it'll just be delayed. If, as I suggested above 
 local-fs-all.target
 would have Requires= on the .mount units, then your unit could still have
 Wants=/After=local-fs-all.target, and it'll be started even if some mounts
 fail.

Thanks now I understand the difference between Requires= and Wants=
better.

 
What we want is.

- Wait for all devices to show up as specified in /etc/fstab. Run fsck
  on devices. Mount devices to mount points specified.

- If everything is successful, things are fine and local-fs-all.target
  will be reached.

- If some device does not show up, or if fsck fails or mount fails, 
still
  local-fs-all.target should reach so that kdump module can detect that
  failure happened and can take alternative action.
 Alternatively, you can specify a soft depenendency on local-fs-all.target by
 using Wants=local-fs-all.target. I think this is preferable, because we want
 local-fs-all.target to be as similar as possible to local-fs.target, which
 has Requires= on the mount points.
 
 With this caveat, this should all be satisfied with my proposal.

Agreed. We could define Wants=local-fs-all.target and that would make
sure that our unit will be started even if local-fs-all.target fails.

 
   You can use OnFailure= to define unit(s) started when
   local-fs-all.target fails. But it sounds like you are not really
   interested in *all* filesystems, but in specific fileststems defined in
   kdump configuration.
  
  Kdump scripts registers with dracut as pre-pivot hook. And I believe
  that in initramfs environments /etc/fstab does not contain all
  filesystems. It prmarily contains root and any file system specified
  on dracut command line using --mount option during initramfs generation.
  
  So my understanding that given the fact that /etc/fstab is minimal in
  initramfs, we should be fine waiting for all the fs specified. 
  
  Given the fact that we run under dracut pre-pivot hook callback, I think
  dracut-pre-pivot.service wil have to create a dependency to run after
  local-fs-all.target is reached.
 Hm, maybe. It would be good to get some input from Harald here.
 This is pretty specialized, so maybe it'd be better to have a separate unit
 positioned before or after or parallel to dracut-pre-pivot.service.

I am just thinking loud now. Taking a step back and going back to
figure out why did we introduce nofail to begin with.

If I go through kexec-tools logs, it says nofail was introduced
otherwise we never reach initrd.target. I am wondering why that's the
case. Current initrd.target seems to have following.

[Unit]
Description=Initrd Target
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
OnFailure=emergency.target
OnFailureIsolate=yes
ConditionPathExists=/etc/initrd-release

So it Requires=basic.target. Now let us say basic.target fails, then
I am assuming emergency.target will be activated. And if we hook into
emergency-shell binary and make it run a registered error handler if
it is available, then kdump can drop its handler and take action on
failure.

IOW, what if we stop passing nofail. Then local-fs.target practically
becomes local-fs-all.target. Either services will start just fine (after
a wait for deivces to show up). Or units will start failing and if boot
can't cointinue then somewhere we will fall into emergency shell and
then emergency shell will call into kdump handler.

This is assuming that we have designed boot path in such a way that
most of the time we will not do infinite wait (until and unless user
asked us to do to. (x-systemd.device-timeout=0). So either we will wait
for finite amount of time and then fail some services but continue to
boot. And along the path if we can't make progress then we will drop into
emergency shell.

If above assumption is right, then hooking into emergency shell logic
in initramfs should provide what I am looking for.

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


Re: [systemd-devel] Netconsole NG

2014-04-08 Thread poma
On 08.04.2014 23:27, poma wrote:
 On 08.04.2014 14:25, Tom Gundersen wrote:
 On Tue, Apr 8, 2014 at 2:10 PM, poma pomidorabelis...@gmail.com wrote:
 On 08.04.2014 04:03, poma wrote:
 On 07.04.2014 19:55, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Apr 07, 2014 at 05:34:10PM +0200, Lukáš Nykrýn wrote:
 The reason why this was not rewritten a long time ago is that the
 initscript tries to figure some of those values by itself (for
 example the MAC address). But yes, we need to do something with
 netconsole. It is a blocker for my initscripts evil plan.
 Doesn't netconsole figure out most of those settings by itself, and
 others default to sensible values, so if the network card is up
 and has an address configured, only the device and target ip must be 
 given?

 Dne 6.4.2014 17:59, poma napsal(a):

 /etc/sysconfig/netconsole:
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source port
 SRC_PORT=12345
 This should default to empty... Kernel will pick something.


 # Source IP address
 SRC_IP=192.168.1.2
 This should default to empty... Kernel will use configured address,
 since we order after network.target anyway.

 # Source network device
 SRC_DEV=enp1s2
 Maybe this can be made into a instance argument?

 # Destination port
 DST_PORT=12345
 I think this should default to 514/syslog, and can be left unset.

 # Destination IP address
 DST_IP=192.168.1.1

 # Destination ethernet address
 DST_EHA=00:11:22:33:44:55
 This should default to unset. The kernel will query it if not set.

 /usr/lib/systemd/system/netconsole.service:
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole
 This is Fedora/RH specific. But I don't know what the proper path should
 be, so maybe this is OK for now.

 Type=simple
 This is the default... No need to specify.

 RemainAfterExit=yes
 ExecStart=/usr/sbin/modprobe netconsole
 This should be /sbin/modprobe for compatibility with split root.

 netconsole=${SRC_PORT}@${SRC_IP}/${SRC_DEV},${DST_PORT}@${DST_IP}/${DST_EHA}
 ExecStop=/usr/sbin/modprobe -r netconsole
 Ditto.


 [Install]
 WantedBy=multi-user.target
 That's a really late... But I don't see a better place unfortunately.

 The original SysV netconsole service with related config - still in use,
 https://git.fedorahosted.org/cgit/initscripts.git/plain/rc.d/init.d/netconsole
 https://git.fedorahosted.org/cgit/initscripts.git/plain/sysconfig/netconsole

 Feel free to comment.
 Looks like an improvement on status quo.

 Zbyszek


 Shall we still leave something for users to configure.
 Thanks for your review.


 $ cat /usr/lib/systemd/system/netconsole-zbyszek.service
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole-zbyszek
 RemainAfterExit=yes
 ExecStart=/sbin/modprobe netconsole netconsole=@/${SRC_DEV},@${DST_IP}/
 ExecStop=/sbin/modprobe -r netconsole

 [Install]
 WantedBy=multi-user.target

 ~~~

 $ cat /etc/sysconfig/netconsole-zbyszek
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source network device
 SRC_DEV=enp1s2

 # Destination IP address
 DST_IP=192.168.1.1

 ~~~

 $ dmesg | grep netcon
 [   24.361611] netpoll: netconsole: local port 6665
 [   24.361764] netpoll: netconsole: local IPv4 address 0.0.0.0
 [   24.361893] netpoll: netconsole: interface 'enp1s2'
 [   24.362061] netpoll: netconsole: remote port 
 [   24.362344] netpoll: netconsole: remote IPv4 address 192.168.1.1
 [   24.362635] netpoll: netconsole: remote ethernet address
 ff:ff:ff:ff:ff:ff
 [   24.362909] netpoll: netconsole: no IP address for enp1s2, aborting
 [   24.363186] netconsole: cleaning up

 ~
 This turns out to be a bare minimum, i.e.
 # modprobe netconsole netconsole=@/enp1s2,@192.168.1.1/
 but that is also squeeze breeze ...
 ~

 $ cat /usr/lib/systemd/system/netconsole-poma.service
 [Unit]
 Description=Adds the netconsole module with the configured parameters
 After=network.target

 [Service]
 EnvironmentFile=/etc/sysconfig/netconsole-poma
 RemainAfterExit=yes
 ExecStart=/sbin/modprobe netconsole
 netconsole=@${SRC_IP}/${SRC_DEV},@${DST_IP}/
 ExecStop=/sbin/modprobe -r netconsole

 [Install]
 WantedBy=multi-user.target

 

 $ cat /etc/sysconfig/netconsole-poma
 # This is the EnvironmentFile for the netconsole service. Starting this
 # service enables the capture of dmesg output on a destination machine.

 # Source IP address
 SRC_IP=192.168.1.2

 # Source network 

Re: [systemd-devel] Netconsole NG

2014-04-08 Thread Jóhann B. Guðmundsson


On 04/08/2014 09:53 PM, poma wrote:

How do you know so much about swallows?


Given that you respond in random unrelated quotes on threads and reports 
then perhaps it's best that people start replying to you in same manner 
since it seems to be your preferred way of communication.


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


Re: [systemd-devel] Netconsole NG

2014-04-08 Thread poma
On 09.04.2014 00:21, Jóhann B. Guðmundsson wrote:
 
 On 04/08/2014 09:53 PM, poma wrote:
 How do you know so much about swallows?
 
 Given that you respond in random unrelated quotes on threads and reports 
 then perhaps it's best that people start replying to you in same manner 
 since it seems to be your preferred way of communication.
 
 JBG

What? A swallow carrying a coconut?


poma


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


Re: [systemd-devel] Two git trees

2014-04-08 Thread David Timothy Strauss
On Tue, Apr 8, 2014 at 11:31 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 https://github.com/systemd/systemd is not yours?

Nope, that's mine. You were right. I misread the two trees as the
authenticated and anonymous git on freedesktop.org for some reason.

They were out of sync because CI broke. It should never be more than
30 minutes behind unless master is broken on freedesktop.org. Fixing
it now.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Two git trees

2014-04-08 Thread David Timothy Strauss
CI is back online, but test-dhcp-option is currently failing, so it
won't update on GitHub until that's fixed.
___
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

2014-04-08 Thread Jason St. John
On Sat, Apr 5, 2014 at 9:26 PM, David Timothy Strauss
da...@davidstrauss.net wrote:
 On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John jstj...@purdue.edu wrote:
 init.debug would be better than systemd.debug, in my opinion. It
 is shorter (less typing and no possible end-user confusion over
 systemd.debug vs. system.debug), and it is init-agnostic. Other
 init systems (OpenRC, Upstart, etc.) would be able to add their own
 support for this, if they want, without requiring an init-specific
 kernel parameter.

 It just seems a lot simpler this way.

 It would be a little odd given how systemd.name is how other
 probably portable options get namespaced. Arguably, systemd.log_level
 would become init.log_level. I'm not against it, but it couldn't be
 just init.debug.

That's a good point. Would patches be accepted that allowed both
systemd.log_level and init.log_level, etc.?

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