Re: [systemd-devel] x-initrd.mount + shutdown umount logic question

2013-06-13 Thread Colin Guthrie
'Twas brillig, and Tom Gundersen at 13/06/13 22:40 did gyre and gimble:
> On Thu, Jun 13, 2013 at 11:13 PM, Colin Guthrie  wrote:
>> If a mount has the x-initrd.mount option shouldn't it be excluded from
>> the umount loop during shutdown?
> 
> Makes sense. Also see the patch "[PATCH] mount: Don't add conflicts
> with umount.target for certain mounts" just posted by Ross Lagerwall,
> I guess these could be unified?

Yeah, it was actually because I'd read Ross' patch that this mount
option was fresh in my mind when reading my bug :)

Could possibly be unified but I think Ross' patch stands on it's own anyway.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] x-initrd.mount + shutdown umount logic question

2013-06-13 Thread Tom Gundersen
On Thu, Jun 13, 2013 at 11:13 PM, Colin Guthrie  wrote:
> If a mount has the x-initrd.mount option shouldn't it be excluded from
> the umount loop during shutdown?

Makes sense. Also see the patch "[PATCH] mount: Don't add conflicts
with umount.target for certain mounts" just posted by Ross Lagerwall,
I guess these could be unified?

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


[systemd-devel] x-initrd.mount + shutdown umount logic question

2013-06-13 Thread Colin Guthrie
Hi,

If a mount has the x-initrd.mount option shouldn't it be excluded from
the umount loop during shutdown?

I've looked at the code but I don't see where they would be excluded.

The reason I ask is that a user asked to exclude certain paths from the
umount logic, but I didn't like the patch he presented which was very
specific and one I'd have to carry downstream (it was used for live
ISOs). I'm sure it could be solved in other ways too but one thought was
the above option, but while I can see it's use in the fstab generator, I
can't see where this info is used in the umounting spree where /usr and
/ are excluded specifically rather than using the result of the
mount_in_initrd() function.

Any thoughts?

Col

For reference:
https://bugs.mageia.org/show_bug.cgi?id=8322
-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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


Re: [systemd-devel] [PATCH] core: switch to journal when socket is listening

2013-06-13 Thread Umut Tezduyar
On Thu, Jun 13, 2013 at 9:26 PM, Umut Tezduyar  wrote:
> systemd starts using journal as soon as the journal
> socket is in listening state instead of waiting for
> journal's socket to switch to 'running' state.
> ---
>  src/core/manager.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/core/manager.c b/src/core/manager.c
> index f16621a..cebc43e 100644
> --- a/src/core/manager.c
> +++ b/src/core/manager.c
> @@ -2613,7 +2613,8 @@ void manager_recheck_journal(Manager *m) {
>  return;
>
>  u = manager_get_unit(m, SPECIAL_JOURNALD_SOCKET);
> -if (u && SOCKET(u)->state != SOCKET_RUNNING) {
> +if (u && SOCKET(u)->state != SOCKET_RUNNING &&
> + SOCKET(u)->state != SOCKET_LISTENING) {
>  log_close_journal();
>  return;
>  }
> --
> 1.8.3
>

Hi,

Due to a race condition (at least I think) between systemd and
journald, systemd might keep logging to kmsg even though journal is up
and running. Systemd switches to using journal for logging when both
journal's socket and service are in running state. Occasionally  I
have ended up finding my system in the following state after booting
to basic.target.

systemd-journald.service   loaded active   running Journal Service
systemd-journald.socketloaded active   listening   Journal Socket

At this point journal is up, program's stdout/err is sent to journal
(can be seen by journalctl) but systemd still thinks journal is not
usable for its own logging and keeps logging to kmsg.

If you are using kernel < 3.5, the effect of the problem is not being
able to see systemds logs in journalctl.

---

I think what is happening is both journald and systemd are racing for
the EPOLLIN event on the journal's sockets. If journal is receiving
EPOLLIN events all the time, then systemd will never get notified of
the activity on the sockets and never switch the socket to running
state.

If I disable the EPOLLIN event registration on the journald side, I
can see that systemd-journald.socket switches to running state %100.

Since systemd-journal.socket and systemd-journal.service are starting
on boot up anyways, I don't see the necessity of waiting for
systemd-journald.socket to go to running state.

If anyone would like to get more information, I can reproduce the
problem pretty often. I have tried both kernel 3.4 and 3.8 as well as
different ISAs.

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


[systemd-devel] [PATCH] core: switch to journal when socket is listening

2013-06-13 Thread Umut Tezduyar
systemd starts using journal as soon as the journal
socket is in listening state instead of waiting for
journal's socket to switch to 'running' state.
---
 src/core/manager.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/core/manager.c b/src/core/manager.c
index f16621a..cebc43e 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2613,7 +2613,8 @@ void manager_recheck_journal(Manager *m) {
 return;
 
 u = manager_get_unit(m, SPECIAL_JOURNALD_SOCKET);
-if (u && SOCKET(u)->state != SOCKET_RUNNING) {
+if (u && SOCKET(u)->state != SOCKET_RUNNING &&
+ SOCKET(u)->state != SOCKET_LISTENING) {
 log_close_journal();
 return;
 }
-- 
1.8.3

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


[systemd-devel] [PATCH] rules: only run systemd-sysctl when a network device is added

2013-06-13 Thread Ross Lagerwall
Otherwise, when a network device is renamed, systemd-sysctl is run twice
with the same network device name: once for ACTION="add" and once for
ACTION="move".
---
 rules/99-systemd.rules.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/99-systemd.rules.in b/rules/99-systemd.rules.in
index d17bdd9..e9b2da7 100644
--- a/rules/99-systemd.rules.in
+++ b/rules/99-systemd.rules.in
@@ -49,7 +49,7 @@ SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{ID_USB_INTERFACES}=="*:0701??:
 
 # Apply sysctl variables to network devices (and only to those) as they appear.
 
-SUBSYSTEM=="net", KERNEL!="lo", RUN+="@rootlibexecdir@/systemd-sysctl 
--prefix=/proc/sys/net/ipv4/conf/$name --prefix=/proc/sys/net/ipv4/neigh/$name 
--prefix=/proc/sys/net/ipv6/conf/$name --prefix=/proc/sys/net/ipv6/neigh/$name"
+ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", 
RUN+="@rootlibexecdir@/systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/$name 
--prefix=/proc/sys/net/ipv4/neigh/$name --prefix=/proc/sys/net/ipv6/conf/$name 
--prefix=/proc/sys/net/ipv6/neigh/$name"
 
 # Asynchronously mount file systems implemented by these modules as
 # soon as they are loaded.
-- 
1.8.3.1

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


[systemd-devel] [PATCH] mount: Don't add conflicts with umount.target for certain mounts

2013-06-13 Thread Ross Lagerwall
At startup, mount_enumerate is called at manager startup.
This creates a unit for each mount point in /proc/self/mountinfo.  If no
unit for the mount point has been loaded yet (which is quite possible
since mount_enumerate is called early), a unit is created and set to
conflict with umount.target.  However, this should not happen for /,
/usr and any mount point marked with x-initrd.mount.

This caused systemd to incorrectly unmount / on shutdown.
---
 src/core/mount.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index 10073b5..377cf44 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1538,9 +1538,12 @@ static int mount_add_one(
 if (r < 0)
 goto fail;
 
-r = unit_add_dependency_by_name(u, UNIT_CONFLICTS, 
SPECIAL_UMOUNT_TARGET, NULL, true);
-if (r < 0)
-goto fail;
+if (!path_equal(where, "/") && !path_equal(where, "/usr") &&
+!mount_test_option(options, "x-initrd.mount")) {
+r = unit_add_dependency_by_name(u, UNIT_CONFLICTS, 
SPECIAL_UMOUNT_TARGET, NULL, true);
+if (r < 0)
+goto fail;
+}
 
 unit_add_to_load_queue(u);
 } else {
-- 
1.8.3.1

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