date:20131120

On Wed, Nov 20, 2013 at 12:02 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:

 On 11/19/2013 09:20 PM, Tom Gundersen wrote:

 On Tue, Nov 19, 2013 at 7:07 PM, Colin Guthriegm...@colin.guthr.ie
 wrote:
 What I have in mind (though it is not dictated by this patch) is
 something different (first proposed by Lennart in an earlier thread):

 [Network]
 Address=192.168.0.1/24
 Address=192.168.0.2/24
 Gateway=192.168.1.1

 [Address:oneaddress]
 Address=192.168.0.3/24
 Label=three
 Peer=192.168.1.1

 [Address:anotheraddress]
 Address=192.168.0.4/24
 Label=four

 In this case we'll configure four addresses. The two first ones could
 also have been expressed as:

 [Address:foo]
 Address=192.168.0.1/24

 [Address:bar]
 Address=192.168.0.2/24,

 but we allow putting them directly in the [Network] section rather
 than in a named [Address] section as a shorthand.

 Notice that if we simply did

 [Address]
 Address=192.168.0.3/24
 Label=three
 Peer=192.168.1.1

 [Address]
 Address=192.168.0.4/24
 Label=four,

 that wouldn't work as it is (at least currently) equivalent to

 [Address]
 Address=192.168.0.3/24
 Label=three
 Peer=192.168.1.1
 Address=192.168.0.4/24
 Label=four,

 which is why we need to give the secitons unique names.


 Arent's we sacrificing significant part of simplicity in units going down
 this path as opposed to have users use per unit interface instances units
 and templating/instances ?

I don't quite follow how that would work? You may be right that this
is not the simplest syntax though, I'm trying to come up with
something better.

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

Re: [systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections

On Wed, Nov 20, 2013 at 12:02 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 On 11/19/2013 09:20 PM, Tom Gundersen wrote:

 On Tue, Nov 19, 2013 at 7:07 PM, Colin Guthriegm...@colin.guthr.ie
 wrote:
 What I have in mind (though it is not dictated by this patch) is
 something different (first proposed by Lennart in an earlier thread):

 [Network]
 Address=192.168.0.1/24
 Address=192.168.0.2/24
 Gateway=192.168.1.1

 [Address:oneaddress]
 Address=192.168.0.3/24
 Label=three
 Peer=192.168.1.1

 [Address:anotheraddress]
 Address=192.168.0.4/24
 Label=four

 In this case we'll configure four addresses. The two first ones could
 also have been expressed as:

 [Address:foo]
 Address=192.168.0.1/24

 [Address:bar]
 Address=192.168.0.2/24,

 but we allow putting them directly in the [Network] section rather
 than in a named [Address] section as a shorthand.

 Notice that if we simply did

 [Address]
 Address=192.168.0.3/24
 Label=three
 Peer=192.168.1.1

 [Address]
 Address=192.168.0.4/24
 Label=four,

 that wouldn't work as it is (at least currently) equivalent to

 [Address]
 Address=192.168.0.3/24
 Label=three
 Peer=192.168.1.1
 Address=192.168.0.4/24
 Label=four,

 which is why we need to give the secitons unique names.

 Arent's we sacrificing significant part of simplicity in units going down
 this path as opposed to have users use per unit interface instances units
 and templating/instances ?

I think it's ok.

But we should probably answer why we don't simply allow the repetition
of plain sections, like we allow the repetition of identical keys in
them.

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

Re: [systemd-devel] [PATCH] bus/rtnl: silence warnings with clang

On Wed, Nov 20, 2013 at 7:48 AM, Thomas H.P. Andersen pho...@gmail.com wrote:
 Hi Tom,

 Sorry. Git send-email is just giving me error messages right now. I
 have attached the patch instead.

Thanks! Applied.

-t
 On Wed, Nov 20, 2013 at 1:12 AM, Tom Gundersen t...@jklm.no wrote:
 Hi Thomas,

 I'm not able to apply this patch, could you please resend using 
 git-send-email?

 Cheers,

 Tom

 On Tue, Nov 19, 2013 at 10:16 PM, Thomas H.P. Andersen pho...@gmail.com 
 wrote:
 ---
  src/libsystemd-bus/bus-internal.h   | 2 +-
  src/libsystemd-rtnl/rtnl-internal.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/libsystemd-bus/bus-internal.h
 b/src/libsystemd-bus/bus-internal.h
 index 4f9d941..faed183 100644
 --- a/src/libsystemd-bus/bus-internal.h
 +++ b/src/libsystemd-bus/bus-internal.h
 @@ -307,4 +307,4 @@ char *bus_address_escape(const char *v);
   * bus from the callback doesn't destroy the object we are working
   * on */
  #define BUS_DONT_DESTROY(bus) \
 -_cleanup_bus_unref_ sd_bus *_dont_destroy_##bus = sd_bus_ref(bus)
 +_cleanup_bus_unref_ _unused_ sd_bus *_dont_destroy_##bus =
 sd_bus_ref(bus)
 diff --git a/src/libsystemd-rtnl/rtnl-internal.h
 b/src/libsystemd-rtnl/rtnl-internal.h
 index c8a97da..a229ae7 100644
 --- a/src/libsystemd-rtnl/rtnl-internal.h
 +++ b/src/libsystemd-rtnl/rtnl-internal.h
 @@ -80,4 +80,4 @@ int socket_read_message(sd_rtnl *nl, sd_rtnl_message 
 **ret);

  /* Make sure callbacks don't destroy the rtnl connection */
  #define RTNL_DONT_DESTROY(rtnl) \
 -_cleanup_sd_rtnl_unref_ sd_rtnl *_dont_destroy_##rtnl =
 sd_rtnl_ref(rtnl)
 +_cleanup_sd_rtnl_unref_ _unused_ sd_rtnl
 *_dont_destroy_##rtnl = sd_rtnl_ref(rtnl)
 --
 1.8.4.2
 ___
 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] Newbie question - Requires doesn't work properly

2013-11-20 Thread salil GK

Hello

  I am pretty new to systemd.
  I am trying to write two dependent services Myservice and MyserviceTwo.

*Myservice.service*

*[Unit]*
*Description=This is a test service*

*[Service]*
*PIDFile=/var/run/Myservice.pid*
*ExecStartPre=/bin/rm -f /tmp/log.log*
*#ExecStartPre=/usr/bin/systemctl stop Myservice*
*ExecStart=/tmp/one.sh*
*Restart=on-abort*
*NotifyAccess=all*
*WatchdogSec=20*

*[Install]*
*Alias=myservice.services*


*MyserviceTwo.service*

*[Unit]*
*Description=This is a TWO test service*
*Requires=Myservice.service*
*After=Myservice.service*

*[Service]*
*PIDFile=/var/run/MyserviceTwo.pid*
*#ExecStartPre=/bin/rm -f /tmp/log.log*
*ExecStart=/tmp/two.sh*
*Restart=on-abort*
*NotifyAccess=all*
*WatchdogSec=10*

*[Install]*
*Alias=Salil2.services*


   When I run systemctl start MyserviceTwo, Myservice also gets started.

   I have put a systemd-notify command in my scripts

*systemd-notify WATCHDOG=1 *

   I deliberately made the one.sh fail so that Myservice will fail.

   What I expected is - when Myservice fails, MyserviceTwo also fail. But
that didn't happen. following is the output of status command

*[root@localhost system]# systemctl status Myservice*
*Myservice.service - This is a test service*
*   Loaded: loaded (/usr/lib/systemd/system/Myservice.service; disabled)*
*   Active: failed (Result: watchdog) since Thu 2013-11-21 00:21:19 IST;
10min ago*
*  Process: 3143 ExecStartPre=/bin/rm -f /tmp/log.log (code=exited,
status=0/SUCCESS)*
* Main PID: 3145*
*   CGroup: name=systemd:/system/Myservice.service*
*   ├─3145 /bin/bash /tmp/one.sh*
*   └─4157 sleep 5*

*Nov 21 00:20:59 localhost.localdomain systemd[1]: Starting This is a test
service...*
*Nov 21 00:20:59 localhost.localdomain systemd[1]: Started This is a test
service.*
*Nov 21 00:21:19 localhost.localdomain systemd[1]: Myservice.service
watchdog timeout!*
*Nov 21 00:21:19 localhost.localdomain systemd[1]: Unit Myservice.service
entered failed state.*

*-*

*[root@localhost system]# systemctl status MyserviceTwo*
*MyserviceTwo.service - This is a TWO test service*
*   Loaded: loaded (/usr/lib/systemd/system/MyserviceTwo.service; disabled)*
*   Active: active (running) since Thu 2013-11-21 00:20:59 IST; 11min ago*
* Main PID: 3146 (two.sh)*
*   CGroup: name=systemd:/system/MyserviceTwo.service*
*   ├─3146 /bin/bash /tmp/two.sh*
*   └─4220 sleep 5*

*Nov 21 00:20:59 localhost.localdomain systemd[1]: Starting This is a TWO
test service...*
*Nov 21 00:20:59 localhost.localdomain systemd[1]: Started This is a TWO
test service.*

Any pointers on how to debug the issue

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

Re: [systemd-devel] Newbie question - Requires doesn't work properly

2013-11-20 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Nov 20, 2013 at 07:09:13PM +0530, salil GK wrote:
 Hello
 
   I am pretty new to systemd.
   I am trying to write two dependent services Myservice and MyserviceTwo.
 
 *Myservice.service*
 
 *[Unit]*
 *Description=This is a test service*
 
 *[Service]*
 *PIDFile=/var/run/Myservice.pid*
 *ExecStartPre=/bin/rm -f /tmp/log.log*
 *#ExecStartPre=/usr/bin/systemctl stop Myservice*
 *ExecStart=/tmp/one.sh*
 *Restart=on-abort*
 *NotifyAccess=all*
 *WatchdogSec=20*
 
 *[Install]*
 *Alias=myservice.services*
 
 
 *MyserviceTwo.service*
 
 *[Unit]*
 *Description=This is a TWO test service*
 *Requires=Myservice.service*
 *After=Myservice.service*
 
 *[Service]*
 *PIDFile=/var/run/MyserviceTwo.pid*
 *#ExecStartPre=/bin/rm -f /tmp/log.log*
That's not nice.

 *ExecStart=/tmp/two.sh*
 *Restart=on-abort*
 *NotifyAccess=all*
 *WatchdogSec=10*
 
 *[Install]*
 *Alias=Salil2.services*
 
 
When I run systemctl start MyserviceTwo, Myservice also gets started.
 
I have put a systemd-notify command in my scripts
 
 *systemd-notify WATCHDOG=1 *
 
I deliberately made the one.sh fail so that Myservice will fail.
 
What I expected is - when Myservice fails, MyserviceTwo also fail. But
 that didn't happen. following is the output of status command
Requires= is only relevant at service start time. I think BindsTo=
should work for you.

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

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

2013-11-20 Thread Thomas Bächler

Am 20.11.2013 14:38, schrieb Tom Gundersen:
 Pass on the line on which a section was decleared to the parsers, so they
 can distinguish between multiple sections (if they chose to). Currently
 no parsers take advantage of this, but a follow-up patch will do that
 to distinguish
 
 [Address]
 Address=192.168.0.1/24
 Label=one
 
 [Address]
 Address=192.168.0.2/24
 Label=two
 
 from
 
 [Address]
 Address=192.168.0.1/24
 Label=one
 Address=192.168.0.2/24
 Label=two

This is a bad idea. When we have a config file

[Section]
Foo=bar

[Section]
Foo=baz

and have a corresponding .d snippet with

[Section]
Foo=bay

what does this mean? Does it override the value of the first section,
the second section or does it create a new section?




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

On Wed, Nov 20, 2013 at 2:57 PM, Thomas Bächler tho...@archlinux.org wrote:
 Am 20.11.2013 14:38, schrieb Tom Gundersen:
 Pass on the line on which a section was decleared to the parsers, so they
 can distinguish between multiple sections (if they chose to). Currently
 no parsers take advantage of this, but a follow-up patch will do that
 to distinguish

 [Address]
 Address=192.168.0.1/24
 Label=one

 [Address]
 Address=192.168.0.2/24
 Label=two

 from

 [Address]
 Address=192.168.0.1/24
 Label=one
 Address=192.168.0.2/24
 Label=two

 This is a bad idea. When we have a config file

 [Section]
 Foo=bar

 [Section]
 Foo=baz

 and have a corresponding .d snippet with

 [Section]
 Foo=bay

 what does this mean? Does it override the value of the first section,
 the second section or does it create a new section?

Yeah, in this case it would not make sense. However, this stuff is
opt-in only, and unit files don't opt-in (currently nothing does). For
the use-case I have in mind we won't allow partial overrides and
probably not even drop-ins/includes.

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

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

2013-11-20 Thread Thomas Bächler

Am 20.11.2013 15:02, schrieb Tom Gundersen:
 what does this mean? Does it override the value of the first section,
 the second section or does it create a new section?
 
 Yeah, in this case it would not make sense. However, this stuff is
 opt-in only, and unit files don't opt-in (currently nothing does). For
 the use-case I have in mind we won't allow partial overrides and
 probably not even drop-ins/includes.

So, we'd have inconsistent config file syntax across systemd? Some
section types override/extend when we write them more than once, some
section types create new instances?

I like the idea of assigning unique names to section instances much more.




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

On Wed, Nov 20, 2013 at 3:05 PM, Thomas Bächler tho...@archlinux.org wrote:
 Am 20.11.2013 15:02, schrieb Tom Gundersen:
 what does this mean? Does it override the value of the first section,
 the second section or does it create a new section?

 Yeah, in this case it would not make sense. However, this stuff is
 opt-in only, and unit files don't opt-in (currently nothing does). For
 the use-case I have in mind we won't allow partial overrides and
 probably not even drop-ins/includes.

 So, we'd have inconsistent config file syntax across systemd? Some
 section types override/extend when we write them more than once, some
 section types create new instances?

We have contradicting domain specific stuff and rules everywhere.

The network files are a stream of files to read and stop at the first
match, file names do not matter at all besides the ordering of apply.

With unit files we have one set of keys, the file name is the key to
lookup the entire set and the drop-ins.

Drop-in for a flow of unnamed files make not much sense, I think.

 I like the idea of assigning unique names to section instances much more.

We could still support/allow them to be named, but not sure why we
would need to require them.

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

Re: [systemd-devel] The whole su/pkexec session debate

On Wed, 2013-11-20 at 10:16 +, Colin Guthrie wrote:

 How do we fix this?

There are a lot of cases - screen is just one of them.  I think to
make forward progress on this we'll have to enumerate the cases,
evaluate the problems with each, then for each problem, evaluate a fix -
and make sure that fix doesn't regress one of the other cases.  Fun! =)

One very important thing that's in the mix here is the user@.service
future.  It helps us move forcefully away from the old model of
independent sessions, a direction we've been going incrementally via
additions of things like XDG_RUNTIME_DIR (and then higher level things
on top like a per-user bus instead of per-session).

Cron for example could be spawned from user@service.

 But in the case of screen I'm specifically asking for a new, stand alone
 session.

I'd agree; but the fix would be fairly invasive for screen.  I think
it'd have to become setuid root, so it could request a new session.

 Perhaps this is all OK, and the closing state here is not a problem.
 But such apps and use cases really are not compatible at all with the
 kill-session-processes= option of pam_systemd and it would be nice to do
 things properly.

I believe that option is not the default precisely because of screen.

But anyways...we have to take some level of incrementalism here.
Martin's patch is a very small and correct fix for a real-world problem.
My patch is a bit more invasive, but I think it's going closer to the
root of the problem.


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

Re: [systemd-devel] The whole su/pkexec session debate

2013-11-20 Thread Colin Guthrie

Hi!

'Twas brillig, and Colin Walters at 20/11/13 14:49 did gyre and gimble:
 On Wed, 2013-11-20 at 10:16 +, Colin Guthrie wrote:
 
 How do we fix this?
 
 There are a lot of cases - screen is just one of them.  I think to
 make forward progress on this we'll have to enumerate the cases,
 evaluate the problems with each, then for each problem, evaluate a fix -
 and make sure that fix doesn't regress one of the other cases.  Fun! =)

Yup!

 One very important thing that's in the mix here is the user@.service
 future.  It helps us move forcefully away from the old model of
 independent sessions, a direction we've been going incrementally via
 additions of things like XDG_RUNTIME_DIR (and then higher level things
 on top like a per-user bus instead of per-session).

ACK again.

 Cron for example could be spawned from user@service.
 
 But in the case of screen I'm specifically asking for a new, stand alone
 session.
 
 I'd agree; but the fix would be fairly invasive for screen.  I think
 it'd have to become setuid root, so it could request a new session.

Yeah that was my fear too.

Although perhaps this is just something that can be done via policy -
e.g. perhaps screen can just ask logind to create a new session for us
and then running some specific shell therein (i.e. a
screen@$newsid.service) then immediately attaching to it.

Perhaps this just needs something to control whether or not it's allowed
to ask logind for a shell. This can perhaps be something controlled by
system policy - e.g. you may be allowed but have to enter your password
again, or you may just be allowed without further auth.

I think eventually the semantics could be quite nice and could
potentially avoid the need for setuid but I don't really know the extent
of the needed infra here.

 Perhaps this is all OK, and the closing state here is not a problem.
 But such apps and use cases really are not compatible at all with the
 kill-session-processes= option of pam_systemd and it would be nice to do
 things properly.
 
 I believe that option is not the default precisely because of screen.

Makes sense.

 But anyways...we have to take some level of incrementalism here.
 Martin's patch is a very small and correct fix for a real-world problem.
 My patch is a bit more invasive, but I think it's going closer to the
 root of the problem.

Absolutely. It is just nice to get an overview of the bigger picture
here. Perhaps someone can start to write up a future of sessions wiki
page with a few notes on what is needed going forward.

Cheers

Col


-- 

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

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

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

On Tue, 2013-11-19 at 22:38 +, Colin Guthrie wrote:
 'Twas brillig, and Colin Walters at 19/11/13 18:13 did gyre and gimble:
  +d /run/user/0 0755 root root 10d
 
 This should probably be 0700 like the runtime dirs usually are I think.

Ooops =/  Fixed!

 Also won't this folder be naturally reaped in user_finalize() in
 login/logind-user.c:

Good point.  Should be fixed by this updated patch.  Thanks for the
careful review!

From e5871c84628528c7fa27b158d61eec04e6f1e022 Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Tue, 19 Nov 2013 10:21:16 -0500
Subject: [PATCH] login: Use correct XDG_RUNTIME_DIR for uid 0 with pkexec and similar

This fixes a special case of the more general issue of uid-changing
programs such as pkexec/su/sudo/runuser.  For the case where a user
logs into a desktop and then runs pkexec bash or sudo su - or
equivalent to become root, we should ensure that XDG_RUNTIME_DIR is
set.

Previous to this patch, we'd retain the incorrect XDG_RUNTIME_DIR from
the current session. There bad things can happen such as a uid 0
process writing files into uid 1000's runtime dir, corrupting it.

However, for changing to a *non-root* uid, we now leave
XDG_RUNTIME_DIR unset, because we cannot guarantee it exists for the
new uid.  This occurs with sudo mysql or variants as recommended by
some MySQL documentation.  But those tools long predate the runtime
dir, and they likely don't even use it.  If they do, the'll now just
fall back to the pre-runtime dir code.

Due to lifecycle issues, we only do this for root, by just ensuring
its runtime directory always exists from early startup.

See https://bugzilla.redhat.com/show_bug.cgi?id=753882
See http://lists.freedesktop.org/archives/systemd-devel/2013-November/014370.html
---
 src/login/logind-dbus.c |   26 +++---
 src/login/logind-user.c |   13 ++---
 src/login/logind.c  |   34 ++
 src/login/logind.h  |2 ++
 src/login/pam-module.c  |   10 ++
 5 files changed, 75 insertions(+), 10 deletions(-)

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 0f25e23..04fdaaf 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -553,10 +553,30 @@ static int method_create_session(sd_bus *bus, sd_bus_message *message, void *use
 if (session) {
 _cleanup_free_ char *path = NULL;
 _cleanup_close_ int fifo_fd = -1;
+const char *runtime_path;
 
 /* Session already exists, client is probably
- * something like su which changes uid but is still
- * the same session */
+ * something like su or pkexec which changes uid.
+ * Here we avoid creating a full new session (since we
+ * don't have child sessions), so we're just reusing
+ * the existing session data almost unchanged.
+ *
+ * One exception to this is the runtime path.  See
+ * https://bugzilla.redhat.com/show_bug.cgi?id=753882
+ * for some discussion.
+ */
+if (uid == 0) {
+/* For uid 0, we always have a runtime dir
+ * that's created early on logind startup.
+ */
+runtime_path = /run/user/0;
+} else {
+/* PAM module should treat this as unset; this means that
+ * in the case of e.g. su - mysql, there will be no XDG_RUNTIME_DIR.
+ * Which is likely fine for them.
+ */
+runtime_path = ;
+}
 
 fifo_fd = session_create_fifo(session);
 if (fifo_fd  0)
@@ -570,7 +590,7 @@ static int method_create_session(sd_bus *bus, sd_bus_message *message, void *use
 bus, message, soshsub,
 session-id,
 path,
-session-user-runtime_path,
+runtime_path,
 fifo_fd,
 session-seat ? session-seat-id : ,
 (uint32_t) session-vtnr,
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 6ba8d98..1045e86 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -484,9 +484,16 @@ static int user_remove_runtime_path(User *u) {
 if (!u-runtime_path)
 return 0;
 
-r = rm_rf(u-runtime_path, false, true, false);
-if (r  0)
-log_error(Failed to remove runtime directory %s: %s, u-runtime_path, strerror(-r));
+/* We keep root's runtime dir around, to ensure that
+ * we have an XDG_RUNTIME_DIR for su/sudo/pkexec.
+ * See

[systemd-devel] Is this the right group for me

2013-11-20 Thread Cecil Westerhof

I have to give a talk about systemd. My colleges are a ‘little’ negative 
about systemd. So I have some questions about systemd. Someone pointed 
me to this group, but because of the devel in the name, I was wondering 
if this would be the right place to post that kind of questions.


If you know about a better group …


Met vriendelijke groet,



Cecil Westerhof
Engineer
mobiel +31 - 6 - 25 00 38 81

--

Snow B.V.
Unix Specialists
De Ooyen 11
4191 PB Geldermalsen

http://www.snow.nl
tel. +31 - 345 - 65 66 66
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is this the right group for me

On Wed, Nov 20, 2013 at 7:24 PM, Cecil Westerhof
cecil.wester...@snow.nl wrote:
 I have to give a talk about systemd. My colleges are a ‘little’ negative
 about systemd. So I have some questions about systemd. Someone pointed me to
 this group, but because of the devel in the name, I was wondering if this
 would be the right place to post that kind of questions.

Sure, go ahead, just ask. All that could happen is that nobody answers. :)

Most of the active developers hang out on IRC on freenode #systemd, if
you want to chat instead of writing mails.

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

Re: [systemd-devel] Is this the right group for me

2013-11-20 Thread Tomasz Torcz

On Wed, Nov 20, 2013 at 07:24:18PM +0100, Cecil Westerhof wrote:
 I have to give a talk about systemd. My colleges are a ‘little’
 negative about systemd. So I have some questions about systemd.
 Someone pointed me to this group, but because of the devel in the
 name, I was wondering if this would be the right place to post that
 kind of questions.
 
 If you know about a better group …

  Well, there's always systemd community on G+:
https://plus.google.com/communities/114587707547576757881

  Generally, if your question isn't answered in manual pages
or Lennart's blog post, you can ask here.


-- 
Tomasz Torcz   72-|   80-|
xmpp: zdzich...@chrome.pl  72-|   80-|

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

Re: [systemd-devel] Is this the right group for me

2013-11-20 Thread Cecil Westerhof


On 11/20/2013 07:45 PM, Kay Sievers wrote:

I have to give a talk about systemd. My colleges are a ‘little’ negative
about systemd. So I have some questions about systemd. Someone pointed me to
this group, but because of the devel in the name, I was wondering if this
would be the right place to post that kind of questions.


Sure, go ahead, just ask. All that could happen is that nobody answers. :)

Most of the active developers hang out on IRC on freenode #systemd, if
you want to chat instead of writing mails.


That would also be a good idea. I only have two weeks and a lot of 
ground to cover.


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

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

2013-11-20 Thread Colin Guthrie

Hi,

Looks good generally but two very small points:


'Twas brillig, and Colin Walters at 20/11/13 17:34 did gyre and gimble:
 +/* Ensure the XDG_RUNTIME_DIR for root always exists, so that
 + * su/sudo/pkexec all do the right thing when changing to root.
 + */
 +static int ensure_root_runtime_path(void)
 +{
 +struct passwd *pw;
 +int r;
 +
 +pw = getpwuid(0);
 +if (!pw) {
 +/* No root in passwd? Okay, we won't make a runtime
 + * directory now then, maybe it's some wacky network
 + * setup and it'll appear later.
 + */
 +return 0;
 +}
 +
 +r = mkdir_safe_label(/run/user, 0755, 0, 0);
 +if (r  0) {
 +log_error(Failed to create /run/user: %s, strerror(-r));
 +return r;
 +}
 +
 +assert_se(pw-pw_uid == 0);


I see no side effect here... perhaps just use assert()? Also it would
feel better to go immediately after pw was populated rather than here
after the mkdir call, but maybe that's just me?

 +r = mkdir_safe_label(/run/user/0, 0700, pw-pw_uid, pw-pw_gid);
 +if (r  0)
 +return r;
 +return 0;
 +}
 +
  int main(int argc, char *argv[]) {
  Manager *m = NULL;
  int r;
 @@ -1172,12 +1203,15 @@ int main(int argc, char *argv[]) {
  mkdir_label(/run/systemd/users, 0755);
  mkdir_label(/run/systemd/sessions, 0755);
  
 +ensure_root_runtime_path();
 +
  m = manager_new();
  if (!m) {
  r = log_oom();
  goto finish;
  }
  
 +
  manager_parse_config_file(m);

Trivial, but unneeded whitespace addition I think.

All the best


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] Is this the right group for me

2013-11-20 Thread Cecil Westerhof


On 11/20/2013 07:54 PM, Cecil Westerhof wrote:

Most of the active developers hang out on IRC on freenode #systemd, if
you want to chat instead of writing mails.


That would also be a good idea. I only have two weeks and a lot of
ground to cover.


I had three major problems. I could move them to minor. I got a new 
major problem. But one is a lot better as three.


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

[systemd-devel] [HEADS-UP] PID 1 now ported to libsystemd-bus

Heya!

I just pushed a huge patch that ports the last remaining bit from
libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
lot of code. I did quite a bit of (personal and automated) testing but
given how large this is I am sure I broke something. So, please, be
careful around git for now, test it please, and don't be too surprised
if it is a bit rougher than usual, thanks!

Of course, this means we can now go on to the next step: boot without
dbus-daemon, and use kdbus instead.

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] [HEADS-UP] PID 1 now ported to libsystemd-bus

2013-11-20 Thread Peter Lemenkov

2013/11/21 Lennart Poettering lenn...@poettering.net:
 Heya!

 I just pushed a huge patch that ports the last remaining bit from
 libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
 lot of code. I did quite a bit of (personal and automated) testing but
 given how large this is I am sure I broke something. So, please, be
 careful around git for now, test it please, and don't be too surprised
 if it is a bit rougher than usual, thanks!

Great!

 Of course, this means we can now go on to the next step: boot without
 dbus-daemon, and use kdbus instead.

is it available in upstream kernel or should anyone interested use
some personal fork instead?



-- 
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] event: clear pending-state when re-arming timers

On Wed, 20.11.13 07:59, David Herrmann (dh.herrm...@gmail.com) wrote:

 If a timer fires and is marked pending, but an application re-arms it
 before it is dispatched, we now clear the pending state.
 
 This fixes a bug where an application arms a timer, which fires and is
 marked pending. But before it is dispatched, the application loses
 interest in it and disables it. Now if the timer is re-armed and
 re-enabled later, it will be immediately dispatched as it is still marked
 pending.
 
 This behavior is unexpected, so avoid it by clearing pending state when
 re-arming timers. Note that applications have no way to clear pending
 state themselves, so there's no current workaround.

Same mistake was actually was actually in the handling of changing of
the accuracy and of IO events too. Fixed those too now.

When you push a patch please reply to the mail you posted on
systemd-devel (if you posted one) and simply say Commited. or so, so
that it is easy for us to track what got already merged and what didn't!
Thanks!

 ---
  src/libsystemd-bus/sd-event.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/src/libsystemd-bus/sd-event.c b/src/libsystemd-bus/sd-event.c
 index 0996316..d01e82d 100644
 --- a/src/libsystemd-bus/sd-event.c
 +++ b/src/libsystemd-bus/sd-event.c
 @@ -1241,6 +1241,7 @@ _public_ int sd_event_source_set_time(sd_event_source 
 *s, uint64_t usec) {
  return 0;
  
  s-time.next = usec;
 +source_set_pending(s, false);
  
  if (s-type == SOURCE_REALTIME) {
  prioq_reshuffle(s-event-realtime_earliest, s, 
 s-time.earliest_index);


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] [HEADS-UP] PID 1 now ported to libsystemd-bus

2013-11-20 Thread Greg KH

On Thu, Nov 21, 2013 at 12:10:27AM +0400, Peter Lemenkov wrote:
 2013/11/21 Lennart Poettering lenn...@poettering.net:
  Heya!
 
  I just pushed a huge patch that ports the last remaining bit from
  libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
  lot of code. I did quite a bit of (personal and automated) testing but
  given how large this is I am sure I broke something. So, please, be
  careful around git for now, test it please, and don't be too surprised
  if it is a bit rougher than usual, thanks!
 
 Great!
 
  Of course, this means we can now go on to the next step: boot without
  dbus-daemon, and use kdbus instead.
 
 is it available in upstream kernel or should anyone interested use
 some personal fork instead?

It's in a separate repo, google 'kdbus' to find it.

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

Re: [systemd-devel] [HEADS-UP] PID 1 now ported to libsystemd-bus

On Thu, 21.11.13 00:10, Peter Lemenkov (lemen...@gmail.com) wrote:

 
 2013/11/21 Lennart Poettering lenn...@poettering.net:
  Heya!
 
  I just pushed a huge patch that ports the last remaining bit from
  libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
  lot of code. I did quite a bit of (personal and automated) testing but
  given how large this is I am sure I broke something. So, please, be
  careful around git for now, test it please, and don't be too surprised
  if it is a bit rougher than usual, thanks!
 
 Great!
 
  Of course, this means we can now go on to the next step: boot without
  dbus-daemon, and use kdbus instead.
 
 is it available in upstream kernel or should anyone interested use
 some personal fork instead?

We will not submit the kernel bits upstream before we haven't made sure
that the they are good enough to boot up a full system without loss of
functionality.

The kdbus kernel patches currently reside here:

http://code.google.com/p/d-bus/source/list

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] [HEADS-UP] PID 1 now ported to libsystemd-bus

2013-11-20 Thread Oleksii Shevchuk

 I just pushed a huge patch that ports the last remaining bit from
 libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
 lot of code. I did quite a bit of (personal and automated) testing but
 given how large this is I am sure I broke something. So, please, be
 careful around git for now, test it please, and don't be too surprised
 if it is a bit rougher than usual, thanks!

Segfaults on boot for me, after/at restoring hwrand. But leaks go away.
Will test at weekend..
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd / PID 1 leak

On Tue, 19.11.13 22:28, Colin Guthrie (gm...@colin.guthr.ie) wrote:

'Twas brillig, and Oleksii Shevchuk at 19/11/13 21:10 did gyre and gimble:
Valgrind

Any methodology for pid 1 valgrinding? How to start/gather information
for example?

Do you have any setup for that? Maybe I can clone it

Probably best to use systemd-nspawn and a container tree to boot a
virtual PID 1.

I don't know the correct commands to run but I think this is typically
the best approach.

Hmm, so I must admit I never tried running systemd as PID 1 in a
valgrind so far (only --user mode, and that daily). Turns out however,
that it actually works... Well, at least after I added this patch to systemd:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=54b434b1b5055f934230fe04fad35b01642b8488

That patch is needed since PID 1 execs the shutdown binary as last step
of shutdown which then will do the actual shutdown. However, valgrind
won't print any final summary then (it does so only if the original
process exit()s, not when it exec()s) which would make it quite
useless. Hence, in order to trigger the summary output this patch will
explicitly exit() from PID 1 rather than do the real shutdown if
valgrind is detected.

I tested this in a container:

systemd-nspawn -D /home/lennart/fedora-tree /usr/bin/valgrind --log-file=/log
/usr/lib/systemd/system

Of course, make sure to compile a version of systemd with that patch
applied in the container first, and make sure to install valgrind-devel
before that.

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][PATCH] conf-parser: distinguish between multiple sections with the same name

On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote:

 Pass on the line on which a section was decleared to the parsers, so they
 can distinguish between multiple sections (if they chose to). Currently
 no parsers take advantage of this, but a follow-up patch will do that
 to distinguish
 
 [Address]
 Address=192.168.0.1/24
 Label=one
 
 [Address]
 Address=192.168.0.2/24
 Label=two
 
 from
 
 [Address]
 Address=192.168.0.1/24
 Label=one
 Address=192.168.0.2/24
 Label=two

I do like this solution better, but I can see Thomas' point. And the
issue Thomas points out manifests itself in handling of .d/
directories... If we want to support .d/ directories for these
configuration files (do we?) then how can we extend the settings of a
specific existing [Address] section? 

So I do prefer the linear version above, but I see a problem with
it...

Hmm, what other options do we have? 

We could number things:

[Address.0]
...

[Address.1]
...

[Address.2]
...

and so on. I kinda like that too, but numbers might suck as ids? 

Maybe then back to labelled sections:

[Address:foobar]
Label=waldo
Address=1.1.1.1

or so, so that the suffix foobar is purely an id that is by default
disconnected from any setting? And then maybe optionally inherit it into
Label= if Label= is not explicitly set? 

Other ideas?

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] Restart instantiated services after suspend

On Tue, 19.11.13 14:18, Marcos Felipe Rasia de Mello (marcos...@gmail.com) 
wrote:

 Hi folks,
 
 I am trying to disable HDDs power management in a systemd way (aka no
 shell scripts :)
 
 /etc/udev/rules.d/99-hdparm.rules
 
 SUBSYSTEM==block, KERNEL==sd*, ATTR{removable}==0,
 TAG+=systemd, ENV{SYSTEMD_WANTS}+=hdparm@%k.service

Why do you do this asyncrhonously via a systemd service? Given that this
tool runs and terminates quickly invokign this with RUN inside of the
udev rule itself sounds like the best approach.

 It works fine, but after the machine wakes up from suspend, I need
 that all hdparm@.service be run again. Is there a way to accomplish
 this?

Well, you could drop in a service into sleep.target.wants/ which orders
itself after systemd-suspend.service...

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] remove duplicate includes

On Tue, 19.11.13 02:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 
 On Mon, Nov 18, 2013 at 02:48:14PM +0100, Karel Zak wrote:
  A few trivial patches... the duplications found by
  https://raw.github.com/karelzak/util-linux/master/tools/checkincludes.pl
 Wow. Applied in one big fell swoop.

I'd be happy to also apply a patch that adds that tool to our tree so
that we can easily rerun it again...

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 208:trouble with inactive user sessions at non-seat0 seats

2013-11-20 Thread David Herrmann

Hi

On Tue, Nov 19, 2013 at 7:13 PM, Laércio de Sousa lbsous...@gmail.com wrote:
 Hi there!

 I'm testing both Fedora 20 Beta and openSUSE 13.1 in my multiseat system
 (with GNOME 3.10, GDM 3.10.0.1 and systemd 208). I'm currently observing a
 strange behaviour which didn't occur in previous distro release (with GNOME
 3.8.4 and systemd 204).

 When I boot my system, gdm greeter session at both seat0 and non-seat0 seats
 are active, as expected. However, when a user logs in at a non-seat0 seat,
 the user session gets inactive. Nevertheless, I can activate it manually
 with command loginctl activate user-session-id, but if that user logs
 out, the new greeter session now becomes inactive.

 I suspect this strange behaviour is related to that generic multi-session
 support introduced in systemd 208. I can see that, when a user logs in, the
 greeter and user sessions coexist for a while, one at closing state and
 the other at online state, depending on whether the user logs in or out.

 What could it be? Lack of generic multi-session support in GDM?

I've appended a patch which avoids the situation without an active
session. Can you give it a try? I won't be able to test my multi-seat
setup before Sunday, sorry.

Thanks
David


diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index b30c4ce..d52e05b 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -228,7 +228,7 @@ int seat_apply_acls(Seat *s, Session *old_active) {
 }

 int seat_set_active(Seat *s, Session *session) {
-Session *old_active;
+Session *old_active, *i;

 assert(s);
 assert(!session || session-seat == s);
@@ -236,6 +236,13 @@ int seat_set_active(Seat *s, Session *session) {
 if (session == s-active)
 return 0;

+/* if no VTs, avoid having no active session */
+if (!seat_has_vts(s)  !session) {
+LIST_FOREACH(sessions_by_seat, i, s-sessions)
+if (i != s-active)
+session = s-active;
+}
+
 old_active = s-active;
 s-active = session;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] PID 1 now ported to libsystemd-bus

On Wed, Nov 20, 2013 at 9:08 PM, Lennart Poettering
lenn...@poettering.net wrote:
 Heya!

 I just pushed a huge patch that ports the last remaining bit from
 libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
 lot of code. I did quite a bit of (personal and automated) testing but
 given how large this is I am sure I broke something. So, please, be
 careful around git for now, test it please, and don't be too surprised
 if it is a bit rougher than usual, thanks!

I tried comparing latest git with v208 in systemd-nspawn.

I now get an almost (but not quite) 100% reproducible hang on poweroff
(until a timeout) with the message A stop job is running for User
Manager for 0. Is this a known problem?

The only other difference I noted was that it now pretty consistently
takes about one tenth of the time to boot into systemd-nspawn (10ms
against 100ms with v208), so that's something to keep in mind in case
the hang is caused by a race.

Cheers,

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

Re: [systemd-devel] [HEADS-UP] PID 1 now ported to libsystemd-bus

On Wed, 20.11.13 23:10, Tom Gundersen (t...@jklm.no) wrote:

 
 On Wed, Nov 20, 2013 at 9:08 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  Heya!
 
  I just pushed a huge patch that ports the last remaining bit from
  libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
  lot of code. I did quite a bit of (personal and automated) testing but
  given how large this is I am sure I broke something. So, please, be
  careful around git for now, test it please, and don't be too surprised
  if it is a bit rougher than usual, thanks!
 
 I tried comparing latest git with v208 in systemd-nspawn.
 
 I now get an almost (but not quite) 100% reproducible hang on poweroff
 (until a timeout) with the message A stop job is running for User
 Manager for 0. Is this a known problem?

Nope, haven't seen that yet...

 
 The only other difference I noted was that it now pretty consistently
 takes about one tenth of the time to boot into systemd-nspawn (10ms
 against 100ms with v208), so that's something to keep in mind in case
 the hang is caused by a race.
 
 Cheers,
 
 Tom


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] [HEADS-UP] PID 1 now ported to libsystemd-bus

On Wed, Nov 20, 2013 at 11:44 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 20.11.13 23:10, Tom Gundersen (t...@jklm.no) wrote:


 On Wed, Nov 20, 2013 at 9:08 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  Heya!
 
  I just pushed a huge patch that ports the last remaining bit from
  libdbus to libsystemd-bus: PID 1 itself. It's a large patch, touching a
  lot of code. I did quite a bit of (personal and automated) testing but
  given how large this is I am sure I broke something. So, please, be
  careful around git for now, test it please, and don't be too surprised
  if it is a bit rougher than usual, thanks!

 I tried comparing latest git with v208 in systemd-nspawn.

Booting latest git on bare metal I get:

Program terminated with signal 11, Segmentation fault.
#0  0x7fcc392be74b in raise () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x7fcc392be74b in raise () from /usr/lib/libpthread.so.0
#1  0x004068fa in crash (sig=11) at src/core/main.c:153
#2  signal handler called
#3  0x0043593a in socket_dispatch_io (source=0x9bc720, fd=24,
revents=1, userdata=0x9b0530) at src/core/socket.c:2044
#4  0x004add07 in source_dispatch (s=0x9bc720) at
src/libsystemd-bus/sd-event.c:1639
#5  0x004ae614 in sd_event_run (e=0x924ae0, timeout=0) at
src/libsystemd-bus/sd-event.c:1814
#6  0x00411356 in manager_loop (m=0x925c70) at src/core/manager.c:1694
#7  0x0040ab9a in main (argc=1, argv=0x7fff3f21a808) at
src/core/main.c:1647
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] PID 1 now ported to libsystemd-bus

On Wed, 20.11.13 23:58, Tom Gundersen (t...@jklm.no) wrote:

  I tried comparing latest git with v208 in systemd-nspawn.
 
 Booting latest git on bare metal I get:
 
 Program terminated with signal 11, Segmentation fault.
 #0  0x7fcc392be74b in raise () from /usr/lib/libpthread.so.0
 (gdb) bt
 #0  0x7fcc392be74b in raise () from /usr/lib/libpthread.so.0
 #1  0x004068fa in crash (sig=11) at src/core/main.c:153
 #2  signal handler called
 #3  0x0043593a in socket_dispatch_io (source=0x9bc720, fd=24,
 revents=1, userdata=0x9b0530) at src/core/socket.c:2044
 #4  0x004add07 in source_dispatch (s=0x9bc720) at
 src/libsystemd-bus/sd-event.c:1639
 #5  0x004ae614 in sd_event_run (e=0x924ae0, timeout=0) at
 src/libsystemd-bus/sd-event.c:1814
 #6  0x00411356 in manager_loop (m=0x925c70) at src/core/manager.c:1694
 #7  0x0040ab9a in main (argc=1, argv=0x7fff3f21a808) at
 src/core/main.c:1647

Should be fixed now.

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] Fix PAM module to not clobber XDG_RUNTIME_DIR with su

On Thu, 14.11.13 07:45, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello all,
 
 pam_systemd currently causes some havoc when you run programs or
 shells with su: it passes on the $XDG_RUNTIME_DIR from the original
 user session, so that programs like pulseaudio or dconf end up
 scribbling into the original user's runtime dir. This has been
 discussed at length at [1][2] and is leading people to consider
 workarounds like [3].
 
 It seems Lennart is against giving the new user a new logind session
 and runtime dir; I think it would be right to give it a fresh (or an
 already existing one for the target user) runtime dir, but in either
 case passing it the original user's runtime dir is actively wrong and
 harmful.

Well, that's quite arbitrary. What about dbus, X11, and so on, do you
plan to turn that off for the new session too?

If you leave access to X11 from the original session around, why isn't
PA also left around?

su is a hack, it is not clear what credentials it changes and which ones
it doesn't. It's entirely random what people think su should do, and
it's a security nightmare, as nobody knows the environment programs run
in anymore, there's no chance to get this done correctly.

Quit frankly, I am pretty sure the best approach is to simply prohibit
running graphical applications from su sessions, it's never going to
work. Letting other user access some (but not all) of a private user's
bits and pieces is never going to work if those bits and pieces are
nowadays a mix of dconf, X11, PA, dbus, security creds, keyrings, yadda
yada...

 Until then I recommend applying this patch (or something equivalent)
 which at least stops destroying existing runtime dirs and makes it
 compliant to the spec [4]. With that, things like pulse, dconf, or
 dbus will still need to keep their internal fallback if there is no
 runtime dir, but that's a less pressing matter.

So, what's the intention here? That XDG_RUNTIME_DIR is entirely unset
after su? That sounds kinda acceptable to me.

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] [HEADS-UP] PID 1 now ported to libsystemd-bus

On Thu, Nov 21, 2013 at 12:06 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 20.11.13 23:58, Tom Gundersen (t...@jklm.no) wrote:

  I tried comparing latest git with v208 in systemd-nspawn.

 Booting latest git on bare metal I get:

 Program terminated with signal 11, Segmentation fault.
 #0  0x7fcc392be74b in raise () from /usr/lib/libpthread.so.0
 (gdb) bt
 #0  0x7fcc392be74b in raise () from /usr/lib/libpthread.so.0
 #1  0x004068fa in crash (sig=11) at src/core/main.c:153
 #2  signal handler called
 #3  0x0043593a in socket_dispatch_io (source=0x9bc720, fd=24,
 revents=1, userdata=0x9b0530) at src/core/socket.c:2044
 #4  0x004add07 in source_dispatch (s=0x9bc720) at
 src/libsystemd-bus/sd-event.c:1639
 #5  0x004ae614 in sd_event_run (e=0x924ae0, timeout=0) at
 src/libsystemd-bus/sd-event.c:1814
 #6  0x00411356 in manager_loop (m=0x925c70) at 
 src/core/manager.c:1694
 #7  0x0040ab9a in main (argc=1, argv=0x7fff3f21a808) at
 src/core/main.c:1647

 Should be fixed now.

Yup, thanks.

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

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

On Tue, 19.11.13 10:42, Colin Walters (walt...@verbum.org) wrote:

 My patch though starts to pave the way for having XDG_RUNTIME_DIR
 consistently point to that of the user's uid

I think this is just bogus. You used su. So the UID was changed and
little else. Now you start patchign XDG_RUNTIME_DIR too, but what about
access to X11? This kind of mix and match is just really really
broken, since in many cases there are connections beteween the
facilities people use. i.e. some apps require that dbus, x11, pa and
XDG_RUNTIME_DIR are always run in the same combination. For example,
dconf requires dbus and XDG_RUNTIME_DIR to stay in sync. PA requires
expects XDG_RUNTIME_DIR and X11 to be ins ync. dbus mantains X11 root
window creds, so binds things together with X11. So yeah, there your mix
and match is broken: if you switch over some things of it things
break... And if we don't get this right for the lower level components,
how on earth do you think that non-trivial user applicatins will ever
get this right?

It's so entirely arbitrary switching some things over and others not. I
am pretty sure the only sensible thing is to say that su and sudo
are minimal, and doesn't switch anything over but the bare minimum,
which is the UID. It stays inside the same XDG_RUNTIME_DIR, PA, X11,
dbus, logind session id and so on.

And then, make su - and sudo -s switch over as much as possible,
i.e. XDG_RUNTIME_DIR, PA, X11, dbus, logind session id.

For that, add a new parameter to pam_systemd maybe
force-new-session=yes/no or so which is set in su -'s PAM config
stack, but not in su's PAM config stack (luckily they are stored in
two separate files). When the boolean is set, the session ID is not
created from the existing session, but a new independent one is made up.

I offered this somewhere in rhbz alread...

Note however, that his will not allow people to su to another user and
then run firefox from there. If they do that with su - the display and
audio should have been disconnected. If they do that with su, then the
app won't be able to access much in XDG_RUNTIME_DIR...

Lennart

 

 From 7fe51a82a5cc1ad2185b4ee4faa087f17e27d24a Mon Sep 17 00:00:00 2001
 From: Colin Walters walt...@verbum.org
 Date: Tue, 19 Nov 2013 10:21:16 -0500
 Subject: [PATCH] login: Make XDG_RUNTIME_DIR match target uid with 
 pkexec/sudo/su
 
 These get attached to the same session, but we should ensure that the
 XDG_RUNTIME_DIR is matches the new uid.  Otherwise bad things can
 happen such as a uid 0 process writing files into uid 1000's runtime
 dir, corrupting it.
 
 This patch currently has the semantics that if you log in via e.g. gdm
 as non-root and then use pkexec, the new shell will have *no*
 XDG_RUNTIME_DIR.
 
 If however root is logged in for real elsewhere via getty or ssh,
 then the XDG_RUNTIME_DIR will be set.  However, once root logs out,
 that directory will be garbage collected, which is probably
 undesirable.  We could either:
 
 1) Attempt to make pkexec/su/sudo have real sessions (invasive)
 2) Drop this hunk of the patch, and *always* leave XDG_RUNTIME_DIR
unset (simple)
 3) Add internal refcounting for XDG_RUNTIME_DIR such that the user
session holds a ref on the root-owned runtime dir (fairly noninvasive)
 ---
  src/login/logind-dbus.c |   17 ++---
  src/login/pam-module.c  |   10 ++
  2 files changed, 20 insertions(+), 7 deletions(-)
 
 diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
 index 0f25e23..397750d 100644
 --- a/src/login/logind-dbus.c
 +++ b/src/login/logind-dbus.c
 @@ -553,10 +553,21 @@ static int method_create_session(sd_bus *bus, 
 sd_bus_message *message, void *use
  if (session) {
  _cleanup_free_ char *path = NULL;
  _cleanup_close_ int fifo_fd = -1;
 +User *target_user;
 +const char *runtime_path;
  
  /* Session already exists, client is probably
 - * something like su which changes uid but is still
 - * the same session */
 + * something like su which changes uid.  We want to join
 + * it to the same session.  One exception to this is the 
 runtime
 + * path.
 + * See https://bugzilla.redhat.com/show_bug.cgi?id=753882
 + * for some discussion.
 + */
 +target_user = hashmap_get(m-users, ULONG_TO_PTR((unsigned 
 long) uid));
 +if (target_user)
 +runtime_path = target_user-runtime_path;
 +else
 +runtime_path = ;  /* PAM module should treat this 
 as unset */
  
  fifo_fd = session_create_fifo(session);
  if (fifo_fd  0)
 @@ -570,7 +581,7 @@ static int method_create_session(sd_bus *bus, 
 sd_bus_message *message, void *use
  bus, message, soshsub,
  session-id,

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

On Tue, 19.11.13 13:13, Colin Walters (walt...@verbum.org) wrote:

 Anyways, new tested patch attached.  Lennart, any objections?

Yes. Let's not tape over problems and pretend things could work if we
freely mix and match things.

I do like Martin's original patch, since by unsetting XDG_RUNTIME_DIR it
basically tells apps Hey, all bets are off, you are fucked, and
doesn't pretend XDG_RUNTIME_DIR would still work. Because it doesn't.

The other thing, as mentioned before that I'd be willing to do is turn
su - and sudo -s into something that creates an entirely new logind
session that is detached from the audit session. (see other mail).

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] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

2013/11/21 Lennart Poettering lenn...@poettering.net:
 For that, add a new parameter to pam_systemd maybe
 force-new-session=yes/no or so which is set in su -'s PAM config
 stack, but not in su's PAM config stack (luckily they are stored in
 two separate files).

This is not the case for Debian based distros, fwiw. There is only a
single /etc/pam.d/su config file:

fedora:
# ls /etc/pam.d/su*
/etc/pam.d/su  /etc/pam.d/sudo  /etc/pam.d/sudo-i  /etc/pam.d/su-l

debian:
# ls /etc/pam.d/su*
/etc/pam.d/su  /etc/pam.d/sudo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

On Thu, 2013-11-21 at 00:32 +0100, Lennart Poettering wrote:
 On Tue, 19.11.13 10:42, Colin Walters (walt...@verbum.org) wrote:
 
  My patch though starts to pave the way for having XDG_RUNTIME_DIR
  consistently point to that of the user's uid
 
 I think this is just bogus. You used su. 

I use pkexec, not su.  One important difference between them is
pkexec *always* clears the environment to a whitelisted set.

Please don't confuse my targeted fix with the larger you group
of people from the RHBZ.

 So the UID was changed and
 little else. Now you start patchign XDG_RUNTIME_DIR too, but what about
 access to X11? This kind of mix and match is just really really
 broken, 

I agree.  I have no intention to change pkexec to allow access to
X11. 

 For example,
 dconf requires dbus and XDG_RUNTIME_DIR to stay in sync. 

The case of dbus and XDG_RUNTIME_DIR is of course interesting because
in the user bus future, XDG_RUNTIME_DIR will give access to DBus.

But concretely right now what will happen with pkexec + app that uses
dconf is quite simple - GDBus will notice there's no
DBUS_SESSION_BUS_ADDRESS (because again, pkexec cleared it), try to
autolaunch one which will attempt to contact $DISPLAY, and *fail*.

And that's fine by me.

 PA requires
 expects XDG_RUNTIME_DIR and X11 to be ins ync.

I am not talking about making PA work or its synchronization to X11.

  dbus mantains X11 root
 window creds, so binds things together with X11. 

I am not talking about proxying or inheriting $DISPLAY.  I
am talking about pkexec.

 So yeah, there your mix
 and match is broken: 

I'm proposing a simple goal: XDG_RUNTIME_DIR should always be that
matching the current uid.  I can't think of any case where you'd
want it otherwise.

(Really ideally this would be in the kernel - if a process with uid N
 exists, it can access /run/user/N)

 It's so entirely arbitrary switching some things over and others not. 

Again from my perspective as a pkexec maintainer, it is now totally
consistent with this patch.

 am pretty sure the only sensible thing is to say that su and sudo
 are minimal, and doesn't switch anything over but the bare minimum,
 which is the UID. It stays inside the same XDG_RUNTIME_DIR, PA, X11,
 dbus, logind session id and so on.

I'm not talking about non-environment-clearing su/sudo.  

 And then, make su - and sudo -s switch over as much as possible,
 i.e. XDG_RUNTIME_DIR, PA, X11, dbus, logind session id.

Er...why would you have PA and X11 for su -?

(Now of course with the user@.service patches I was working on,
 things like libX11 pick up the address from XDG_RUNTIME_DIR, whiich
 would mean you *do* get those if you've already logged in as the
 target user)

 For that, add a new parameter to pam_systemd maybe
 force-new-session=yes/no or so which is set in su -'s PAM config
 stack, but not in su's PAM config stack (luckily they are stored in
 two separate files). 

In my case, I'm happy to change pkexec to pass such a flag.

 Note however, that his will not allow people to su to another user and
 then run firefox from there. 

Yes, and I think that use case is crack; I'm not talking about fixing
it.  I care about pkexec.


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

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

2013/11/18 Michael Stapelberg stapelb...@debian.org:
 This is a rather pressing issue for us (it breaks GDM logins in some
 cases), and we’d like to fix it by cherry-picking a patch that was
 merged upstream.

some cases is very vague. Reading through the gdm bug report (or the
one re-assigned to libpam-systemd) it's actually not clear to me what
exactly causes gdm to fail and under which conditions.

Would probably be best to dig deeper here and find the root cause.
gdm is working just fine here, fwiw.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

On Thu, 2013-11-21 at 00:36 +0100, Lennart Poettering wrote:
 On Tue, 19.11.13 13:13, Colin Walters (walt...@verbum.org) wrote:
 
  Anyways, new tested patch attached.  Lennart, any objections?
 
 Yes. Let's not tape over problems and pretend things could work if we
 freely mix and match things.

I am not freely mixing and matching.  I am solely targeting
XDG_RUNTIME_DIR.

 I do like Martin's original patch, since by unsetting XDG_RUNTIME_DIR it
 basically tells apps Hey, all bets are off, you are fucked, and
 doesn't pretend XDG_RUNTIME_DIR would still work. Because it doesn't.

My patch *also* unsets it for every uid except 0, which I make always
work.  Did you read it?  Under what scenarios will my patch cause
failures that did not already exist?




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

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

On Thu, 2013-11-21 at 01:20 +0100, Michael Biebl wrote:
 2013/11/18 Michael Stapelberg stapelb...@debian.org:
  This is a rather pressing issue for us (it breaks GDM logins in some
  cases), and we’d like to fix it by cherry-picking a patch that was
  merged upstream.
 
 some cases is very vague.

See:
https://bugzilla.redhat.com/show_bug.cgi?id=753882#c43

Now as Lennart is arguing here, running gedit as root is crack.  But
the problem is greatly exacerbated by systemd leaving XDG_RUNTIME_DIR as
the user, which causes the root-owned process to write to it,
leaving directories owned by root whch can't be deleted by the user.

But if say you happen to be logged in via ssh or a getty as well,
that broken dconf directory will persist until you log out everywhere,
and it will break logging in via gdm.

This can happen with just pure pkexec and a *non-X11* application
which wants to save transient per-uid state.





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

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

2013/11/21 Colin Walters walt...@verbum.org:
 On Thu, 2013-11-21 at 01:20 +0100, Michael Biebl wrote:
 2013/11/18 Michael Stapelberg stapelb...@debian.org:
  This is a rather pressing issue for us (it breaks GDM logins in some
  cases), and we’d like to fix it by cherry-picking a patch that was
  merged upstream.

 some cases is very vague.

 See:
 https://bugzilla.redhat.com/show_bug.cgi?id=753882#c43

I was referring to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729674#90
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724731

which supposedly breaks gdm logins.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

2013/11/21 Colin Walters walt...@verbum.org:
 On Thu, 2013-11-21 at 01:20 +0100, Michael Biebl wrote:
 2013/11/18 Michael Stapelberg stapelb...@debian.org:
  This is a rather pressing issue for us (it breaks GDM logins in some
  cases), and we’d like to fix it by cherry-picking a patch that was
  merged upstream.

 some cases is very vague.

 See:
 https://bugzilla.redhat.com/show_bug.cgi?id=753882#c43

 Now as Lennart is arguing here, running gedit as root is crack.  But
 the problem is greatly exacerbated by systemd leaving XDG_RUNTIME_DIR as
 the user, which causes the root-owned process to write to it,
 leaving directories owned by root whch can't be deleted by the user.

 But if say you happen to be logged in via ssh or a getty as well,
 that broken dconf directory will persist until you log out everywhere,
 and it will break logging in via gdm.

 This can happen with just pure pkexec and a *non-X11* application
 which wants to save transient per-uid state.

Hm, yeah, that might be it.
I guess one would have to ask the bug reporters if they had used su to
start a root X application (in case they remember) and if the problem
goes away after a reboot, i.e. /run has been reset.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

2013/11/21 Michael Biebl mbi...@gmail.com:
 Hm, yeah, that might be it.
 I guess one would have to ask the bug reporters if they had used su to
 start a root X application (in case they remember) and if the problem
 goes away after a reboot, i.e. /run has been reset.

Actually, starting a root X application via su doesn't explain that
gdm fails to start, at least I don't see how.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote:

 Pass on the line on which a section was decleared to the parsers, so they
 can distinguish between multiple sections (if they chose to). Currently
 no parsers take advantage of this, but a follow-up patch will do that
 to distinguish

 [Address]
 Address=192.168.0.1/24
 Label=one

 [Address]
 Address=192.168.0.2/24
 Label=two

 from

 [Address]
 Address=192.168.0.1/24
 Label=one
 Address=192.168.0.2/24
 Label=two

 I do like this solution better, but I can see Thomas' point. And the
 issue Thomas points out manifests itself in handling of .d/
 directories... If we want to support .d/ directories for these
 configuration files (do we?) then how can we extend the settings of a
 specific existing [Address] section?

My take was that we do not want to support .d/ directories, in which
case unnamed sections would be fine, right? (i.e., as long as we only
ever consider one file at a time). Essentially I think it would be ok
to just tell people to copy the .network file to /etc and edit it
there.

If, on the other hand, we do want to allow .d/ directories in the
future, I think I'd advocate allowing both named and unnamed sections
(where only the named ones can be overridden of course). Notice that
we already encounter a similar overriding issue with the plain
Address= and Gateway= entries from the [Network] section, which can
not be accessed individually from .d/ fragments (but possibly cleared
altogether, as we allow in similar situations elsewhere).

I guess the normal use-case would then be that .nework files created
by admins would mostly (only) use the unnamed sections, as it is
simpler/neater and won't be something you'd ever override, but stuff
shipped by packages could use the named sections where overriding
might possibly make sense.

 So I do prefer the linear version above, but I see a problem with
 it...

 Hmm, what other options do we have?

 We could number things:

 [Address.0]
 ...

 [Address.1]
 ...

 [Address.2]
 ...

 and so on. I kinda like that too, but numbers might suck as ids?

Yes, I guess for someone writing the .d/ fragment it is annoying to
have to remember the number. So for something we expect could be
overridden, descriptive names would be best.

 Maybe then back to labelled sections:

 [Address:foobar]
 Label=waldo
 Address=1.1.1.1

 or so, so that the suffix foobar is purely an id that is by default
 disconnected from any setting? And then maybe optionally inherit it into
 Label= if Label= is not explicitly set?

I think the section name should not have any other function/meaning. I
first tried to make 'section name'='Label', but I'm worried it might
be confusing: If section names are required, it means we now require
labeling, or force the admin to set Label= to disable it, which
seems a bit weird. Also, I find it asymmetric the way section names
for Addresses have this extra meaning, but for Routes or other types
of sections where there is no natural equivalent to Label=, they have
no meaning apart from a name.

I'm really not convinced one way or the other, but I think my
preferred solution is: go with unnamed sections now, and if ever it
becomes necessary, introduce named ones additionally.

If we end up adding named sections, I do see the possible confusion of
oh, I have to name these before I can override them...?. But if we
force always to name them I see people using 'random' strings foo,
bar, baz, rtyrty, tryytr, and at some point getting lost
in what strings they have used and accidentally reusing strings (of
course the clever person would in this case name the sections 1,
2, 3, etc). Basically, my concern is that there is not a big step
from requiring the user to invent unique strings to requiring
UUID's...

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

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

2013-11-20 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Nov 21, 2013 at 02:27:28AM +0100, Tom Gundersen wrote:
 On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote:
 
  Pass on the line on which a section was decleared to the parsers, so they
  can distinguish between multiple sections (if they chose to). Currently
  no parsers take advantage of this, but a follow-up patch will do that
  to distinguish
 
  [Address]
  Address=192.168.0.1/24
  Label=one
 
  [Address]
  Address=192.168.0.2/24
  Label=two
 
  from
 
  [Address]
  Address=192.168.0.1/24
  Label=one
  Address=192.168.0.2/24
  Label=two
 
  I do like this solution better, but I can see Thomas' point. And the
  issue Thomas points out manifests itself in handling of .d/
  directories... If we want to support .d/ directories for these
  configuration files (do we?) then how can we extend the settings of a
  specific existing [Address] section?
 
 My take was that we do not want to support .d/ directories,
udev supports overrides, tmpfiles support them too, so do systemd
units, and sysctl settings. I'm pretty sure we can assume that
overrides for network files will happen sooner or later. Also, it's
not just /etc/...  overriddes, but also /run/... overrides, for
until-reboot settings.

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

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

On Thu, Nov 21, 2013 at 2:39 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Thu, Nov 21, 2013 at 02:27:28AM +0100, Tom Gundersen wrote:
 On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote:
 
  Pass on the line on which a section was decleared to the parsers, so they
  can distinguish between multiple sections (if they chose to). Currently
  no parsers take advantage of this, but a follow-up patch will do that
  to distinguish
 
  [Address]
  Address=192.168.0.1/24
  Label=one
 
  [Address]
  Address=192.168.0.2/24
  Label=two
 
  from
 
  [Address]
  Address=192.168.0.1/24
  Label=one
  Address=192.168.0.2/24
  Label=two
 
  I do like this solution better, but I can see Thomas' point. And the
  issue Thomas points out manifests itself in handling of .d/
  directories... If we want to support .d/ directories for these
  configuration files (do we?) then how can we extend the settings of a
  specific existing [Address] section?

 My take was that we do not want to support .d/ directories,

 udev supports overrides, tmpfiles support them too, so do systemd
 units, and sysctl settings. I'm pretty sure we can assume that
 overrides for network files will happen sooner or later. Also, it's
 not just /etc/...  overriddes, but also /run/... overrides, for
 until-reboot settings.


Nah, this is only about fragment drop-ins, they are only supported by
unit files.

The network files surely support individual files in a directory, but
not fragments to overwrite parts of a file.

As mentioned earlier, network files are like udev rules, the file name
is meaningless, so .d/ fragment drop-ins make not much sense here.

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

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

Just to suggest the wildly different approach I mentioned on IRC, we
could treat addresses (including DHCP) as the main units and then
specify the backing hardware as part of the address's configuration.
This would be particularly useful for bridges.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

On Thu, Nov 21, 2013 at 11:48 AM, David Timothy Strauss
da...@davidstrauss.net wrote:
 This would be particularly useful for bridges.

Actually, I meant bonded interfaces, not bridges.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] build fix: add RT_LIBS to link against for test-bus-marshal

2013-11-20 Thread Yin Kangkai

Otherwise, build fail:

/usr/bin/ld: ./.libs/libsystemd-daemon-internal.a(sd-daemon.o): undefined 
reference to symbol 'mq_getattr@@GLIBC_2.3.4'
/usr/bin/ld: note: 'mq_getattr@@GLIBC_2.3.4' is defined in DSO /lib/librt.so.1 
so try adding it to the linker command line
/lib/librt.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: *** [test-bus-marshal] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Signed-off-by: Yin Kangkai kangkai@intel.com
---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index f7fe96c..f0193e9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2008,7 +2008,8 @@ test_bus_marshal_LDADD = \
libsystemd-capability.la \
$(GLIB_LIBS) \
$(DBUS_LIBS) \
-   $(CAP_LIBS)
+   $(CAP_LIBS) \
+   $(RT_LIBS)
 
 test_bus_marshal_CFLAGS = \
$(AM_CFLAGS) \
-- 
1.8.2.1

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

Re: [systemd-devel] [PATCH] build fix: add RT_LIBS to link against for test-bus-marshal

I often get this when I have a dirty build. Have you tried a fully clean build?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Newbie question - Requires doesn't work properly

The service configuration is strange. Normally, this is how they work
with dependencies:

 * Type=simple considers the service started immediately on exec()
with no respect for PIDFiles or sd_notify. This can cause dependent
services to come up too early.
 * Type=forking considers the service started when either the file
specified in PIDFile= appears or when the service completes a double
fork.
 * Type=notify is like Type=simple, except that it relies on sd_notify
to indicate final startup.
 * Type=bus is like Type=simple, except that it waits for the dbus
listener to indicate final startup.

You have PIDFile= specified, which is for Type=forking. I think
PIDFile= just gets ignored for Type=simple (the default). So, for one,
I'd pick a more coherent startup-detection configuration.

More interesting is how Myservice gets marked failed but isn't
forcibly stopped. That may be why systemd isn't bringing down
dependent services. Most services only get marked failed after
stopping (because of a non-zero exit code, for example).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fix PAM module to not clobber XDG_RUNTIME_DIR with su

2013-11-20 Thread Tollef Fog Heen

]] Lennart Poettering 

 Well, that's quite arbitrary. What about dbus, X11, and so on, do you
 plan to turn that off for the new session too?

Yes, please.

In the following, I'm talking about «su -» not plain «su», which I think
should go away since the semantics are woolen.

 su is a hack, it is not clear what credentials it changes and which ones
 it doesn't. It's entirely random what people think su should do, and
 it's a security nightmare, as nobody knows the environment programs run
 in anymore, there's no chance to get this done correctly.

I don't see it as any more arbitrary than login or ssh.  (ssh can
transfer a bunch of credentials just fine, think Kerberos GSSAPI
delegation or agent forwarding.)  That we're not tracking loginuid
across the network is just a limitation of the tools, there's nothing
inherent which says that we should stop at a host boundary.  Older,
weaker protocols exist for tracking that, such as ident.

 Quit frankly, I am pretty sure the best approach is to simply prohibit
 running graphical applications from su sessions, it's never going to
 work. Letting other user access some (but not all) of a private user's
 bits and pieces is never going to work if those bits and pieces are
 nowadays a mix of dconf, X11, PA, dbus, security creds, keyrings, yadda
 yada...

If you want to run graphical applications through su, you need to do
xhost +SI:localuser:$newuser and set DISPLAY correctly.  That's fine,
and I think requiring people to do so is fine.

  Until then I recommend applying this patch (or something equivalent)
  which at least stops destroying existing runtime dirs and makes it
  compliant to the spec [4]. With that, things like pulse, dconf, or
  dbus will still need to keep their internal fallback if there is no
  runtime dir, but that's a less pressing matter.
 
 So, what's the intention here? That XDG_RUNTIME_DIR is entirely unset
 after su? That sounds kinda acceptable to me.

Either unset or set to the new user's XDG_RUNTIME_DIR.  The main point
is «it should not be wrong» (which it is today).  If we can make it
point somewhere sensible that's a bonus, but not required.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Newbie question - Requires doesn't work properly

2013-11-20 Thread salil GK

Thanks David and Zbyszek

Yes with BindsTo parameter it works

David

   I was trying out the options in the unit file hence PID parameter came
in. I forgot to remove that later :-(


some  more questions in the same thread -

1. How do I trace the heartbeat message - or rather can I capture the
systemd-notify messages being sent by the process.
2. Is there any way I can see whether systemd captured the notification
or missed it. The reason why I am asking this is - my process runs for some
time and all the while it sends WATCHDOG notification in every 5 seconds.
But systemd made the process failed saying  watchdog timeout.
3. One more use case I can think of is - if the process fail to send
heartbeat message ( WATCHDOG ) for some time and later it starts sending -
because of some time. So during the time WATCHDOG notification is missing
process can be marked as failed and the moment notification start coming,
can it be marked as active-running ?
4. Is there way systemd can notify me in case a watchdog timeout
happens for a service - like systemd calls some program or write to some
socket etc. So basically in case any service fails because of watchdog
timeout, I would like to know asynchronously. Is there any way I can
configure this.

Thanks
Salil


On 21 November 2013 09:02, David Timothy Strauss da...@davidstrauss.netwrote:

 The service configuration is strange. Normally, this is how they work
 with dependencies:

  * Type=simple considers the service started immediately on exec()
 with no respect for PIDFiles or sd_notify. This can cause dependent
 services to come up too early.
  * Type=forking considers the service started when either the file
 specified in PIDFile= appears or when the service completes a double
 fork.
  * Type=notify is like Type=simple, except that it relies on sd_notify
 to indicate final startup.
  * Type=bus is like Type=simple, except that it waits for the dbus
 listener to indicate final startup.

 You have PIDFile= specified, which is for Type=forking. I think
 PIDFile= just gets ignored for Type=simple (the default). So, for one,
 I'd pick a more coherent startup-detection configuration.

 More interesting is how Myservice gets marked failed but isn't
 forcibly stopped. That may be why systemd isn't bringing down
 dependent services. Most services only get marked failed after
 stopping (because of a non-zero exit code, for example).

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

Re: [systemd-devel] Newbie question - Requires doesn't work properly