date:20141027

---
 src/shared/calendarspec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 8e6c871..ec84d65 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -907,6 +907,10 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
**spec) {
 if (r  0)
 goto fail;
 
+r = parse_months(p, c);
+if (r  0)
+goto fail;
+
 r = parse_date(p, c);
 if (r  0)
 goto fail;
-- 
1.9.3

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

[systemd-devel] [PATCH 1/7] calendar: add constant values

---
 src/shared/calendarspec.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 64d0dec..73f87c6 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -24,6 +24,12 @@
 
 #include calendarspec.h
 
+#define CENTURY_ONE 1900
+#define CENTURY_TWO 2000
+#define CENTURY_GAP 70
+#define BITS_WEEKDAYS  127
+#define BITS_MONTHS127
+
 static void free_chain(CalendarComponent *c) {
 CalendarComponent *n;
 
@@ -107,11 +113,11 @@ static void fix_year(CalendarComponent *c) {
 while(c) {
 CalendarComponent *n = c-next;
 
-if (c-value = 0  c-value  70)
-c-value += 2000;
+if (c-value = 0  c-value  CENTURY_GAP)
+c-value += CENTURY_TWO;
 
-if (c-value = 70  c-value  100)
-c-value += 1900;
+if (c-value = CENTURY_GAP  c-value  100)
+c-value += CENTURY_ONE;
 
 c = n;
 }
@@ -157,7 +163,9 @@ _pure_ bool calendar_spec_valid(CalendarSpec *c) {
 if (c-weekdays_bits  127)
 return false;
 
-if (!chain_valid(c-year, 1970, 2199))
+if (!chain_valid(c-year,
+   (CENTURY_ONE + CENTURY_GAP),
+   (CENTURY_TWO + CENTURY_GAP)))
 return false;
 
 if (!chain_valid(c-month, 1, 12))
@@ -847,9 +855,9 @@ static int find_next(const CalendarSpec *spec, struct tm 
*tm) {
 mktime(c);
 c.tm_isdst = -1;
 
-c.tm_year += 1900;
+c.tm_year += CENTURY_ONE;
 r = find_matching_component(spec-year, c.tm_year);
-c.tm_year -= 1900;
+c.tm_year -= CENTURY_ONE;
 
 if (r  0) {
 c.tm_mon = 0;
-- 
1.9.3

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

[systemd-devel] [PATCH 4/7] calendar: new case 'minutely'

---
 src/shared/calendarspec.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 196a330..6186301 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -833,7 +833,12 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
**spec) {
 if (!c)
 return -ENOMEM;
 
-if (strcaseeq(p, hourly)) {
+if (strcaseeq(p, minutely)) {
+r = const_chain(0, c-second);
+if (r  0)
+goto fail;
+
+} else if (strcaseeq(p, hourly)) {
 r = const_chain(0, c-minute);
 if (r  0)
 goto fail;
-- 
1.9.3

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

[systemd-devel] [PATCH 5/7] calendar: re-ordering 'weekly'

---
 src/shared/calendarspec.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 6186301..fae7dfd 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -857,10 +857,10 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
**spec) {
 if (r  0)
 goto fail;
 
-} else if (strcaseeq(p, monthly)) {
-r = const_chain(1, c-day);
-if (r  0)
-goto fail;
+} else if (strcaseeq(p, weekly)) {
+
+c-weekdays_bits = 1;
+
 r = const_chain(0, c-hour);
 if (r  0)
 goto fail;
@@ -871,11 +871,7 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
**spec) {
 if (r  0)
 goto fail;
 
-} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)
-   || strcaseeq(p, anually) /* backwards compatibility */ ) {
-r = const_chain(1, c-month);
-if (r  0)
-goto fail;
+} else if (strcaseeq(p, monthly)) {
 r = const_chain(1, c-day);
 if (r  0)
 goto fail;
@@ -889,10 +885,14 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
**spec) {
 if (r  0)
 goto fail;
 
-} else if (strcaseeq(p, weekly)) {
-
-c-weekdays_bits = 1;
-
+} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)
+   || strcaseeq(p, anually) /* backwards compatibility */ ) {
+r = const_chain(1, c-month);
+if (r  0)
+goto fail;
+r = const_chain(1, c-day);
+if (r  0)
+goto fail;
 r = const_chain(0, c-hour);
 if (r  0)
 goto fail;
-- 
1.9.3

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

[systemd-devel] [PATCH 3/7] calendar: functions and callings to handle the months's labels

---
 src/shared/calendarspec.c | 198 ++
 src/shared/calendarspec.h |   1 +
 2 files changed, 199 insertions(+)

diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 67fd76a..196a330 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -129,6 +129,9 @@ int calendar_spec_normalize(CalendarSpec *c) {
 if (c-weekdays_bits = 0 || c-weekdays_bits = BITS_WEEKDAYS)
 c-weekdays_bits = -1;
 
+if (c-months_bits = 0 || c-months_bits = BITS_MONTHS)
+c-months_bits = -1;
+
 fix_year(c-year);
 
 sort_chain(c-year);
@@ -163,6 +166,9 @@ _pure_ bool calendar_spec_valid(CalendarSpec *c) {
 if (c-weekdays_bits  BITS_WEEKDAYS)
 return false;
 
+if (c-months_bits  BITS_MONTHS)
+return false;
+
 if (!chain_valid(c-year,
(CENTURY_ONE + CENTURY_GAP),
(CENTURY_TWO + CENTURY_GAP)))
@@ -235,6 +241,60 @@ static void format_weekdays(FILE *f, const CalendarSpec 
*c) {
 }
 }
 
+static void format_months(FILE *f, const CalendarSpec *c) {
+static const char *const months[] = {
+Jan,
+Feb,
+Mar,
+Apr,
+May,
+Jun,
+Jul,
+Aug,
+Sep,
+Oct,
+Nov,
+Dec
+};
+
+int l, x;
+bool need_colon = false;
+
+assert(f);
+assert(c);
+assert(c-months_bits  0  c-months_bits = BITS_MONTHS);
+
+for (x = 0, l = -1; x  (int) ELEMENTSOF(months); x++) {
+
+if (c-months_bits  (1  x)) {
+
+if (l  0) {
+if (need_colon)
+fputc(',', f);
+else
+need_colon = true;
+
+fputs(months[x], f);
+l = x;
+}
+
+} else if (l = 0) {
+
+if (x  l + 1) {
+fputc(x  l + 2 ? '-' : ',', f);
+fputs(months[x-1], f);
+}
+
+l = -1;
+}
+}
+
+if (l = 0  x  l + 1) {
+fputc(x  l + 2 ? '-' : ',', f);
+fputs(months[x-1], f);
+}
+}
+
 static void format_chain(FILE *f, int space, const CalendarComponent *c) {
 assert(f);
 
@@ -272,6 +332,11 @@ int calendar_spec_to_string(const CalendarSpec *c, char 
**p) {
 fputc(' ', f);
 }
 
+if (c-months_bits  0  c-months_bits = BITS_MONTHS) {
+format_months(f, c);
+fputc(' ', f);
+}
+
 format_chain(f, 4, c-year);
 fputc('-', f);
 format_chain(f, 2, c-month);
@@ -391,6 +456,108 @@ static int parse_weekdays(const char **p, CalendarSpec 
*c) {
 }
 }
 
+static int parse_months(const char **p, CalendarSpec *c) {
+static const struct {
+const char *name;
+const int nr;
+} month_nr[] = {
+{ January,   0 },
+{ Jan,   0 },
+{ February,  1 },
+{ Feb,   1 },
+{ March, 2 },
+{ Mar,   2 },
+{ April, 3 },
+{ Apr,   3 },
+{ May,   4 },
+{ June,  5 },
+{ Jun,   5 },
+{ July,  6 },
+{ Jul,   6 },
+{ August,7 },
+{ Aug,   7 },
+{ September, 8 },
+{ Sep,   8 },
+{ October,   9 },
+{ Oct,   9 },
+{ November,  10 },
+{ Nov,   10 },
+{ December,  11 },
+{ Dec,   11 }
+};
+
+int l = -1;
+bool first = true;
+
+assert(p);
+assert(*p);
+assert(c);
+
+for (;;) {
+unsigned i;
+
+if (!first  **p == ' ')
+return 0;
+
+for (i = 0; i  ELEMENTSOF(month_nr); i++) {
+size_t skip;
+
+if (!startswith_no_case(*p, month_nr[i].name))
+continue;
+
+skip = strlen(month_nr[i].name);
+
+if ((*p)[skip] != '-' 
+(*p)[skip] != ',' 
+(*p)[skip] != ' ' 
+(*p)[skip] != 0)
+return -EINVAL;
+
+c-months_bits |= 1  month_nr[i].nr;
+
+

[systemd-devel] [PATCH 6/7] calendar: no backward compatibility for erroneous label

---
 src/shared/calendarspec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index fae7dfd..8e6c871 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -885,8 +885,7 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
**spec) {
 if (r  0)
 goto fail;
 
-} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)
-   || strcaseeq(p, anually) /* backwards compatibility */ ) {
+} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)) {
 r = const_chain(1, c-month);
 if (r  0)
 goto fail;
-- 
1.9.3

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

[systemd-devel] [PATCH 2/7] calendar: constant value for weekdays

---
 src/shared/calendarspec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 73f87c6..67fd76a 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -126,7 +126,7 @@ static void fix_year(CalendarComponent *c) {
 int calendar_spec_normalize(CalendarSpec *c) {
 assert(c);
 
-if (c-weekdays_bits = 0 || c-weekdays_bits = 127)
+if (c-weekdays_bits = 0 || c-weekdays_bits = BITS_WEEKDAYS)
 c-weekdays_bits = -1;
 
 fix_year(c-year);
@@ -160,7 +160,7 @@ _pure_ static bool chain_valid(CalendarComponent *c, int 
from, int to) {
 _pure_ bool calendar_spec_valid(CalendarSpec *c) {
 assert(c);
 
-if (c-weekdays_bits  127)
+if (c-weekdays_bits  BITS_WEEKDAYS)
 return false;
 
 if (!chain_valid(c-year,
@@ -202,7 +202,7 @@ static void format_weekdays(FILE *f, const CalendarSpec *c) 
{
 
 assert(f);
 assert(c);
-assert(c-weekdays_bits  0  c-weekdays_bits = 127);
+assert(c-weekdays_bits  0  c-weekdays_bits = BITS_WEEKDAYS);
 
 for (x = 0, l = -1; x  (int) ELEMENTSOF(days); x++) {
 
@@ -267,7 +267,7 @@ int calendar_spec_to_string(const CalendarSpec *c, char 
**p) {
 if (!f)
 return -ENOMEM;
 
-if (c-weekdays_bits  0  c-weekdays_bits = 127) {
+if (c-weekdays_bits  0  c-weekdays_bits = BITS_WEEKDAYS) {
 format_weekdays(f, c);
 fputc(' ', f);
 }
@@ -830,7 +830,7 @@ static bool matches_weekday(int weekdays_bits, const struct 
tm *tm) {
 struct tm t;
 int k;
 
-if (weekdays_bits  0 || weekdays_bits = 127)
+if (weekdays_bits  0 || weekdays_bits = BITS_WEEKDAYS)
 return true;
 
 t = *tm;
-- 
1.9.3

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

[systemd-devel] [PATCH] man: fix typos in description of SELinuxContextFromNet=

2014-10-27 Thread Ivan Shapovalov

---
 man/systemd.socket.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index ce04b0b..57f769f 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -678,7 +678,7 @@
 varlistentry
   
termvarnameSELinuxContextFromNet=/varname/term
  listitemparaTakes a boolean
- argument. When true systemd will attempt
+ argument. When true, systemd will attempt
  to figure out the SELinux label used
  for the instantiated service from the
  information handed by the peer over the
@@ -688,9 +688,9 @@
  the resulting SELinux context originate
  from either the target binary that is
  effectively triggered by socket unit
- are taken from the value of the
+ or from the value of the
  varnameSELinuxContext=/varname
- option.This configuration option only
+ option. This configuration option only
  affects sockets with
  varnameAccept=/varname mode set to
  literaltrue/literal. Also note that
-- 
2.1.2

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

[systemd-devel] systemctl preset for user units (and how presets are applied after factory reset)

2014-10-27 Thread Colin Guthrie

Hi,

When implementing socket activation for PulseAudio, the question came up
of how to ship the enablement when running make install.

In my first incarnation I simply shipped a
/usr/lib/systemd/user/socket.target.wants/pulseaudio.socket symlink. I
did this because I considered this a vendor choice (as opposed to an
administrator choice) and that's probably what I'd do downstream
(although I will add an additional condition in the unit so that it
doesn't run when the user has an ALSA Sound Profile (where Sound
Profiles are our downstream way of managing this choice for users), but
this is out of scope here).



However, this decision sparked some debate about whether we really
should add such a hard enablment during make install.

Perhaps the user .socket unit should just have an [Install] section and
it should be up to the packagers to call systemctl --global enable at
package install time.

This would mirror system services for the most part... with the
exception that system services should really be calling preset...


So that led me to ask myself: does systemctl preset support user units?
The man page doesn't make it clear that e.g. the --global switch applies
to preset as well as enable, but in testing it (happily) appears to
work! So I'm going to answer that question with a yes, it does work!



So, as preset works for user-units, I'm thinking that we should NOT ship
a /usr/lib/systemd/user/socket.target.wants/pulseaudio.socket symlink
and leave it to downstream packagers to call systemctl preset --global
pulseaudio.socket when the package is first installed. This will create
the /etc/systemd/user/socket.target.wants/pulseaudio.socket symlink for
us and all is well.

[As a side note, if this is the recommended approach, then we should
probably add appropriate RPM macros to macros.systemd for user unit
presets...]


There are, however, two questions still remain:

1. As we have two units, pulseaudio.socket and pulseaudio.service, and
as the desired behaviour is to enable only the socket but not the
service (i.e. by default rely on socket activation - don't waste
resources unless a client actually connects; this is a bit of an
assumption - perhaps this should be desirable?) should we:
  a) Recommend packagers only call systemctl preset --global
pulseaudio.socket
  b) Recommend packagers call systemctl preset --global
pulseaudio.socket pulseaudio.service, but remove the [Install] section
from the .service
  c) Recommend packagers call systemctl preset --global
pulseaudio.socket pulseaudio.service, but ship a preset file in
/usr/lib/systemd/user-preset/50-pulseaudio.preset that has disable
pulseaudio.service in it.

systemd.preset(5) suggests not to do c) but I think this could be an
example of an exception to that rule (to me this seems cleanest)?
Perhaps there are other socket+service pairs where this makes sense too
however, and this should be encapsulated in the preset logic more
generally? (i.e. the default logic is if a .service unit is set to be
enabled, double check to see if it has a corresponding .socket unit
which will be enabled and if so, skip enabling the .service.



2. On factory reset, I do not see any calls to systemctl preset, for
either the system or user units. Am I missing something or is this
something which should be part of the factory reset logic (i.e. a unit
with ConditionNeedsUpdate=/etc to call systemctl preset - if so, it
would presumably also need to reload systemd if any work was done for
system units, but we can assume this is safely completed before any user
instances kick in).


Thoughts welcome :)

Col


-- 

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

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

Re: [systemd-devel] [PATCH] man: fix typos in description of SELinuxContextFromNet=

2014-10-27 Thread Tom Gundersen

Pushed. Thanks!

On Mon, Oct 27, 2014 at 10:07 AM, Ivan Shapovalov intelfx...@gmail.com wrote:
 ---
  man/systemd.socket.xml | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
 index ce04b0b..57f769f 100644
 --- a/man/systemd.socket.xml
 +++ b/man/systemd.socket.xml
 @@ -678,7 +678,7 @@
  varlistentry

 termvarnameSELinuxContextFromNet=/varname/term
   listitemparaTakes a boolean
 - argument. When true systemd will attempt
 + argument. When true, systemd will attempt
   to figure out the SELinux label used
   for the instantiated service from the
   information handed by the peer over the
 @@ -688,9 +688,9 @@
   the resulting SELinux context originate
   from either the target binary that is
   effectively triggered by socket unit
 - are taken from the value of the
 + or from the value of the
   varnameSELinuxContext=/varname
 - option.This configuration option only
 + option. This configuration option only
   affects sockets with
   varnameAccept=/varname mode set to
   literaltrue/literal. Also note that
 --
 2.1.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

Re: [systemd-devel] [PATCH] util: introduce sethostname_idempotent

2014-10-27 Thread Michal Sekletar

On Tue, Oct 21, 2014 at 07:29:31PM +0200, Lennart Poettering wrote:
 On Tue, 21.10.14 18:32, Michal Sekletar (msekl...@redhat.com) wrote:
snip
 Go ahead and commit. Ideally with those two nitpicks fixed, but even
 if you don't it's OK.

sethostname_idempotent now returns 1 when hostname was changed. Also, I've
pushed follow-up fix-up for copy paste error, so we actually call sethostname()
on s not on buf which contains old hostname.

Michal

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

Re: [systemd-devel] [PATCH 3/4] shutdown: don't do final unmounting when inside the container and running without CAP_SYS_ADMIN

2014-10-27 Thread Michal Sekletar

On Wed, Oct 08, 2014 at 04:54:59PM +0200, Lennart Poettering wrote:
 On Wed, 08.10.14 16:49, Michal Sekletar (msekl...@redhat.com) wrote:
 
 Hmm, I think we should just do need_umount = !in_container, like we
 do for the other things like loopback detaching, dm detaching or
 swapoff. After all, if we run in a container we run in a mount
 namespace anyway, so unmounting things is done by the kernel
 implicitly if the namespace dies. At least in theory this means we can
 simply skip the unmounting in all containers, but I must admit that I
 am not entirely clear on this one, so this needs to be tested in the
 common container managers really, I figure...

Do you mind if I push just need_umount = !in_container then?
   
   Well, yes.
   
   I'd be thankful if you'd test this a bit first, so that this doesn't
   break anything. Testing nspawn and on bare-metal should be enough.
  
  Works just fine on F21 KVM guest and in rawhide nspawn container.
 
 THen please, go ahead, commit with a good commit msg explaining things,
 maybe even referencing this discussion.

Pushed with better explanation. Hope that commit message makes sense.

Michal

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

Re: [systemd-devel] [PATCH 1/7] calendar: add constant values

On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:

  src/shared/calendarspec.c | 22 +++---
  1 file changed, 15 insertions(+), 7 deletions(-)
 
 diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
 index 64d0dec..73f87c6 100644
 --- a/src/shared/calendarspec.c
 +++ b/src/shared/calendarspec.c
 @@ -24,6 +24,12 @@
  
  #include calendarspec.h
  
 +#define CENTURY_ONE 1900
 +#define CENTURY_TWO 2000
 +#define CENTURY_GAP 70

Hmm, Idon't think these defines above are really useful. Years are
counted up in numbers, and there's really no reason to introduce new
#defines for them. It's a ton more readable if we actually mentioned
the years the same way as they are usually referred to: by their year
name.

 +#define BITS_WEEKDAYS127

I figure this makes sense to introduce.

 +#define BITS_MONTHS  127

Hmm? There aren't only 7 months in the year, there are twelve! 

The patch doesn#t appear to make use of the latter two macros though?

Lennart

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

Re: [systemd-devel] [PATCH 2/7] calendar: constant value for weekdays

On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:

Could you merge the #define for BITS_WEEKDAYS into this patch please,
as this patch appears to be the one that starts making use of this?

 ---
  src/shared/calendarspec.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
 index 73f87c6..67fd76a 100644
 --- a/src/shared/calendarspec.c
 +++ b/src/shared/calendarspec.c
 @@ -126,7 +126,7 @@ static void fix_year(CalendarComponent *c) {
  int calendar_spec_normalize(CalendarSpec *c) {
  assert(c);
  
 -if (c-weekdays_bits = 0 || c-weekdays_bits = 127)
 +if (c-weekdays_bits = 0 || c-weekdays_bits = BITS_WEEKDAYS)
  c-weekdays_bits = -1;
  
  fix_year(c-year);
 @@ -160,7 +160,7 @@ _pure_ static bool chain_valid(CalendarComponent *c, int 
 from, int to) {
  _pure_ bool calendar_spec_valid(CalendarSpec *c) {
  assert(c);
  
 -if (c-weekdays_bits  127)
 +if (c-weekdays_bits  BITS_WEEKDAYS)
  return false;
  
  if (!chain_valid(c-year,
 @@ -202,7 +202,7 @@ static void format_weekdays(FILE *f, const CalendarSpec 
 *c) {
  
  assert(f);
  assert(c);
 -assert(c-weekdays_bits  0  c-weekdays_bits = 127);
 +assert(c-weekdays_bits  0  c-weekdays_bits = BITS_WEEKDAYS);
  
  for (x = 0, l = -1; x  (int) ELEMENTSOF(days); x++) {
  
 @@ -267,7 +267,7 @@ int calendar_spec_to_string(const CalendarSpec *c, char 
 **p) {
  if (!f)
  return -ENOMEM;
  
 -if (c-weekdays_bits  0  c-weekdays_bits = 127) {
 +if (c-weekdays_bits  0  c-weekdays_bits = BITS_WEEKDAYS) {
  format_weekdays(f, c);
  fputc(' ', f);
  }
 @@ -830,7 +830,7 @@ static bool matches_weekday(int weekdays_bits, const 
 struct tm *tm) {
  struct tm t;
  int k;
  
 -if (weekdays_bits  0 || weekdays_bits = 127)
 +if (weekdays_bits  0 || weekdays_bits = BITS_WEEKDAYS)
  return true;
  
  t = *tm;
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH 3/7] calendar: functions and callings to handle the months's labels

On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:

  typedef struct CalendarSpec {
  int weekdays_bits;
 +  int months_bits;
  

I see the usefulness of the functionality, and I am willing to take a
patch for this, but adding a new months_bits field here is not the way
to go I fear, simply because it is entirely redundant given the
month linked list we already have in place. Specifying a textual
month should simply translate into the right change to month, not
more.

Lennart

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

Re: [systemd-devel] [PATCH 4/7] calendar: new case 'minutely'

On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:

Looks good! Applied! Thanks!

 ---
  src/shared/calendarspec.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)
 
 diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
 index 196a330..6186301 100644
 --- a/src/shared/calendarspec.c
 +++ b/src/shared/calendarspec.c
 @@ -833,7 +833,12 @@ int calendar_spec_from_string(const char *p, 
 CalendarSpec **spec) {
  if (!c)
  return -ENOMEM;
  
 -if (strcaseeq(p, hourly)) {
 +if (strcaseeq(p, minutely)) {
 +r = const_chain(0, c-second);
 +if (r  0)
 +goto fail;
 +
 +} else if (strcaseeq(p, hourly)) {
  r = const_chain(0, c-minute);
  if (r  0)
  goto fail;
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH 5/7] calendar: re-ordering 'weekly'

On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:

Hmm, can you elaborate on this change and why you made it?

 ---
  src/shared/calendarspec.c | 26 +-
  1 file changed, 13 insertions(+), 13 deletions(-)
 
 diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
 index 6186301..fae7dfd 100644
 --- a/src/shared/calendarspec.c
 +++ b/src/shared/calendarspec.c
 @@ -857,10 +857,10 @@ int calendar_spec_from_string(const char *p, 
 CalendarSpec **spec) {
  if (r  0)
  goto fail;
  
 -} else if (strcaseeq(p, monthly)) {
 -r = const_chain(1, c-day);
 -if (r  0)
 -goto fail;
 +} else if (strcaseeq(p, weekly)) {
 +
 +c-weekdays_bits = 1;
 +
  r = const_chain(0, c-hour);
  if (r  0)
  goto fail;
 @@ -871,11 +871,7 @@ int calendar_spec_from_string(const char *p, 
 CalendarSpec **spec) {
  if (r  0)
  goto fail;
  
 -} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)
 -   || strcaseeq(p, anually) /* backwards compatibility */ 
 ) {
 -r = const_chain(1, c-month);
 -if (r  0)
 -goto fail;
 +} else if (strcaseeq(p, monthly)) {
  r = const_chain(1, c-day);
  if (r  0)
  goto fail;
 @@ -889,10 +885,14 @@ int calendar_spec_from_string(const char *p, 
 CalendarSpec **spec) {
  if (r  0)
  goto fail;
  
 -} else if (strcaseeq(p, weekly)) {
 -
 -c-weekdays_bits = 1;
 -
 +} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)
 +   || strcaseeq(p, anually) /* backwards compatibility */ 
 ) {
 +r = const_chain(1, c-month);
 +if (r  0)
 +goto fail;
 +r = const_chain(1, c-day);
 +if (r  0)
 +goto fail;
  r = const_chain(0, c-hour);
  if (r  0)
  goto fail;
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH 6/7] calendar: no backward compatibility for erroneous label

On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:

Hmm? Why would we want to drop the backwards compatibility here? We
juste added it a few days ago!

 ---
  src/shared/calendarspec.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
 index fae7dfd..8e6c871 100644
 --- a/src/shared/calendarspec.c
 +++ b/src/shared/calendarspec.c
 @@ -885,8 +885,7 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
 **spec) {
  if (r  0)
  goto fail;
  
 -} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)
 -   || strcaseeq(p, anually) /* backwards compatibility */ 
 ) {
 +} else if (strcaseeq(p, annually) || strcaseeq(p, yearly)) {
  r = const_chain(1, c-month);
  if (r  0)
  goto fail;
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH 7/7] calendar: parse months

On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:

This should be in the same patch that introduces parse_months()!

 ---
  src/shared/calendarspec.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
 index 8e6c871..ec84d65 100644
 --- a/src/shared/calendarspec.c
 +++ b/src/shared/calendarspec.c
 @@ -907,6 +907,10 @@ int calendar_spec_from_string(const char *p, 
 CalendarSpec **spec) {
  if (r  0)
  goto fail;
  
 +r = parse_months(p, c);
 +if (r  0)
 +goto fail;
 +
  r = parse_date(p, c);
  if (r  0)
  goto fail;
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH 4/7] calendar: new case 'minutely'

On Mon, 27.10.14 13:42, Lennart Poettering (lenn...@poettering.net) wrote:

 On Mon, 27.10.14 08:42, Daniele Medri (dme...@gmail.com) wrote:
 
 Looks good! Applied! Thanks!

Also made man page changes for this now.

Please, when posting a patch like this always include the man page
changes documenting it, too!

Thanks!

Lennart

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

Re: [systemd-devel] [PATCH] login: remove multi-seat-x

On Sun, 26.10.14 00:30, Timofey Titovets (nefelim...@gmail.com) wrote:

 Completed TODO: remove multi-seat-x

Hmm, I don't remember the details of this, did X release a new version
which makes this tool unnecessary? I think they commited code that
made it unnecessary, but did they actually release it?

 
 From 57b2655d2041d2bb2e9b25bef577ead9b27ce6ee Mon Sep 17 00:00:00 2001
 From: Timofey Titovets nefelim...@gmail.com
 Date: Sun, 26 Oct 2014 00:17:24 +0300
 Subject: [PATCH] login: remove multi-seat-x
 
 ---
  Makefile.am  |  14 --
  TODO |   2 -
  configure.ac |   8 
  src/login/multi-seat-x.c | 108
 ---
  4 files changed, 132 deletions(-)
  delete mode 100644 src/login/multi-seat-x.c
 
 diff --git a/Makefile.am b/Makefile.am
 index fae946a..fc86b45 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -5400,20 +5400,6 @@ SYSTEM_UNIT_ALIASES += \
  BUSNAMES_TARGET_WANTS += \
   org.freedesktop.login1.busname
 
 -if ENABLE_MULTI_SEAT_X
 -
 -systemd_multi_seat_x_SOURCES = \
 - src/login/multi-seat-x.c
 -
 -systemd_multi_seat_x_LDADD = \
 - libsystemd-label.la \
 - libsystemd-shared.la
 -
 -rootlibexec_PROGRAMS += \
 - systemd-multi-seat-x
 -
 -endif
 -
  dist_udevrules_DATA += \
   src/login/70-uaccess.rules \
   src/login/70-power-switch.rules
 diff --git a/TODO b/TODO
 index ed00661..195ca55 100644
 --- a/TODO
 +++ b/TODO
 @@ -102,8 +102,6 @@ Features:
 
  * maybe introduce AssertXYZ= similar to ConditionXYZ= that causes a unit to
 fail (instead of skipping it) if some condition is not true...
 
 -* remove multi-seat-x now
 -
  * refcounting in sd-resolve is borked
 
  * exponential backoff in timesyncd and resolved when we cannot reach a
 server
 diff --git a/configure.ac b/configure.ac
 index c3b4ea3..f69eb82 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1063,14 +1063,6 @@ fi
  AM_CONDITIONAL(ENABLE_EFI, [test x$have_efi = xyes])
 
  # 
 --
 -have_multi_seat_x=no
 -AC_ARG_ENABLE(multi_seat_x, AS_HELP_STRING([--disable-multi-seat-x], [do
 not build multi-seat-x]))
 -if test x$enable_multi_seat_x != xno; then
 -have_multi_seat_x=yes
 -fi
 -AM_CONDITIONAL(ENABLE_MULTI_SEAT_X, [test $have_multi_seat_x = yes])
 -
 -# 
 --
  have_terminal=no
  AC_ARG_ENABLE(terminal, AS_HELP_STRING([--enable-terminal], [enable
 terminal support]))
  if test x$enable_terminal = xyes; then
 diff --git a/src/login/multi-seat-x.c b/src/login/multi-seat-x.c
 deleted file mode 100644
 index 83760d4..000
 --- a/src/login/multi-seat-x.c
 +++ /dev/null
 @@ -1,108 +0,0 @@
 -/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
 -
 -/***
 -  This file is part of systemd.
 -
 -  Copyright 2011 Lennart Poettering
 -
 -  systemd is free software; you can redistribute it and/or modify it
 -  under the terms of the GNU Lesser General Public License as published by
 -  the Free Software Foundation; either version 2.1 of the License, or
 -  (at your option) any later version.
 -
 -  systemd is distributed in the hope that it will be useful, but
 -  WITHOUT ANY WARRANTY; without even the implied warranty of
 -  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 -  Lesser General Public License for more details.
 -
 -  You should have received a copy of the GNU Lesser General Public License
 -  along with systemd; If not, see http://www.gnu.org/licenses/.
 -***/
 -
 -#include string.h
 -#include unistd.h
 -
 -#include util.h
 -#include mkdir.h
 -
 -int main(int argc, char *argv[]) {
 -
 -int i;
 -const char *seat = NULL;
 -char **new_argv;
 -_cleanup_free_ char *path = NULL;
 -int r;
 -_cleanup_fclose_ FILE *f = NULL;
 -
 -/* This binary will go away as soon as X natively takes the
 - * arguments in question as command line parameters, instead
 - * of requiring them in the configuration file. */
 -
 -/* If this file is removed, don't forget to remove the code
 - * that invokes this in gdm and other display managers. */
 -
 -for (i = 1; i  argc; i++)
 -if (streq(argv[i], -seat))
 -seat = argv[i+1];
 -
 -if (isempty(seat) || streq(seat, seat0)) {
 -argv[0] = (char*) X_SERVER;
 -execv(X_SERVER, argv);
 -log_error(Failed to execute real X server: %m);
 -goto fail;
 -}
 -
 -r = mkdir_safe_label(/run/systemd/multi-session-x, 0755, 0, 0);
 -if (r  0) {
 -log_error(Failed to create directory: %s, strerror(-r));
 -goto fail;
 -}
 -
 -path = strappend(/run/systemd/multi-session-x/, seat);
 -if (!path) {
 -log_oom();
 -goto fail;
 -

Re: [systemd-devel] udev database backwards compatibility guarantees

2014-10-27 Thread Alexander Larsson

On lör, 2014-10-25 at 13:45 +0200, Kay Sievers wrote:
  Kay, any ideas on the udev database stability?
 
 No stability. And so far no guarantees that things will not change.
 
 The versions of the udev daemon, libudev and the runtime data must
 match. Any expectations about version mix and match would require a
 promise we do not give at this moment.
 
 It might change with an imaginary sd-device library, but it is very
 unlikely to happen with the current udev.

So, libudev will not be supportable as bundled in a sandboxed app then?



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

Re: [systemd-devel] udev database backwards compatibility guarantees

2014-10-27 Thread Kay Sievers

On Mon, Oct 27, 2014 at 2:22 PM, Alexander Larsson al...@redhat.com wrote:
 On lör, 2014-10-25 at 13:45 +0200, Kay Sievers wrote:
  Kay, any ideas on the udev database stability?

 No stability. And so far no guarantees that things will not change.

 The versions of the udev daemon, libudev and the runtime data must
 match. Any expectations about version mix and match would require a
 promise we do not give at this moment.

 It might change with an imaginary sd-device library, but it is very
 unlikely to happen with the current udev.

 So, libudev will not be supportable as bundled in a sandboxed app then?

Right. I don't think we can make any such promises with the current code base.

The event monitor depends on a the same version of the running daemon,
or the properties which depend on the data in /run. Only the part that
finds devices, reads properties and enumerates /sys should be fine.

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

Re: [systemd-devel] systemctl preset for user units (and how presets are applied after factory reset)

On Mon, Oct 27, 2014 at 10:42:56AM +, Colin Guthrie wrote:
 So that led me to ask myself: does systemctl preset support user units?
 The man page doesn't make it clear that e.g. the --global switch applies
 to preset as well as enable, but in testing it (happily) appears to
 work! So I'm going to answer that question with a yes, it does work!
SYNOPSIS lists a few .../user-preset/... paths, which indicates that
it does.

 So, as preset works for user-units, I'm thinking that we should NOT ship
 a /usr/lib/systemd/user/socket.target.wants/pulseaudio.socket symlink
 and leave it to downstream packagers to call systemctl preset --global
 pulseaudio.socket when the package is first installed. This will create
 the /etc/systemd/user/socket.target.wants/pulseaudio.socket symlink for
 us and all is well.
 
 [As a side note, if this is the recommended approach, then we should
 probably add appropriate RPM macros to macros.systemd for user unit
 presets...]
Good point.

 There are, however, two questions still remain:
 
 1. As we have two units, pulseaudio.socket and pulseaudio.service, and
 as the desired behaviour is to enable only the socket but not the
 service (i.e. by default rely on socket activation - don't waste
 resources unless a client actually connects; this is a bit of an
 assumption - perhaps this should be desirable?) should we:
   a) Recommend packagers only call systemctl preset --global
 pulseaudio.socket
   b) Recommend packagers call systemctl preset --global
 pulseaudio.socket pulseaudio.service, but remove the [Install] section
 from the .service
   c) Recommend packagers call systemctl preset --global
 pulseaudio.socket pulseaudio.service, but ship a preset file in
 /usr/lib/systemd/user-preset/50-pulseaudio.preset that has disable
 pulseaudio.service in it.

Neither of those. Distribution packaging should set the default
policy, which in case of Fedora would be 'disable *', and
the package specific policy, containing just 'enable pulseaudio.socket'
assuming that only socket activiation is desired.

This way, full flexibility is retained, and distributions like
Fedora that don't activate by default on package installation, and
the ones like Debian that sometimes do, attain desired behaviour
by simply chaning one or two lines in the presets files.

 systemd.preset(5) suggests not to do c) but I think this could be an
 example of an exception to that rule (to me this seems cleanest)?
 Perhaps there are other socket+service pairs where this makes sense too
 however, and this should be encapsulated in the preset logic more
 generally? (i.e. the default logic is if a .service unit is set to be
 enabled, double check to see if it has a corresponding .socket unit
 which will be enabled and if so, skip enabling the .service.
 
 2. On factory reset, I do not see any calls to systemctl preset, for
 either the system or user units. Am I missing something or is this
 something which should be part of the factory reset logic (i.e. a unit
 with ConditionNeedsUpdate=/etc to call systemctl preset - if so, it
 would presumably also need to reload systemd if any work was done for
 system units, but we can assume this is safely completed before any user
 instances kick in).
I seems this should be done. I thought that factory-reset already does
that...

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

Re: [systemd-devel] [PATCH] login: remove multi-seat-x

On Mon, 27.10.14 16:23, Timofey Titovets (nefelim...@gmail.com) wrote:

 2014-10-27 16:00 GMT+03:00 Lennart Poettering lenn...@poettering.net:
  On Sun, 26.10.14 00:30, Timofey Titovets (nefelim...@gmail.com) wrote:
 
  Completed TODO: remove multi-seat-x
 
  Hmm, I don't remember the details of this, did X release a new version
  which makes this tool unnecessary? I think they commited code that
  made it unnecessary, but did they actually release it?
 
 As i find: gdm uses it.

Well, the original patch for gdm I did first tried multi-user-x if it
was around, and then fell back to X itself. Thus, we can safely get
rid of multi-user-x without breaking gdm. However, we should do so
only after verifying that the per-seat magic that multi-user-x did is
now correctly and fully done by X itself.

Lennart

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

Re: [systemd-devel] [PATCH] Add timesync-wait tool

On Fri, 24.10.14 23:13, Lukasz Stelmach (stl...@poczta.fm) wrote:

 On 24.10.2014 00:28, Lennart Poettering wrote:
  On Thu, 23.10.14 21:24, Łukasz Stelmach (stl...@poczta.fm) wrote:
  
  +int main(int argc, char *argv[]) {
  +struct timex tbuf;
  +int r;
  +
  +memset(tbuf, 0, sizeof(tbuf));
  
  Please initialize this with = {} while declaring, instead of using
  memset() here.
  
  +r = adjtimex(tbuf);
  +
  +while (r != TIME_OK) {
  
  This check looks wrong. Should check for tbuf.status  STA_UNSYNC, no? 
  
  Also, we already have the ntp_synced() call for doing this. 
 
 Indeed. I can replace most of the code here with ntp_synced() leaving an
 if with a break and the sleep();
 
  +sleep(1);
  +/* Unfortunately there seem to be no other way than
  +polling to get this information. */
  +memset(tbuf, 0, sizeof(tbuf));
  
  In this case, use zero(), it's nicer, simpler and less error prone.
  
  +r = adjtimex(tbuf);
  +}
  
  Implementing this with a sleep loop is really ugly. Can't we at least
  calculate the expected sync time from the data returned by adjtimex()?
 
 I don't know how to do it exactly (yet). But my guess is that when the
 system starts the information you refer are not good enough to predict
 anything?

Hmm, thinking about this some more: is STA_UNSYNC actually really what
we should be looking for? I mean, what is the tool supposed to be
waiting on: that the time is set as accurately as possible (in that
case watching STA_UNSYNC sounds good, plus waiting for
TFD_CANCEL_ON_SET for big jumps and guessing sleep times from
adjtimex()'s return values for smaller jumps)? Or that the time is set
accurately enough for adjtimex() to be used for the remaining accuracy
(In that case, we'd actually have to make timesyncd report this
information to us, maybe using a flag file to watch via inotify)? Or
that the time set accurately enough to be monotonic, but not more (in
that case just ordering after systemd-timesyncd.service should be
enough, no need for any other tool)?

Of these three options, I think the first one is not necessarily a
good idea, since adjtimex() is really about making time corrections
smooth and hence slow. Making this slow, and trying to wait for it is
kinda contradictory, no?

The third one is not a good idea either, since we already have
functionality covering that.

But if the second option is the relevant one, then I figure neither
adjtimex() nor TFP_CANCEL_ON_SET will be useful to us, and instead we
need to teach systemd-timesyncd some flag file stuff.

  The same way as network-wait-online has a timeout this tool should
  probably have one too.
 
 If the timeout is reached the tool exits with a non-zero code. Right?
 That makes sense. Is three minutes OK?

I'd use the same default timeout as for systemd-network-wait-online,
for whatever that is.

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] Problem with modprobe in lm_sensors.service

On Mon, 06.10.14 14:41, Dale R. Worley (wor...@alum.mit.edu) wrote:

 I am running Fedora 16 with kernel 3.14.19-100.fc19.x86_64 and
 systemd-204-21.fc19.x86_64.
 
 On startup (and sometimes shutdown), I see a message like this in
 /var/log/messages:
 
 Oct  6 13:53:37 hobgoblin modprobe[623]: modprobe: ERROR: missing 
 parameters. See -h.
 
 This message appears to be due to invocations of modprobe with these
 arguments:
 
 /sbin/modprobe -qab
 /sbin/modprobe -qabr
 
 Grepping all the system files (and looking in the journal), it seems
 likely that these invocations are made by systemd, under control of
 /usr/lib/systemd/system/lm_sensors.service:
 
 [Unit]
 Description=Initialize hardware monitoring sensors
 After=syslog.target
 
 [Service]
 EnvironmentFile=/etc/sysconfig/lm_sensors
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=-/sbin/modprobe -qab $BUS_MODULES $HWMON_MODULES
 ExecStart=/usr/bin/sensors -s
 ExecStop=-/sbin/modprobe -qabr $BUS_MODULES $HWMON_MODULES
 
 [Install]
 WantedBy=multi-user.target
 
 Which suggests that $BUS_MODULES and $HWMON_MODULES are empty in this
 context.
 
 Is it normal for these variables to be empty (in which case, the
 lm_sensors people need to fix their .service file) or is systemd
 supposed to be providing values here (in wich case, this is a systemd
 problem)?
 
 (And if it's a problem with the .service file, is there a standard
 way to avoid this problem that I can suggest to the lm_sensors
 people?)

I'd recommend for the lm_sensors package to migrate the modules list
into normal /etc/modules-load.d/ files and then remove the relevant
bits from /etc/sysconfig, all from a %post script. Loading kernel
modules manually in individual packages is really confusing for the
admin, and not recommended.

The way modprobe works and this unit tries to make use of are
incompatible if no modules are configured in lm-sensor's sysconfig
file. THis can be fied by changing modprobe to accept empty arguments
list, or by not using it this way (and adding a wrapper scripts)

Also not that unloading kernel modules is merely a
debugging/testing/developer tool. It's nothing that should ever happen
during normal operation, as there are a few races left. The ExecStop=
line is hence really really wrong. Kernel modules should *not* be
unloaded during shutdown.

Lennart

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

Re: [systemd-devel] [PATCH] Move apparmor code before the namespace setup

On Sat, 11.10.14 21:57, m...@zarb.org (m...@zarb.org) wrote:

 From: Michael Scherer m...@zarb.org
 
 Since apparmor need to access /proc to communicate with the kernel,
 any unit setting / as readonly will be unable to also use the
 AppArmorProfile setting, as found on debian bug 760526.

A unit that sets /proc to read-only is broken anyway, I don't think we
should work around that. or am I missing something here?

If you apply the apparmor profile before setting up the namespace
stuff you need to whitelist all the namespace operations in the
apparmor profile. That might be quite a lot, hence: is this really
desirable?

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 in initramfs: /etc/passwd, /etc/group, emergency.service and sulogin

On Sat, 25.10.14 00:52, Ivan Shapovalov (intelfx...@gmail.com) wrote:

 Hi,
 
 A few questions regarding usage of systemd+udev in initramfs. Before all,
 this is what I want to achieve (to prevent XY-problems): working
 emergency.service in initramfs.
 
 The questions are a bit Arch-specific and possibly lame, but well...
 
 - is /etc/passwd still[1] needed in initramfs due to libdbus1?

Hmm, good question. 

I think for the simpler cases /etc/passwd could be empty now. However,
as soon as networkd is thrown into the mix we really want the
systemd-network user around, so that networkd can drop privs, which
it really should do a network-facing daemon that it is.

 - how to pass '--resolve-names=never' to udevd in initramfs, will it work this
   way and will it allow to exclude /etc/group[2] from initramfs?

You should be able to pass it in the systemd-udevd.service unit file
you ship in the unit file. I think doing this should be OK, but I
figure you have to try. That all said, due to the systemd-network
user I am not convinced that a /etc/passwd-less initrd is really
useful for more than the simplest cases.

 - is it possible to use 'sulogin -e' instead of 'sulogin'[3]
   security-wise?

Sure, just override the upstream unit files in question. That said, I
am a bit afraid of making this change upstream...

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] Waiting for nspawn services

On Sat, 25.10.14 05:39, Rich Freeman (r-syst...@thefreemanclan.net) wrote:

 One of the useful options in nspawn is the ability to boot the init
 within the container using -b, especially if that init happens to be
 systemd.
 
 However, I could not find any easy way to set a dependency on a
 service within a container.
 
 Example use case:
 Unit 1 boots an nspawn container that runs mysql
 Unit 2 launches a service that depends on mysql, or it might even be
 another container that depends on mysql.
 
 I could put together a script that pings mysql until it is up, but the
 original mysql unit already has to make the determination as to
 whether the service is ready, so this is redundant.  Also, that is a
 solution specific to a single daemon, while the problem is generic.
 
 I could think of a few possible ways to solve this.
 
 1.  Have a way to actually specify a dependency on a unit within a
 container.

As I see it containers are really about separation of things, and
integrating multiple systemd nodes into a single dependency tree
appears a slippery slope to me here...

 2.  Have a generic wait program that can wait for any unit to start
 within a container, or perhaps even on a remote host.

Note that a tool like this would have to do the
try-wait-try-again-repeat dance as well, as init systems are not
immediately connectable when a container is booted, during their early
boot phase. 

 3.  Have a way for nspawn to delay becoming online until all services
 inside have become online.
 
 Actually, being able to express unit dependencies across machines
 might be useful on many levels, but I'll be happy enough just to be
 able to handle containers on a single host for now.

I am not opposed to adding a scheme that makes this possible, but I am
not sure how we could do this in a nice way. Requirements I see are:
that it fails gracefully on non-systemd guests, is race-free, doesn't
involve retry loops.

In general I think making use of socket notification here would be the
much better option, as it removes the entire need for ordering things
here. nspawn already support socket activation just fine. If your
mysql container would use this, then you could start the entire mysql
container at the same time as the mysql client without any further
complexity or synchronization, and it would just work.

socket activation in mysql would be pretty useful anyway, so maybe
that's the more preferable option anyway?

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] systemctl preset for user units (and how presets are applied after factory reset)

On Mon, Oct 27, 2014 at 02:16:38PM +, Colin Guthrie wrote:
 
 Zbigniew Jędrzejewski-Szmek wrote on 27/10/14 13:52:
  [As a side note, if this is the recommended approach, then we should
  probably add appropriate RPM macros to macros.systemd for user unit
  presets...]
  Good point.
 
 I usually get one or two a year ;)
 
  There are, however, two questions still remain:
 
  1. As we have two units, pulseaudio.socket and pulseaudio.service, and
  as the desired behaviour is to enable only the socket but not the
  service (i.e. by default rely on socket activation - don't waste
  resources unless a client actually connects; this is a bit of an
  assumption - perhaps this should be desirable?) should we:
a) Recommend packagers only call systemctl preset --global
  pulseaudio.socket
b) Recommend packagers call systemctl preset --global
  pulseaudio.socket pulseaudio.service, but remove the [Install] section
  from the .service
c) Recommend packagers call systemctl preset --global
  pulseaudio.socket pulseaudio.service, but ship a preset file in
  /usr/lib/systemd/user-preset/50-pulseaudio.preset that has disable
  pulseaudio.service in it.
  
  Neither of those. Distribution packaging should set the default
  policy, which in case of Fedora would be 'disable *', and
  the package specific policy, containing just 'enable pulseaudio.socket'
  assuming that only socket activiation is desired.
 
 So: d) Recommend packagers call systemctl preset --global
 pulseaudio.socket pulseaudio.service and ship separately the global
 distro-wide preferences in another package?
Yes.

  This way, full flexibility is retained, and distributions like
  Fedora that don't activate by default on package installation, and
  the ones like Debian that sometimes do, attain desired behaviour
  by simply chaning one or two lines in the presets files.
 
 My main point was not really about the enable by default or not type
 policy of presets, but rather what happens when you have socket+service
 combos.
 
 If your distro policy is to enable by default, then is there a better
 way to handle the case where you only want to enable sockets for the
 services, but not the services themselves.
I don't think that there is a sensible policy encompassing all
socket+service combos. I expect each case to be handled on its own merits.
This means that having explicit lists of
enable service a.socket
enable service b.socket b.service
...
is unavoidable.
 
  Perhaps there are other socket+service pairs where this makes sense too
  however, and this should be encapsulated in the preset logic more
  generally? (i.e. the default logic is if a .service unit is set to be
  enabled, double check to see if it has a corresponding .socket unit
  which will be enabled and if so, skip enabling the .service.
 
 Basically, is the above something to cater for at a higher level in the
 distro policy or not?
No, imho.

  2. On factory reset, I do not see any calls to systemctl preset, for
  either the system or user units. Am I missing something or is this
  something which should be part of the factory reset logic (i.e. a unit
  with ConditionNeedsUpdate=/etc to call systemctl preset - if so, it
  would presumably also need to reload systemd if any work was done for
  system units, but we can assume this is safely completed before any user
  instances kick in).
  I seems this should be done. I thought that factory-reset already does
  that...
 
 Perhaps it does. I didn't see any obvious units when searching for
 ConditionNeedsUpdate in the systemd git tree, but perhaps this is
 achieved in a different way? I didn't search too much more than that so
 could easily have missed it.

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

Re: [systemd-devel] [PATCH v4] udev hwdb: Support shipping pre-compiled database in system images

On Fri, 24.10.14 16:24, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hey Zbyszek,
 
 Zbigniew Jędrzejewski-Szmek [2014-10-24 19:45 +0200]:
  This enumeration is also used below... The definition should be shared.
  You might want to also consider using NULSTR_FOREACH for iteration.
 
 Ah, thanks for pointing that out.
 
  This function should have the prototype of 'int open_hwdb_bin(const char 
  **path, FILE *file)'
  and return a proper value on error. Right now the return value is passed
  through errno, which works but is inelegant.
 
 OK. Personally I prefer ret  0 and errno as that's the standard
 POSIX way and also allows using %m etc., but if strerror(-retval) is
 the systemd style, fair enough.

Yes, systemd style is the same as kernel style here: we return
negative-errno error codes, and thus strerror(-r) is the usual idiom
to get a human-readable string. Also see the CODING_STYLE text in the
repo for details on this.

  
 +static const char hwdb_bin_paths[] =
 +/etc/udev/hwdb.bin\0
 +UDEVLIBEXECDIR /hwdb.bin\0;
 +
 +
 +static int open_hwdb_bin(const char **path, FILE** f) {
 +const char* p;
 +
 +NULSTR_FOREACH(p, hwdb_bin_paths) {
 +*path = p;

Please do not write functions that clobber passed-in arguments on
failure. Please store any result in a temporary variable first, and
clobber the passed-in variables only on success.

 +*f = fopen(p, re);

same here.

I updated CODING_STYLE to clarify this, too.

 -if (stat(/etc/udev/hwdb.bin, st)  0)
 +
 +/* if hwdb.bin doesn't exist anywhere, we need to update */
 +NULSTR_FOREACH(p, hwdb_bin_paths) {
 +if (stat(p, st) = 0) {
 +found = true;
 +break;
 +}
 +}
 +if (!found)
  return true;

I'd prefer if you could use access(..., F_OK) here, for checking for
file existance, as stat() does substantially more than just checking
existance.

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] string constants vs. #defines [was: Re: [PATCH v4] udev hwdb: Support shipping pre-compiled database in system images]

On Sun, 26.10.14 07:51, Martin Pitt (martin.p...@ubuntu.com) wrote:

   +static const char hwdb_bin_paths[] =
   +/etc/udev/hwdb.bin\0
   +UDEVLIBEXECDIR /hwdb.bin\0;
  Actually we don't need to define a variable for this, a #define would be 
  enough.
 
 Are #defines actually preferred in systemd's code style/conventions?
 Personally I prefer proper constants, as they are more type safe and
 less magic, and presumably string constants will end up in the same
 place in the ELF anyway? Using #defines potentially duplicates the
 strings too, although I suspect gcc to be clever enough to
 de-duplicate identical string constants in the source. Is there any
 downside to using static constants?

Well, there's quite a difference between string macros and string
constants. In C string macros are usually preferable, since they allow
compilers to arrange things pretty freely, as they do not imply
the actual allocation of a variable in the ELF result for this.

Moreover, string macros have the benefit that you can use them to put
together strings at build time, the way you do it above even. 

Currently, in systemd we try to be conservative:

a) Paths that are not really configurable aren't really made
   configurable, and hence are hardcoded as literal strings (such as
   the /etc/udev above...) Given that systemd is pretty much at the
   core of the OS very little of systemd is relocatable, which in turn
   means that most of its own paths are actually not configurable. In
   fact we should probably refuse building if people try to build
   systemd with prefix=/waldo...

b) For configurable and non-obvious strings we use string macros

b) Complex strings, for example NULSTR-style things, that feel more
   like an array than a real string are placed in string constants.

That alls said, the lines are blurry and we don't follow these rules
strictly so far...

Hope that makes sense?

Lennart

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

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

On Sat, 25.10.14 23:18, Kay Sievers (k...@vrfy.org) wrote:

 On Mon, Oct 20, 2014 at 6:35 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Fri, 17.10.14 15:10, Martin Pitt (martin.p...@ubuntu.com) wrote:
 
  Looks generally OK (as discussed in Düsseldorf). I'll leave this for
  Kay to merge though, as udev is more his thing. Kay!
 
 Sounds all fine, I would prefer though to use --usr-only or
 --system-only, something a little bit more descriptive than just
 --vendor though. The hwdb data is full ov vendor strings and it
 sounds too confusing to me.

I'd prefer --usr then for this. It's short, and descriptive. The
-only suffix probably creates more confusion than clears things up,
hence I'd avoid 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] Waiting for nspawn services

2014-10-27 Thread Rich Freeman

On Mon, Oct 27, 2014 at 10:49 AM, Lennart Poettering
lenn...@poettering.net wrote:
 In general I think making use of socket notification here would be the
 much better option, as it removes the entire need for ordering things
 here. nspawn already support socket activation just fine. If your
 mysql container would use this, then you could start the entire mysql
 container at the same time as the mysql client without any further
 complexity or synchronization, and it would just work.


Is socket activation supported for nspawn containers that use network
namespaces?  Incoming connections would not be pointed at the host IP,
but at the container's IP, which the host wouldn't otherwise be
listening on since the interface for it does not yet exist.

Or do I need to move everything to different port numbers and use the host IP?

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

Re: [systemd-devel] udev database backwards compatibility guarantees

On Mon, 27.10.14 14:43, Kay Sievers (k...@vrfy.org) wrote:

 On Mon, Oct 27, 2014 at 2:22 PM, Alexander Larsson al...@redhat.com wrote:
  On lör, 2014-10-25 at 13:45 +0200, Kay Sievers wrote:
   Kay, any ideas on the udev database stability?
 
  No stability. And so far no guarantees that things will not change.
 
  The versions of the udev daemon, libudev and the runtime data must
  match. Any expectations about version mix and match would require a
  promise we do not give at this moment.
 
  It might change with an imaginary sd-device library, but it is very
  unlikely to happen with the current udev.
 
  So, libudev will not be supportable as bundled in a sandboxed app then?
 
 Right. I don't think we can make any such promises with the current code base.
 
 The event monitor depends on a the same version of the running daemon,
 or the properties which depend on the data in /run. Only the part that
 finds devices, reads properties and enumerates /sys should be fine.

Maybe the right approach is to move things over to kdbus, and then
make sandboxed apps use the kdbus interface, and hide the other stuff
away or so...

Lennart

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

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

2014-10-27 Thread Michael Biebl

2014-10-27 16:21 GMT+01:00 Lennart Poettering lenn...@poettering.net:
 Sounds all fine, I would prefer though to use --usr-only or
 --system-only, something a little bit more descriptive than just
 --vendor though. The hwdb data is full ov vendor strings and it
 sounds too confusing to me.

 I'd prefer --usr then for this. It's short, and descriptive. The
 -only suffix probably creates more confusion than clears things up,
 hence I'd avoid that.

Keep in mind, that with split-usr, the hwdb files are in /lib/udev/hwdb

So --usr would be confusing/misleading.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Waiting for nspawn services

On Mon, 27.10.14 11:24, Rich Freeman (r-syst...@thefreemanclan.net) wrote:

 On Mon, Oct 27, 2014 at 10:49 AM, Lennart Poettering
 lenn...@poettering.net wrote:
  In general I think making use of socket notification here would be the
  much better option, as it removes the entire need for ordering things
  here. nspawn already support socket activation just fine. If your
  mysql container would use this, then you could start the entire mysql
  container at the same time as the mysql client without any further
  complexity or synchronization, and it would just work.
 
 Is socket activation supported for nspawn containers that use network
 namespaces? 

Yes. The socket passed in doesn't have to be from the same namespace
as the container runs in. It's kinda cool, as this allows locking down
containers pretty strictly, but still granting them access on some
very specific listening socket.

(Note though that ymmv on this, because depending on the software you
use it might want to reverse-dns lookup incomoing connections, and
that would fail if the container doesn't have network access to do
DNS... That said, if mysql would do reverse-dns of all incoming
connections it would be really stupid...)

 Incoming connections would not be pointed at the host IP,
 but at the container's IP, which the host wouldn't otherwise be
 listening on since the interface for it does not yet exist.
 
 Or do I need to move everything to different port numbers and use the host IP?

Network namespaces are relevant for the process that originally binds
the sockets. In the case of socket-activated containers that would be
the host. If you then pass the fds into the containers and those are
locked into their own namespaces, then any sockets they create and
bind would be from their own namepsace, but the one they got passed in
would still be from the original host namespace. If they then accept a
connection on that passed-in socket that connection socket would also
be part of the same host namespace -- not of the containers.

Hence, two rules:

a) if you have a socket, then all sockets you derive from it via
   accept() stay part of the same namespace as that original socket.

b) any new sockets you generate via socket() are part of whatever
   network namespace your process is currently in.

Hope that makes sense?

Lennart

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

Re: [systemd-devel] Waiting for nspawn services

2014-10-27 Thread Reindl Harald



Am 27.10.2014 um 16:32 schrieb Lennart Poettering:

(Note though that ymmv on this, because depending on the software you
use it might want to reverse-dns lookup incomoing connections, and
that would fail if the container doesn't have network access to do
DNS... That said, if mysql would do reverse-dns of all incoming
connections it would be really stupid...)


it does because you can set permissions on hostnames
but you can add skip-name-resolve in my.cnf



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

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

On Mon, 27.10.14 16:31, Michael Biebl (mbi...@gmail.com) wrote:

 2014-10-27 16:21 GMT+01:00 Lennart Poettering lenn...@poettering.net:
  Sounds all fine, I would prefer though to use --usr-only or
  --system-only, something a little bit more descriptive than just
  --vendor though. The hwdb data is full ov vendor strings and it
  sounds too confusing to me.
 
  I'd prefer --usr then for this. It's short, and descriptive. The
  -only suffix probably creates more confusion than clears things up,
  hence I'd avoid that.
 
 Keep in mind, that with split-usr, the hwdb files are in /lib/udev/hwdb
 
 So --usr would be confusing/misleading.

Well, I think that's OK really. We want to stay compatible with
split-usr distros, but that kind of setup is really not at the focus
of what we design for.

I still think this should be named --usr. After all, moving those
files away from /etc doesn't really make sense on split-/usr systems
anyway, as it wouldn't help monopolizing vendor data in /usr
really... Or at least I think the --usr stuff is really about
monopolizing vendor data in /usr, and if you have a split-/usr system
then that goal is moot anyway...

Lennart

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

Re: [systemd-devel] [PATCH 5/7] calendar: re-ordering 'weekly'

 Hmm, can you elaborate on this change and why you made it?

Readability, cases sorted by time (daily  weekly  monthly).

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

Re: [systemd-devel] [PATCH 5/7] calendar: re-ordering 'weekly'

On Mon, 27.10.14 16:40, Daniele Medri (dme...@gmail.com) wrote:

  Hmm, can you elaborate on this change and why you made it?
 
 Readability, cases sorted by time (daily  weekly  monthly).

Well, I think I disagree. We mostly have ordered these if() blocks by
the order of appearance in the normalized string form (or, actually,
the reverse of it), which I think makes some sense.

ANyway, this is close to bakeshedding...

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] udev database backwards compatibility guarantees

2014-10-27 Thread Kay Sievers

On Mon, Oct 27, 2014 at 4:25 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 27.10.14 14:43, Kay Sievers (k...@vrfy.org) wrote:

 On Mon, Oct 27, 2014 at 2:22 PM, Alexander Larsson al...@redhat.com wrote:
  On lör, 2014-10-25 at 13:45 +0200, Kay Sievers wrote:
   Kay, any ideas on the udev database stability?
 
  No stability. And so far no guarantees that things will not change.
 
  The versions of the udev daemon, libudev and the runtime data must
  match. Any expectations about version mix and match would require a
  promise we do not give at this moment.
 
  It might change with an imaginary sd-device library, but it is very
  unlikely to happen with the current udev.
 
  So, libudev will not be supportable as bundled in a sandboxed app then?

 Right. I don't think we can make any such promises with the current code 
 base.

 The event monitor depends on a the same version of the running daemon,
 or the properties which depend on the data in /run. Only the part that
 finds devices, reads properties and enumerates /sys should be fine.

 Maybe the right approach is to move things over to kdbus, and then
 make sandboxed apps use the kdbus interface, and hide the other stuff
 away or so...

Yeah, that sounds like the way to go. We should be very careful with
exposing the so-far-private /run state to the sandboxed apps if we
want to make promises about backwards compat. I don't think that will
work out in the longer run.

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

Re: [systemd-devel] [PATCH] tmpfiles: only change device permissions if mknod succeeded

On Sat, 25.10.14 01:36, Tom Gundersen (t...@jklm.no) wrote:

 On Mon, Oct 20, 2014 at 9:32 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 14.10.14 16:19, Jan Synacek (jsyna...@redhat.com) wrote:
 
  https://bugzilla.redhat.com/show_bug.cgi?id=1147248
 
  Hmm, so far tmpfiles always adjust access modes, for all types of
  lines, if that's possible. I think this makes sense. The bug
  referenced above seems to suggest though that the access mode of the
  /dev/fuse file node is specified differently in two places
  though. This sounds like something to fix first?
 
 Well, the /run/tmpfiles.d/kmod.conf one is what the kernel exposes,
 and then the udev rules overrides this. We could surely fix this case,
 but in general I think we should expect that these may differ.
 
 To me it seems that we should not create devices nodes at all, except
 in systemd-tmpfiles-setup-dev.service, the reason being that udev
 rules are only applied to static nodes at udev startup, so any device
 nodes created (or changed) after that may end up with the wrong
 permissions (as seen here).

Hmm, so does this mean that the kmod tmpfiles converter really should
suffixits lines with the exclamation mark? That way, only invocation
of tmpfiles with --boot would honour those files, which are the ones
we start at boot.

Does that make sense?

Lennart

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

Re: [systemd-devel] Waiting for nspawn services

2014-10-27 Thread Rich Freeman

On Mon, Oct 27, 2014 at 11:32 AM, Lennart Poettering
lenn...@poettering.net wrote:
 Network namespaces are relevant for the process that originally binds
 the sockets. In the case of socket-activated containers that would be
 the host. If you then pass the fds into the containers and those are
 locked into their own namespaces, then any sockets they create and
 bind would be from their own namepsace, but the one they got passed in
 would still be from the original host namespace. If they then accept a
 connection on that passed-in socket that connection socket would also
 be part of the same host namespace -- not of the containers.


In case it wasn't clear - I'm talking about network namespaces with
ethernet bridging - not just an isolated network namespace without any
network access at all.  That said, I could certainly see why the
latter would be useful.

So, if the host is 10.0.0.1, then mysql would normally listen on
10.0.0.2:3306.  One of my goals here was to keep everything running on
its native port and dedicated IP to minimize configuration.  For
example, I can run ssh on 10.0.0.2 and let it have port 22, and not
worry about the other 3 containers running ssh on port 22.

I suppose I could have systemd listen on 10.0.0.1:x and pass that
connection over to mysql.  However, then I need to point services to
10.0.0.1 and not 10.0.0.2.

This is why I alluded to it being useful to be able to depend on
services on remote hosts.  I completely agree that doing this in a
clean way without resorting to polling would involve a bit of work.
My own workaround in this case was basically going to amount to
polling.

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

Re: [systemd-devel] [PATCH] tmpfiles: only change device permissions if mknod succeeded

2014-10-27 Thread Tom Gundersen

On Mon, Oct 27, 2014 at 4:48 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Sat, 25.10.14 01:36, Tom Gundersen (t...@jklm.no) wrote:

 On Mon, Oct 20, 2014 at 9:32 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 14.10.14 16:19, Jan Synacek (jsyna...@redhat.com) wrote:
 
  https://bugzilla.redhat.com/show_bug.cgi?id=1147248
 
  Hmm, so far tmpfiles always adjust access modes, for all types of
  lines, if that's possible. I think this makes sense. The bug
  referenced above seems to suggest though that the access mode of the
  /dev/fuse file node is specified differently in two places
  though. This sounds like something to fix first?

 Well, the /run/tmpfiles.d/kmod.conf one is what the kernel exposes,
 and then the udev rules overrides this. We could surely fix this case,
 but in general I think we should expect that these may differ.

 To me it seems that we should not create devices nodes at all, except
 in systemd-tmpfiles-setup-dev.service, the reason being that udev
 rules are only applied to static nodes at udev startup, so any device
 nodes created (or changed) after that may end up with the wrong
 permissions (as seen here).

 Hmm, so does this mean that the kmod tmpfiles converter really should
 suffixits lines with the exclamation mark? That way, only invocation
 of tmpfiles with --boot would honour those files, which are the ones
 we start at boot.

 Does that make sense?


Yes, indeed, this is precisely what we want. I had missed that
feature. I'll do a patch.

Thanks!

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

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

2014-10-27 Thread Martin Pitt

Lennart Poettering [2014-10-27 16:37 +0100]:
 After all, moving those files away from /etc doesn't really make
 sense on split-/usr systems anyway, as it wouldn't help monopolizing
 vendor data in /usr really... Or at least I think the --usr stuff is
 really about monopolizing vendor data in /usr, and if you have a
 split-/usr system then that goal is moot anyway...

It still does make sense. On those systems, the OS == /bin, /sbin,
/lib*, /usr, /boot. Except for that it's pretty much like a single
/usr tree.

I. e. with this one can still build system images with these dirs
being r/o, and it also avoids an architecture-specific and big binary
file in an otherwise config file only /etc. (Yes, /etc/ld.so.cache
is somewhat of an exception, but it's arch independent, text, and
small).

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

On Mon, 27.10.14 16:53, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Lennart Poettering [2014-10-27 16:37 +0100]:
  After all, moving those files away from /etc doesn't really make
  sense on split-/usr systems anyway, as it wouldn't help monopolizing
  vendor data in /usr really... Or at least I think the --usr stuff is
  really about monopolizing vendor data in /usr, and if you have a
  split-/usr system then that goal is moot anyway...
 
 It still does make sense. On those systems, the OS == /bin, /sbin,
 /lib*, /usr, /boot. Except for that it's pretty much like a single
 /usr tree.

No, it's still a mess.

Anyway, please let's try to design our stuff in a way that everything
is nice and clean on systems where /usr is monopolized properly. And
other systems shall be supported, but it's not what we pick the naming
for.

 I. e. with this one can still build system images with these dirs
 being r/o, and it also avoids an architecture-specific and big binary
 file in an otherwise config file only /etc. (Yes, /etc/ld.so.cache
 is somewhat of an exception, but it's arch independent, text, and
 small).

/etc/ld.so.cache is not a text file. It's binary.

BTW, after the hwdb thing you probably want to do something similar
for the journal catalog database.

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] Starting configurable set of services first

2014-10-27 Thread Umut Tezduyar Lindskog

On Wed, Oct 22, 2014 at 7:44 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 02.09.14 10:06, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,

 I would like to start a configurable set of services first and the
 services are wanted by multi-user.target. I am using a service to jump
 to multi-user.target and I was wondering if we can support this use
 case natively by systemd.

 multi-user.target.wants
   A.service
   B.service
   C.service
   D.service

 default.target  stage.target
 stage.target.wants (These are set by generator)
   A.service
   C.service
   switcher.service

 switcher.service (This is generated by generator)
   [Unit]
   Description=Switch to multi-user.targe
   After=A.service C.service
   [Service]
   Type=oneshot
   RemainAfterExit=yes
   ExecStart=/usr/bin/systemctl --no-block start multi-user.target

 This way I am jumping from one target to another target during runtime.

 - What stage.target wants is dynamic. If it was static, my job would
 have been very simple.
 - I am aware of StartupCPUShares but it is not the ultimate solution
 A) there is a configurable minimum quota in CFS which still gives CPU
 to other processes. B) We still fork other processes and this causes
 changes in timeout values of other processes.
 - Adding dynamically After= to B and D service files is not the
 ultimate solution either because B and D might be socket/dbus
 activated by A or C.

 Should this be something we should support natively by systemd?

 As discussed at th systemd hackfest: I am a bit conservative about
 this as it introduces plenty chance for deadlocks, where services
 might trigger/request some other unit but we'd delay it until the
 later stage...

 I think the implementation you chose is actually pretty good. I am not
 sure though that we should do this upstream. I mean, I really would
 prefer if we'd dump as much work as possible on the IO elevator and
 CPU scheduler, and then adjust the priorities of it to give hints what
 matters more. Trying to second-guess the elevator and scheduler in
 userspace feels a bit like chickening out to me, even though I am sure
 that it might be something that one has to do for now, in the real
 world...

I am not agreeing on this. Once you fork the process, it will always
get some CPU even though you play with cpu.shares, sched_latency_ns,
sched_min_granularity_ns. My goal is not forking it at all until high
priority services are activated. Just like Before=, After=.


 There's one change I'd really like to see done though in systemd, that
 might make things nicer for you. Currently, it's undefined in systemd
 which job is dispatched first, if multiple jobs can be executed. That
 means when we are about to fork off a number of processes there's no
 way to control which one gets forked off first. I'd be willing to
 merge a patch that turns this into a prioq, so that some priority
 value can be configured (or automatically derived) for each unit, and
 the one with the highest priority would win, and be processed
 first. This would not provide you with everything what you want, but
 would make things a bit nicer when we dump all possible work on the
 scheduler/elevator, because after all we cannot really dump all work
 at the same time, and hence should at least give you control in which
 order to dump it, if you follow what I mean.

I have understood your propose with the exception of one thing. When
do we start dispatching low priority jobs? When the high priority jobs
are dispatched/forked or when the high priority jobs are
dispatched/activated?

Umut


 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] Waiting for nspawn services

On Mon, 27.10.14 11:49, Rich Freeman (r-syst...@thefreemanclan.net) wrote:

 On Mon, Oct 27, 2014 at 11:32 AM, Lennart Poettering
 lenn...@poettering.net wrote:
  Network namespaces are relevant for the process that originally binds
  the sockets. In the case of socket-activated containers that would be
  the host. If you then pass the fds into the containers and those are
  locked into their own namespaces, then any sockets they create and
  bind would be from their own namepsace, but the one they got passed in
  would still be from the original host namespace. If they then accept a
  connection on that passed-in socket that connection socket would also
  be part of the same host namespace -- not of the containers.
 
 
 In case it wasn't clear - I'm talking about network namespaces with
 ethernet bridging - not just an isolated network namespace without any
 network access at all.  That said, I could certainly see why the
 latter would be useful.
 
 So, if the host is 10.0.0.1, then mysql would normally listen on
 10.0.0.2:3306.  One of my goals here was to keep everything running on
 its native port and dedicated IP to minimize configuration.  For
 example, I can run ssh on 10.0.0.2 and let it have port 22, and not
 worry about the other 3 containers running ssh on port 22.
 
 I suppose I could have systemd listen on 10.0.0.1:x and pass that
 connection over to mysql.  However, then I need to point services to
 10.0.0.1 and not 10.0.0.2.

Correct.

 This is why I alluded to it being useful to be able to depend on
 services on remote hosts.  I completely agree that doing this in a
 clean way without resorting to polling would involve a bit of work.
 My own workaround in this case was basically going to amount to
 polling.

There has been a TODO list item for a while to allow .socket units to
be created within specific namespaces. I figure with that in place you
could actually make this work, by creating the mysql socket with
IP_FREEBIND in a new namespace, and then make nspawn ultimately take
possession of it, or so...

But dunno, maybe not, sounds like a ton of races still

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] Starting configurable set of services first

On Mon, 27.10.14 17:06, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

  Should this be something we should support natively by systemd?
 
  As discussed at th systemd hackfest: I am a bit conservative about
  this as it introduces plenty chance for deadlocks, where services
  might trigger/request some other unit but we'd delay it until the
  later stage...
 
  I think the implementation you chose is actually pretty good. I am not
  sure though that we should do this upstream. I mean, I really would
  prefer if we'd dump as much work as possible on the IO elevator and
  CPU scheduler, and then adjust the priorities of it to give hints what
  matters more. Trying to second-guess the elevator and scheduler in
  userspace feels a bit like chickening out to me, even though I am sure
  that it might be something that one has to do for now, in the real
  world...
 
 I am not agreeing on this. Once you fork the process, it will always
 get some CPU even though you play with cpu.shares, sched_latency_ns,
 sched_min_granularity_ns. My goal is not forking it at all until high
 priority services are activated. Just like Before=, After=.

That sounds like a limitation of the kernel's scheduler and the cpu
cgroup controller, no?

If there's no way to ensure that a process we fork() off gets exactly
zero CPU until the point where otherwise nothing needs to run, then
that's something to fix in the kernel, no?

I really would like to stay away from working around kernel
limitations in userspace if we can. In particular since doing this in
userspace is an invitation of all kinds of deadlocks where we would
refuse activating certain low-priority units even though high-priority
ones are waiting for it.

Note that by adding a sufficeint number of ordering deps for systemd
units, and making sure all services use sd_notify() late enough to
signal full completion of their initializatin you can already
completely remove any possible parallel execution in systemd. i.e. for
all possible combination of two units that could be run at the same
time you could add a manual dependency (of course always making sure
manually that you keep thigns cycle-free), which systemd would then
execute strictly linearly, since it will adhere to those deps...

  There's one change I'd really like to see done though in systemd, that
  might make things nicer for you. Currently, it's undefined in systemd
  which job is dispatched first, if multiple jobs can be executed. That
  means when we are about to fork off a number of processes there's no
  way to control which one gets forked off first. I'd be willing to
  merge a patch that turns this into a prioq, so that some priority
  value can be configured (or automatically derived) for each unit, and
  the one with the highest priority would win, and be processed
  first. This would not provide you with everything what you want, but
  would make things a bit nicer when we dump all possible work on the
  scheduler/elevator, because after all we cannot really dump all work
  at the same time, and hence should at least give you control in which
  order to dump it, if you follow what I mean.
 
 I have understood your propose with the exception of one thing. When
 do we start dispatching low priority jobs? When the high priority jobs
 are dispatched/forked or when the high priority jobs are
 dispatched/activated?

We'd simply process all queued jobs that are runnable in the order of
their priority. This means:

1) we'd still dispatch only one job at a time (i.e. fork() off one
   process at a time) 
2) we'd dispatch all jobs as quickly as possible, as soon as they are
   runnable
3) If two jobs are runnable at the same time, we'd dispatch the one
   with the higher priority first.

Lennart

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

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

2014-10-27 Thread Michael Biebl

2014-10-27 16:37 GMT+01:00 Lennart Poettering lenn...@poettering.net:
 Well, I think that's OK really. We want to stay compatible with
 split-usr distros, but that kind of setup is really not at the focus
 of what we design for.

 I still think this should be named --usr. After all, moving those
 files away from /etc doesn't really make sense on split-/usr systems
 anyway, as it wouldn't help monopolizing vendor data in /usr
 really... Or at least I think the --usr stuff is really about
 monopolizing vendor data in /usr, and if you have a split-/usr system
 then that goal is moot anyway...

Well, as I suggested earlier, --system sounds just more logical to me.
This switch after all is for creating a cache for the system supplied
hwdb files.
And it has the nice benefit of being without ambiguity for both
split-usr and merged-usr systems.
So I don't see a good reason to not pick that original suggestion from
Kay (without the -only).

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] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

On Mon, 27.10.14 17:25, Michael Biebl (mbi...@gmail.com) wrote:

 2014-10-27 16:37 GMT+01:00 Lennart Poettering lenn...@poettering.net:
  Well, I think that's OK really. We want to stay compatible with
  split-usr distros, but that kind of setup is really not at the focus
  of what we design for.
 
  I still think this should be named --usr. After all, moving those
  files away from /etc doesn't really make sense on split-/usr systems
  anyway, as it wouldn't help monopolizing vendor data in /usr
  really... Or at least I think the --usr stuff is really about
  monopolizing vendor data in /usr, and if you have a split-/usr system
  then that goal is moot anyway...
 
 Well, as I suggested earlier, --system sounds just more logical to me.
 This switch after all is for creating a cache for the system supplied
 hwdb files.
 And it has the nice benefit of being without ambiguity for both
 split-usr and merged-usr systems.
 So I don't see a good reason to not pick that original suggestion from
 Kay (without the -only).

Well. system is usually used in the context of user context
vs. system context by systemd. The former being something
unpriviliged that runs under user identities of normal users, while
the latter is everything that is running underneat that. This spills
into a lot of different things, for example there's
/etc/systemd/user/ and /etc/systemd/system/ for the unit files for
systemd: the former are the ones to be executed by systemd user
managers, the latter ones used by systemd system managers.

Now, the distinction udevadm is supposed to make here though is very
different, it is a distinction between /etc and /usr, i.e. between
vendor data and local configuration. Using the word system to
distuingish this is highly misleading hence.

Still, --usr is the most appropriate name, even if on split-usr
distros things might appear slightly weird then.

Lennart

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

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

2014-10-27 Thread Michael Biebl

2014-10-27 17:31 GMT+01:00 Lennart Poettering mzerq...@0pointer.de:

 Now, the distinction udevadm is supposed to make here though is very
 different, it is a distinction between /etc and /usr, i.e. between
 vendor data and local configuration. Using the word system to
 distuingish this is highly misleading hence.
 Still, --usr is the most appropriate name, even if on split-usr
 distros things might appear slightly weird then.

Quoting the udev man page:
  paraThe hwdb files are read from the files located in the
  system hwdb directory filename/usr/lib/udev/hwdb.d/filename,

So naming that switch --system is only consistent if it acts on the
system hwdb files only.


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

[systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again

Some time ago, I have complained that some boots are unsuccessful, 
because the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 
symlink (which should point to /dev/sda2) is not created by udev in the 
initramfs (which uses dracut). Thankfully, people on IRC have suggested 
some useful debugging options:


systemd.log_level=debug rd.udev.log-priority=debug

So now I have a SOS report. It is over 1 MB, so not attached. The useful 
lines are:


[3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda), 
skipping event handling: Resource temporarily unavailable
[3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda), 
skipping event handling: Resource temporarily unavailable


Let me complain here that these error messages still don't contain the 
complete picture. How am I supposed to know which program in my 
dracut-created initramfs locks /dev/sda and interferes with udev event 
handling?


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

Re: [systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

On Mon, 27.10.14 17:44, Michael Biebl (mbi...@gmail.com) wrote:

 2014-10-27 17:31 GMT+01:00 Lennart Poettering mzerq...@0pointer.de:
 
  Now, the distinction udevadm is supposed to make here though is very
  different, it is a distinction between /etc and /usr, i.e. between
  vendor data and local configuration. Using the word system to
  distuingish this is highly misleading hence.
  Still, --usr is the most appropriate name, even if on split-usr
  distros things might appear slightly weird then.
 
 Quoting the udev man page:
   paraThe hwdb files are read from the files located in the
   system hwdb directory filename/usr/lib/udev/hwdb.d/filename,
 
 So naming that switch --system is only consistent if it acts on the
 system hwdb files only.

Well, we probably should change the udev man page to not use system
in this context then, as it is really confusing.

That said, man documentation we can change any time, they are not
API. A new command line switch however is API, and hence needs much
more careful naming, because we cannot rename it later on.

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] On /dev/disk/by-id/ata-...-part2 missing, again

On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote:

 Some time ago, I have complained that some boots are unsuccessful, because
 the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which
 should point to /dev/sda2) is not created by udev in the initramfs (which
 uses dracut). Thankfully, people on IRC have suggested some useful debugging
 options:
 
 systemd.log_level=debug rd.udev.log-priority=debug
 
 So now I have a SOS report. It is over 1 MB, so not attached. The useful
 lines are:
 
 [3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda),
 skipping event handling: Resource temporarily unavailable
 [3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda),
 skipping event handling: Resource temporarily unavailable
 
 Let me complain here that these error messages still don't contain the
 complete picture. How am I supposed to know which program in my
 dracut-created initramfs locks /dev/sda and interferes with udev event
 handling?

Most likely you are either using a too old util-linux, whose use of
BSD locks conflict's with udev's use of it. (fsck -l)

Please always check README, it will let you know precisely which
release of util-linux you need at least.

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] On /dev/disk/by-id/ata-...-part2 missing, again


27.10.2014 21:49, Lennart Poettering wrote:

On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote:


Some time ago, I have complained that some boots are unsuccessful, because
the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which
should point to /dev/sda2) is not created by udev in the initramfs (which
uses dracut). Thankfully, people on IRC have suggested some useful debugging
options:

systemd.log_level=debug rd.udev.log-priority=debug

So now I have a SOS report. It is over 1 MB, so not attached. The useful
lines are:

[3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda),
skipping event handling: Resource temporarily unavailable
[3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda),
skipping event handling: Resource temporarily unavailable

Let me complain here that these error messages still don't contain the
complete picture. How am I supposed to know which program in my
dracut-created initramfs locks /dev/sda and interferes with udev event
handling?


Most likely you are either using a too old util-linux, whose use of
BSD locks conflict's with udev's use of it. (fsck -l)

Please always check README, it will let you know precisely which
release of util-linux you need at least.


I use fsck from util-linux 2.25.1. Verified by extracting the initramfs. 
According to the README, this version should be OK, so it must be 
something else.


Here is a list of files in my initramfs which, according to grep, 
contain the word flock:


./usr/bin/flock
./usr/lib64/systemd/systemd-udevd
./usr/lib64/systemd/systemd-fsck
./usr/lib64/libseccomp.so.2.1.1
./usr/lib64/libgpg-error.so.0.12.1
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/afs/kafs.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/cifs/cifs.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/fuse/fuse.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/gfs2/gfs2.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/lockd/lockd.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/nfs/nfs.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/nfs/nfsv4.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/ocfs2/ocfs2.ko
./lib64/modules/3.17.1-gentoo-r1/kernel/fs/xfs/xfs.ko
./lib64/modules/3.17.1-gentoo-r1/modules.symbols
./lib64/dracut-crypt-lib.sh
./lib64/libdevmapper-event.so.1.02
./lib64/liblvm2cmd.so.2.02
./lib64/libaudit.so.1.0.0
./lib64/libc-2.19.so
./lib64/libuuid.so.1.3.0
./lib64/libmount.so.1.1.0
./lib64/libpthread-2.19.so
./lib64/libmultipath.so.0
./sbin/lvm
./sbin/fsck
./sbin/btrfs
./sbin/dhclient
./sbin/btrfsck


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

Re: [systemd-devel] [PATCH] tmpfiles: only change device permissions if mknod succeeded

2014-10-27 Thread Tom Gundersen

On Mon, Oct 27, 2014 at 4:53 PM, Tom Gundersen t...@jklm.no wrote:
 On Mon, Oct 27, 2014 at 4:48 PM, Lennart Poettering
 mzerq...@0pointer.de wrote:
 On Sat, 25.10.14 01:36, Tom Gundersen (t...@jklm.no) wrote:

 On Mon, Oct 20, 2014 at 9:32 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 14.10.14 16:19, Jan Synacek (jsyna...@redhat.com) wrote:
 
  https://bugzilla.redhat.com/show_bug.cgi?id=1147248
 
  Hmm, so far tmpfiles always adjust access modes, for all types of
  lines, if that's possible. I think this makes sense. The bug
  referenced above seems to suggest though that the access mode of the
  /dev/fuse file node is specified differently in two places
  though. This sounds like something to fix first?

 Well, the /run/tmpfiles.d/kmod.conf one is what the kernel exposes,
 and then the udev rules overrides this. We could surely fix this case,
 but in general I think we should expect that these may differ.

 To me it seems that we should not create devices nodes at all, except
 in systemd-tmpfiles-setup-dev.service, the reason being that udev
 rules are only applied to static nodes at udev startup, so any device
 nodes created (or changed) after that may end up with the wrong
 permissions (as seen here).

 Hmm, so does this mean that the kmod tmpfiles converter really should
 suffixits lines with the exclamation mark? That way, only invocation
 of tmpfiles with --boot would honour those files, which are the ones
 we start at boot.

 Does that make sense?


 Yes, indeed, this is precisely what we want. I had missed that
 feature. I'll do a patch.


And done: http://permalink.gmane.org/gmane.linux.kernel.modules/1402.

Jan, does this look like it solves the original problem?

Cheers,

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

Re: [systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again

On Mon, 27.10.14 21:57, Alexander E. Patrakov (patra...@gmail.com) wrote:

 27.10.2014 21:49, Lennart Poettering wrote:
 On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote:
 
 Some time ago, I have complained that some boots are unsuccessful, because
 the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which
 should point to /dev/sda2) is not created by udev in the initramfs (which
 uses dracut). Thankfully, people on IRC have suggested some useful debugging
 options:
 
 systemd.log_level=debug rd.udev.log-priority=debug
 
 So now I have a SOS report. It is over 1 MB, so not attached. The useful
 lines are:
 
 [3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda),
 skipping event handling: Resource temporarily unavailable
 [3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda),
 skipping event handling: Resource temporarily unavailable
 
 Let me complain here that these error messages still don't contain the
 complete picture. How am I supposed to know which program in my
 dracut-created initramfs locks /dev/sda and interferes with udev event
 handling?
 
 Most likely you are either using a too old util-linux, whose use of
 BSD locks conflict's with udev's use of it. (fsck -l)
 
 Please always check README, it will let you know precisely which
 release of util-linux you need at least.
 
 I use fsck from util-linux 2.25.1. Verified by extracting the initramfs.
 According to the README, this version should be OK, so it must be something
 else.

Hmm, please use lslocks or /proc/locks to figure out which process
might have the device nodes locked.


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] How soon after login can I rely on systemd --user having reached sockets.target?

On Sun, 26.10.14 20:47, Damien Robert (damien.olivier.rob...@gmail.com) wrote:

 From Lennart Poettering, Fri 24 Oct 2014 at 01:09:56 (+0200) :
  So, I really would prefer if this logic wasn't just a hook, but
  actually the primary action of logging in graphically via a display
  manager.
 
 Ok, and login off would just be something like 'systemctl stop
 gnome.target'?

Could be, yeah.

  On multiseat setups you could hence merge multiple seats into
  a single meta-session with the workspace spanning all of the seats if
  you keep logging in with the same user.
 
 I could imagine having several virtual machines that connects via ssh -X to
 the main computer to launch graphical sessions (so that there is no need to
 install it on the vms); in this case there would be a need to start the
 same target but with different displays. And the solution I outlined on my
 preceding mail using instances target templates work very well (and it does
 since a long time, I was very impressed when I tried it and it worked out
 of the box); but having 'hooks' on logind would help a bit.

Well, the way I think remoting espcially with the advent of wayland
should work is that when you cannot via VNC/Spice or similar, this new
screen also gets added to the existing meta-session as another
display. In this case these VNC/spice displays would simply show the
same contents as any pre-existing sesion already though by default,
instead of extending the virtual screen real estate...

(and to turn this around: even in multi-head setups such a clone mode
might make sense too: on each display you log into you could
optionally just clone what you already see on the others...)

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] On /dev/disk/by-id/ata-...-part2 missing, again


27.10.2014 22:13, Lennart Poettering wrote:

On Mon, 27.10.14 21:57, Alexander E. Patrakov (patra...@gmail.com) wrote:


27.10.2014 21:49, Lennart Poettering wrote:

On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote:


Some time ago, I have complained that some boots are unsuccessful, because
the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which
should point to /dev/sda2) is not created by udev in the initramfs (which
uses dracut). Thankfully, people on IRC have suggested some useful debugging
options:

systemd.log_level=debug rd.udev.log-priority=debug

So now I have a SOS report. It is over 1 MB, so not attached. The useful
lines are:

[3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda),
skipping event handling: Resource temporarily unavailable
[3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda),
skipping event handling: Resource temporarily unavailable

Let me complain here that these error messages still don't contain the
complete picture. How am I supposed to know which program in my
dracut-created initramfs locks /dev/sda and interferes with udev event
handling?


Most likely you are either using a too old util-linux, whose use of
BSD locks conflict's with udev's use of it. (fsck -l)

Please always check README, it will let you know precisely which
release of util-linux you need at least.


I use fsck from util-linux 2.25.1. Verified by extracting the initramfs.
According to the README, this version should be OK, so it must be something
else.


Hmm, please use lslocks or /proc/locks to figure out which process
might have the device nodes locked.


Thanks for the pointer. It is good to know that the information is 
available in the kernel.


Unfortunately, it is not possible to run the lslocks program manually or 
see the contents of /proc/locks exactly at the moment when some stupid 
program decides to lock the device. Especially since this does not 
happen at every boot.


I think that printing the equivalent of the lslocks output directly from 
udevd when failing to lock the device would be a useful debugging aid. 
Of course, this feature request only applies when udev.log-priority=debug.


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

Re: [systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again

On Mon, 27.10.14 22:22, Alexander E. Patrakov (patra...@gmail.com) wrote:

 Thanks for the pointer. It is good to know that the information is available
 in the kernel.
 
 Unfortunately, it is not possible to run the lslocks program manually or see
 the contents of /proc/locks exactly at the moment when some stupid program
 decides to lock the device. Especially since this does not happen at every
 boot.
 
 I think that printing the equivalent of the lslocks output directly from
 udevd when failing to lock the device would be a useful debugging aid. Of
 course, this feature request only applies when udev.log-priority=debug.

Well, to my knowledge there is not efficient way to query this
information, so we probably shouldn't do that.

If fsck is not the process that takes the locks, I bet LVM is. Are you
using that? Consider turning it off.

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] On /dev/disk/by-id/ata-...-part2 missing, again


27.10.2014 22:28, Lennart Poettering wrote:

On Mon, 27.10.14 22:22, Alexander E. Patrakov (patra...@gmail.com) wrote:


Thanks for the pointer. It is good to know that the information is available
in the kernel.

Unfortunately, it is not possible to run the lslocks program manually or see
the contents of /proc/locks exactly at the moment when some stupid program
decides to lock the device. Especially since this does not happen at every
boot.

I think that printing the equivalent of the lslocks output directly from
udevd when failing to lock the device would be a useful debugging aid. Of
course, this feature request only applies when udev.log-priority=debug.


Well, to my knowledge there is not efficient way to query this
information, so we probably shouldn't do that.


That's why I suggested doing it only when debugging is enabled via the 
kernel command line. Otherwise, all this is left is guessing and code 
audits - which is worse than the inefficient search for the smoking gun :)



If fsck is not the process that takes the locks, I bet LVM is. Are you
using that? Consider turning it off.


On this machine, LVM is not actually used, but is pulled in as a 
dependency of udisks-2.1.3. And that dependency is conditional, on the 
cryptsetup USE flag that is also useless on this desktop. So I think I 
can indeed remove the lvm binary from this desktop (but not from the 
Sony laptop). Thanks again!


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

Re: [systemd-devel] [PATCH] manager: do not print anything while passwords are being queried

On Sun, 26.10.14 05:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 https://bugs.freedesktop.org/show_bug.cgi?id=73942

So in really old systemd versions I had a concept in place of never
printing to the console if there was a controlling process on it. The
kernel's concept of a controlling process we used as a somewhat
natural synchronization on the tty. However, this functionality has
pretty much been lost. 

I am not entirely sure what happened between all the reworks there,
but maybe we should just resurrect that scheme? Suppressing output on
the console if there's a controlling process would not just
automatically avoid mixing password queries with getty login prompts,
but also all other cases where some process wants exclusive ownership
of the tty.

Using the controlling tty for this would be somewhat nice, as all
users of the tty would just work with it. Another idea could be to use
BSD locks on the /dev/console device node. Everybody with access on
the tty could take one of the logs. We would even have R/W locks then,
where the status output would just take a read lock, while things like
gettys and the password stuff would take a full write lock.

Either solution appears nicer to me then explicitly hooking up PID 1
with the ask-password stuff, in particularly, because we really should
look into moving hte ask-password onto kdbus and the kernel keyring,
and we hence shouldn't add cross-links to it now, where we already
know it should probably go away the way it currently is. 

The BSD lock scheme would be pretty much race-free afaics. The
controlling process stuff otoh would be race-ful, probably to the same
level as watching the ask-password stuff.

Anyway, opinions on this?

I am slightly leaning towards the BSD lock solution I must say. In
particular as it is compatible with the story we kinda want to push
people using /dev/ttyS* towards, who really should use BSD locks too,
instead of the awful LCK.. files...

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] On /dev/disk/by-id/ata-...-part2 missing, again

On Mon, 27.10.14 22:35, Alexander E. Patrakov (patra...@gmail.com) wrote:

 27.10.2014 22:28, Lennart Poettering wrote:
 On Mon, 27.10.14 22:22, Alexander E. Patrakov (patra...@gmail.com) wrote:
 
 Thanks for the pointer. It is good to know that the information is available
 in the kernel.
 
 Unfortunately, it is not possible to run the lslocks program manually or see
 the contents of /proc/locks exactly at the moment when some stupid program
 decides to lock the device. Especially since this does not happen at every
 boot.
 
 I think that printing the equivalent of the lslocks output directly from
 udevd when failing to lock the device would be a useful debugging aid. Of
 course, this feature request only applies when udev.log-priority=debug.
 
 Well, to my knowledge there is not efficient way to query this
 information, so we probably shouldn't do that.
 
 That's why I suggested doing it only when debugging is enabled via the
 kernel command line. Otherwise, all this is left is guessing and code audits
 - which is worse than the inefficient search for the smoking gun :)

Well, it makes sense adding debugging functionality like this if this
is sometimes that happens to end users all the time because of
end-user mistakes. However, I am pretty sure in this case this is just
a packaging bug, which allowed incompatible versions of software to
run together.

 If fsck is not the process that takes the locks, I bet LVM is. Are you
 using that? Consider turning it off.
 
 On this machine, LVM is not actually used, but is pulled in as a dependency
 of udisks-2.1.3. And that dependency is conditional, on the cryptsetup USE
 flag that is also useless on this desktop. So I think I can indeed remove
 the lvm binary from this desktop (but not from the Sony laptop). Thanks
 again!

Humm. udisks doesn't make use of LVM. Not sure what distro you are
using, but the dependency chain seems broken there... cryptsetup is
certainly not useless on the desktop, but actually independent of
LVM. If your distribution implies LVM if cryptsetup is on, then your
distro is really really broken.

Lennart

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

Re: [systemd-devel] [PATCH 1/4] manager: print a warning after 2/3 of the start timeout

On Sat, 25.10.14 21:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 ---
 This could use some more polishing, but is useful as is I think...

I love the idea!

 +static int manager_log_running_jobs(Manager *m) {
 +unsigned n;
 +
 +assert(m);
 +
 +n = hashmap_size(m-jobs);
 +
 +if (n  0) {
 +unsigned i = 0;
 +_cleanup_strv_free_ char **strv;
 +_cleanup_free_ char *all = NULL;
 +
 +Iterator it;
 +Job *j;
 +
 +strv = new(char*, n + 1);
 +if (!strv)
 +return log_oom();
 +
 +HASHMAP_FOREACH(j, m-jobs, it) {
 +strv[i] = strjoin(j-unit-id, /, 
 job_type_to_string(j-type),
 +  /, 
 job_state_to_string(j-state), NULL);
 +if (!strv[i])
 +return log_oom();
 +i++;
 +}
 +strv[i] = NULL;
 +
 +all = strv_join(strv, ,\n\t);
 +if (!all)
 +return log_oom();
 +
 +log_info(Active jobs (%u running):\n\t%s., 
 m-n_running_jobs, all);
 +} else
 +log_info(No jobs seem to be running.);
 +
 +return 0;
 +}

A long-standing TODO list item has been to print something like this
if the user hits C-A-Del 3 times within 1s or so (under the assumption
that he might do this if shutdown gets stuck for some reason). If we have
this function in place, maybe that's something to quickly hookup with
C-A-Del too? (using the ratelimit infrastruturce should make the patch
for detecting the 3-times-within-1s thing trivial)...

 +
  static int manager_watch_jobs_in_progress(Manager *m) {
  usec_t next;
  
 @@ -1015,15 +1054,39 @@ static int manager_distribute_fds(Manager *m, FDSet 
 *fds) {
  
  static int on_start_timeout(sd_event_source *s, usec_t usec, void *userdata) 
 {
  Manager *m = userdata;
 +int r;
  
  assert(s);
  assert(m);
  
 +if (!m-start_timeout_warned) {
 +log_warning(2/3 of the start timeout have passed.);
 +m-start_timeout_warned = true;
 +
 +(void) manager_log_running_jobs(m);
 +
 +r = sd_event_source_set_time(m-start_timeout_event_source,
 + now(CLOCK_MONOTONIC) +
 m-start_timeout_usec / 3);

I think it would be nicer to use the original startup timestamp for
this, instead of invoking now() here again...

In fact, I think I should have used m-userspace_timestamp.monotonic
as base for this in the first place

Lennart

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

Re: [systemd-devel] [PATCH 3/4] manager: stop start timeout when sysinit.target is reached

On Sat, 25.10.14 21:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

  
 +if (result == JOB_DONE  unit_has_name(u, SPECIAL_SYSINIT_TARGET))
 +manager_cancel_start_timeout(u-manager);
 +

I'd really prefer to hook this up with manager_state(), so that we
don't have to hardcode the target name more than once, and so that we
know that the rescue/emergency mode is properly handled...

Lennart

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

Re: [systemd-devel] [PATCH] login: remove multi-seat-x

2014-10-27 Thread Laércio de Sousa

Lennart,

I've told you some time ago that Xorg-server since release 1.16 no longer
requires multi-seat-x wrapper.
Em 27/10/2014 11:00, Lennart Poettering lenn...@poettering.net escreveu:

 On Sun, 26.10.14 00:30, Timofey Titovets (nefelim...@gmail.com) wrote:

  Completed TODO: remove multi-seat-x

 Hmm, I don't remember the details of this, did X release a new version
 which makes this tool unnecessary? I think they commited code that
 made it unnecessary, but did they actually release it?

 
  From 57b2655d2041d2bb2e9b25bef577ead9b27ce6ee Mon Sep 17 00:00:00 2001
  From: Timofey Titovets nefelim...@gmail.com
  Date: Sun, 26 Oct 2014 00:17:24 +0300
  Subject: [PATCH] login: remove multi-seat-x
 
  ---
   Makefile.am  |  14 --
   TODO |   2 -
   configure.ac |   8 
   src/login/multi-seat-x.c | 108
  ---
   4 files changed, 132 deletions(-)
   delete mode 100644 src/login/multi-seat-x.c
 
  diff --git a/Makefile.am b/Makefile.am
  index fae946a..fc86b45 100644
  --- a/Makefile.am
  +++ b/Makefile.am
  @@ -5400,20 +5400,6 @@ SYSTEM_UNIT_ALIASES += \
   BUSNAMES_TARGET_WANTS += \
org.freedesktop.login1.busname
 
  -if ENABLE_MULTI_SEAT_X
  -
  -systemd_multi_seat_x_SOURCES = \
  - src/login/multi-seat-x.c
  -
  -systemd_multi_seat_x_LDADD = \
  - libsystemd-label.la \
  - libsystemd-shared.la
  -
  -rootlibexec_PROGRAMS += \
  - systemd-multi-seat-x
  -
  -endif
  -
   dist_udevrules_DATA += \
src/login/70-uaccess.rules \
src/login/70-power-switch.rules
  diff --git a/TODO b/TODO
  index ed00661..195ca55 100644
  --- a/TODO
  +++ b/TODO
  @@ -102,8 +102,6 @@ Features:
 
   * maybe introduce AssertXYZ= similar to ConditionXYZ= that causes a
 unit to
  fail (instead of skipping it) if some condition is not true...
 
  -* remove multi-seat-x now
  -
   * refcounting in sd-resolve is borked
 
   * exponential backoff in timesyncd and resolved when we cannot reach a
  server
  diff --git a/configure.ac b/configure.ac
  index c3b4ea3..f69eb82 100644
  --- a/configure.ac
  +++ b/configure.ac
  @@ -1063,14 +1063,6 @@ fi
   AM_CONDITIONAL(ENABLE_EFI, [test x$have_efi = xyes])
 
   #
 --
  -have_multi_seat_x=no
  -AC_ARG_ENABLE(multi_seat_x, AS_HELP_STRING([--disable-multi-seat-x], [do
  not build multi-seat-x]))
  -if test x$enable_multi_seat_x != xno; then
  -have_multi_seat_x=yes
  -fi
  -AM_CONDITIONAL(ENABLE_MULTI_SEAT_X, [test $have_multi_seat_x = yes])
  -
  -#
 --
   have_terminal=no
   AC_ARG_ENABLE(terminal, AS_HELP_STRING([--enable-terminal], [enable
  terminal support]))
   if test x$enable_terminal = xyes; then
  diff --git a/src/login/multi-seat-x.c b/src/login/multi-seat-x.c
  deleted file mode 100644
  index 83760d4..000
  --- a/src/login/multi-seat-x.c
  +++ /dev/null
  @@ -1,108 +0,0 @@
  -/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
  -
  -/***
  -  This file is part of systemd.
  -
  -  Copyright 2011 Lennart Poettering
  -
  -  systemd is free software; you can redistribute it and/or modify it
  -  under the terms of the GNU Lesser General Public License as published
 by
  -  the Free Software Foundation; either version 2.1 of the License, or
  -  (at your option) any later version.
  -
  -  systemd is distributed in the hope that it will be useful, but
  -  WITHOUT ANY WARRANTY; without even the implied warranty of
  -  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  -  Lesser General Public License for more details.
  -
  -  You should have received a copy of the GNU Lesser General Public
 License
  -  along with systemd; If not, see http://www.gnu.org/licenses/.
  -***/
  -
  -#include string.h
  -#include unistd.h
  -
  -#include util.h
  -#include mkdir.h
  -
  -int main(int argc, char *argv[]) {
  -
  -int i;
  -const char *seat = NULL;
  -char **new_argv;
  -_cleanup_free_ char *path = NULL;
  -int r;
  -_cleanup_fclose_ FILE *f = NULL;
  -
  -/* This binary will go away as soon as X natively takes the
  - * arguments in question as command line parameters, instead
  - * of requiring them in the configuration file. */
  -
  -/* If this file is removed, don't forget to remove the code
  - * that invokes this in gdm and other display managers. */
  -
  -for (i = 1; i  argc; i++)
  -if (streq(argv[i], -seat))
  -seat = argv[i+1];
  -
  -if (isempty(seat) || streq(seat, seat0)) {
  -argv[0] = (char*) X_SERVER;
  -execv(X_SERVER, argv);
  -log_error(Failed to execute real X server: %m);
  -goto fail;
  -}
  -
  -r =

Re: [systemd-devel] [PATCH] core: send sigabrt on watchdog timeout

On Sat, 25.10.14 23:58, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:

 if sigabrt doesn't do the job, follow regular shutdown
 routine, sigterm  sigkill.

I like it, with one exception.

 
 diff --git a/src/core/unit.c b/src/core/unit.c
 index e40e6f2..66804c9 100644
 --- a/src/core/unit.c
 +++ b/src/core/unit.c
 @@ -3305,6 +3305,7 @@ int unit_kill_context(
  Unit *u,
  KillContext *c,
  bool sigkill,
 +bool sigabrt,

Hmm, I think it would be better to replace these two bool's with a
single enum. Maybe like this:

typedef enum KillOperation = {
KILL_TERMINATE,
KILL_KILL,
KILL_ABORT,
} KillOperation;

Where KILL_TERMINATE would use c-kill_signal, while KILL_KILL would
use SIGKILL, and KILL_ABORT would use SIGABRT?

Of course, KILL_KILL is an awful name, but I guess that's Unix, we
just inherit that from the weirdly named kill(pid, SIGKILL)...

Makes sense?

Lennart

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

Re: [systemd-devel] [PATCH] login: remove multi-seat-x

On Mon, 27.10.14 16:00, Laércio de Sousa 
(laercioso...@sme-mogidascruzes.sp.gov.br) wrote:

 Lennart,
 
 I've told you some time ago that Xorg-server since release 1.16 no longer
 requires multi-seat-x wrapper.

Ah, OK! 

Hmm, can't get the patch to apply though, seems corrupted by the
mailer. Timofey, can you resend the patch please, without line-breaks?
It's OK to attach the git-format-patch formatted to an email, if your
mailer corrupts the patch when you send it inline!

Lennart

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

Re: [systemd-devel] [PATCH] bash-completion: fix systemctl isolate

On Thu, 09.10.14 12:03, Jan Synacek (jsyna...@redhat.com) wrote:

Patch looks good, but I'll leave this for Zbigniew to merge, as my own
expertise is bash completion stuff is pretty limited. 

 ---
  shell-completion/bash/systemctl.in | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/shell-completion/bash/systemctl.in 
 b/shell-completion/bash/systemctl.in
 index 0150018..e47c028 100644
 --- a/shell-completion/bash/systemctl.in
 +++ b/shell-completion/bash/systemctl.in
 @@ -67,6 +67,8 @@ __get_disabled_units () { __systemctl $1 list-unit-files  \
  | { while read -r a b c  ; do [[ $b == disabled ]]  echo  $a; 
 done; }; }
  __get_masked_units   () { __systemctl $1 list-unit-files  \
  | { while read -r a b c  ; do [[ $b == masked   ]]  echo  $a; 
 done; }; }
 +__get_all_targets() { { __systemctl $1 list-units -t target --all; } \
 +| { while read -r a b; do echo  $a; done; }; }
  
  _systemctl () {
  local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
 @@ -198,7 +200,7 @@ _systemctl () {
  
  elif __contains_word $verb ${VERBS[ISOLATABLE_UNITS]}; then
  comps=$( __filter_units_by_property $mode AllowIsolate yes \
 -  $( __get_all_units $mode ) )
 +  $( __get_all_targets $mode ) )
  compopt -o filenames
  
  elif __contains_word $verb ${VERBS[FAILED_UNITS]}; then
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 


Lennart

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

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

On Thu, 23.10.14 17:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

  order it after basic.target (which things are by default anyway)...
  
  My proposal now, (which is the same Damien's as I understood him):
  
  1. pam_systemd should sync on default.target
  2. by default default.target should just be an alias to basic.target.
  
  That way we have two things:
  
  a) as basic.target pulls in all sockets and busnames we know that
 everything that needs to be listened on is listened on by the time
 PAM succeeds
  
  b) if people really want they can change the default.target symlink to
 something else and thus add additional services into this, that may
 run after the sockets/busnames, but before PAM succeeds.
  
  Makes sense?
 Not to me. It still potentially delays user login a lot, because
 it conflates things which should be started by default with things
 which should be started before login completes.
 
 If I want to start a bunch of daemons whenever my systemd instance is
 running, I want to add them to default.target, that's what it is there
 for. I see a strong parallel with the system default.target: it
 specifies what should be launched on boot, but user logins are allowed
 much earlier.
 
 Maybe this should be made explicit and PAM should wait for a new
 user-login.target, which by default will simply have Wants=basic.target,
 but the user is free to add additional dependencies if they want to
 have more stuff running before they are allowed to log in.

I see what you mean. But user- sounds like an unnecessary prefix, if
we are already in user context, no?

Maybe just login.target?

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] On /dev/disk/by-id/ata-...-part2 missing, again


27.10.2014 22:13, Lennart Poettering wrote:

On Mon, 27.10.14 21:57, Alexander E. Patrakov (patra...@gmail.com) wrote:


27.10.2014 21:49, Lennart Poettering wrote:

On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote:


Some time ago, I have complained that some boots are unsuccessful, because
the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which
should point to /dev/sda2) is not created by udev in the initramfs (which
uses dracut). Thankfully, people on IRC have suggested some useful debugging
options:

systemd.log_level=debug rd.udev.log-priority=debug

So now I have a SOS report. It is over 1 MB, so not attached. The useful
lines are:

[3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda),
skipping event handling: Resource temporarily unavailable
[3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda),
skipping event handling: Resource temporarily unavailable

Let me complain here that these error messages still don't contain the
complete picture. How am I supposed to know which program in my
dracut-created initramfs locks /dev/sda and interferes with udev event
handling?


Most likely you are either using a too old util-linux, whose use of
BSD locks conflict's with udev's use of it. (fsck -l)

Please always check README, it will let you know precisely which
release of util-linux you need at least.


I use fsck from util-linux 2.25.1. Verified by extracting the initramfs.
According to the README, this version should be OK, so it must be something
else.


Hmm, please use lslocks or /proc/locks to figure out which process
might have the device nodes locked.


OK, after playing with /etc/ld.so.preload and shared libraries, I found 
the bad guy. It is multipathd from multipath-tools-0.5.0. I don't use 
multipath-tools on this desktop, but know why they are here (kpartx was 
needed at one time in order to debug a partition table issue with a disk 
image, but now I would probably use a partitioned loop device for the 
same task). Now they are definitely unneeded.


Removed them, but please consider putting a warning in the systemd 
README file on the incompatibility. As there are no locking-related 
commits in the multipath-tools repository since 0.5.0, this is 
definitely not a packaging bug.


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

Re: [systemd-devel] [PATCH 3/4] manager: stop start timeout when sysinit.target is reached

On Mon, Oct 27, 2014 at 06:51:08PM +0100, Lennart Poettering wrote:
 On Sat, 25.10.14 21:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
   
  +if (result == JOB_DONE  unit_has_name(u, SPECIAL_SYSINIT_TARGET))
  +manager_cancel_start_timeout(u-manager);
  +
 
 I'd really prefer to hook this up with manager_state(), so that we
 don't have to hardcode the target name more than once, and so that we
 know that the rescue/emergency mode is properly handled...
Yeah, I thought about that too, but only after I sent the patch.

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

Re: [systemd-devel] [PATCH 1/4] manager: print a warning after 2/3 of the start timeout

On Mon, Oct 27, 2014 at 06:49:22PM +0100, Lennart Poettering wrote:
  +log_info(Active jobs (%u running):\n\t%s., 
  m-n_running_jobs, all);
  +} else
  +log_info(No jobs seem to be running.);
  +
  +return 0;
  +}
 
 A long-standing TODO list item has been to print something like this
 if the user hits C-A-Del 3 times within 1s or so (under the assumption
 that he might do this if shutdown gets stuck for some reason). If we have
 this function in place, maybe that's something to quickly hookup with
 C-A-Del too? (using the ratelimit infrastruturce should make the patch
 for detecting the 3-times-within-1s thing trivial)...
I'd prefer to reserve c-a-del×3 for reboot-force now. Maybe we
could use ^C for status instead? Or even simply 's'? As long as
we haven't launched anything using the tty, we could interpret the
keystrokes.

   static int manager_watch_jobs_in_progress(Manager *m) {
   usec_t next;
   
  @@ -1015,15 +1054,39 @@ static int manager_distribute_fds(Manager *m, FDSet 
  *fds) {
   
   static int on_start_timeout(sd_event_source *s, usec_t usec, void 
  *userdata) {
   Manager *m = userdata;
  +int r;
   
   assert(s);
   assert(m);
   
  +if (!m-start_timeout_warned) {
  +log_warning(2/3 of the start timeout have passed.);
  +m-start_timeout_warned = true;
  +
  +(void) manager_log_running_jobs(m);
  +
  +r = sd_event_source_set_time(m-start_timeout_event_source,
  + now(CLOCK_MONOTONIC) +
  m-start_timeout_usec / 3);
 
 I think it would be nicer to use the original startup timestamp for
 this, instead of invoking now() here again...
 
 In fact, I think I should have used m-userspace_timestamp.monotonic
 as base for this in the first place
OK.

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

Re: [systemd-devel] [PATCH] Move apparmor code before the namespace setup

2014-10-27 Thread Michael Scherer

On Mon, Oct 27, 2014 at 03:38:37PM +0100, Lennart Poettering wrote:
 On Sat, 11.10.14 21:57, m...@zarb.org (m...@zarb.org) wrote:
 
  From: Michael Scherer m...@zarb.org
  
  Since apparmor need to access /proc to communicate with the kernel,
  any unit setting / as readonly will be unable to also use the
  AppArmorProfile setting, as found on debian bug 760526.
 
 A unit that sets /proc to read-only is broken anyway, I don't think we
 should work around that. or am I missing something here?

When a unit set / as readonly, /proc seems to become readonly too.

And I would count setting /proc as readonly ( or unreadable ) as a hardening 
measure to reduce the attack surface. 
For example :

CVE-2012-0056 local root exploit, requires to open /proc/$PARENT/mem to work 
 http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c

CVE-2011-2495 /proc/ information leak
 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2495

CVE-2011-1593 local root exploit, requires to read /proc to be exploited
 
http://xorl.wordpress.com/2011/04/25/cve-2011-1593-linux-kernel-proc-next_pidmap-invalid-memory-access/
 )

CVE-2011-1020 race condition on /proc permitting DOS
 https://access.redhat.com/security/cve/CVE-2011-1020

I also wonder how it would be broken, since /proc access is very restricted 
inside openshift due to selinux and most if not all softwares work fine here.
 
 If you apply the apparmor profile before setting up the namespace
 stuff you need to whitelist all the namespace operations in the
 apparmor profile. That might be quite a lot, hence: is this really
 desirable?

Apparmor profile is applied on next exec with aa_change_onexec, so we are
not restricted until we switch to the daemon, no need to whitelist anything.
( unless we start to use system/fork/exec in the exec_child function but I think
we want to avoid that ).

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

Re: [systemd-devel] [PATCH] login: remove multi-seat-x

2014-10-27 Thread Timofey Titovets

2014-10-27 21:05 GMT+03:00 Lennart Poettering mzerq...@0pointer.de:
 On Mon, 27.10.14 16:00, Laércio de Sousa 
 (laercioso...@sme-mogidascruzes.sp.gov.br) wrote:

 Lennart,

 I've told you some time ago that Xorg-server since release 1.16 no longer
 requires multi-seat-x wrapper.

 Ah, OK!

 Hmm, can't get the patch to apply though, seems corrupted by the
 mailer. Timofey, can you resend the patch please, without line-breaks?
 It's OK to attach the git-format-patch formatted to an email, if your
 mailer corrupts the patch when you send it inline!

 Lennart

 --
 Lennart Poettering, Red Hat

I attached it to the first message, well, this is not a problem, i
attach it again (below). =]

-- 
Have a nice day,
Timofey.
From 57b2655d2041d2bb2e9b25bef577ead9b27ce6ee Mon Sep 17 00:00:00 2001
From: Timofey Titovets nefelim...@gmail.com
Date: Sun, 26 Oct 2014 00:17:24 +0300
Subject: [PATCH] login: remove multi-seat-x

---
 Makefile.am  |  14 --
 TODO |   2 -
 configure.ac |   8 
 src/login/multi-seat-x.c | 108 ---
 4 files changed, 132 deletions(-)
 delete mode 100644 src/login/multi-seat-x.c

diff --git a/Makefile.am b/Makefile.am
index fae946a..fc86b45 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5400,20 +5400,6 @@ SYSTEM_UNIT_ALIASES += \
 BUSNAMES_TARGET_WANTS += \
 	org.freedesktop.login1.busname
 
-if ENABLE_MULTI_SEAT_X
-
-systemd_multi_seat_x_SOURCES = \
-	src/login/multi-seat-x.c
-
-systemd_multi_seat_x_LDADD = \
-	libsystemd-label.la \
-	libsystemd-shared.la
-
-rootlibexec_PROGRAMS += \
-	systemd-multi-seat-x
-
-endif
-
 dist_udevrules_DATA += \
 	src/login/70-uaccess.rules \
 	src/login/70-power-switch.rules
diff --git a/TODO b/TODO
index ed00661..195ca55 100644
--- a/TODO
+++ b/TODO
@@ -102,8 +102,6 @@ Features:
 
 * maybe introduce AssertXYZ= similar to ConditionXYZ= that causes a unit to fail (instead of skipping it) if some condition is not true...
 
-* remove multi-seat-x now
-
 * refcounting in sd-resolve is borked
 
 * exponential backoff in timesyncd and resolved when we cannot reach a server
diff --git a/configure.ac b/configure.ac
index c3b4ea3..f69eb82 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1063,14 +1063,6 @@ fi
 AM_CONDITIONAL(ENABLE_EFI, [test x$have_efi = xyes])
 
 # --
-have_multi_seat_x=no
-AC_ARG_ENABLE(multi_seat_x, AS_HELP_STRING([--disable-multi-seat-x], [do not build multi-seat-x]))
-if test x$enable_multi_seat_x != xno; then
-have_multi_seat_x=yes
-fi
-AM_CONDITIONAL(ENABLE_MULTI_SEAT_X, [test $have_multi_seat_x = yes])
-
-# --
 have_terminal=no
 AC_ARG_ENABLE(terminal, AS_HELP_STRING([--enable-terminal], [enable terminal support]))
 if test x$enable_terminal = xyes; then
diff --git a/src/login/multi-seat-x.c b/src/login/multi-seat-x.c
deleted file mode 100644
index 83760d4..000
--- a/src/login/multi-seat-x.c
+++ /dev/null
@@ -1,108 +0,0 @@
-/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
-
-/***
-  This file is part of systemd.
-
-  Copyright 2011 Lennart Poettering
-
-  systemd is free software; you can redistribute it and/or modify it
-  under the terms of the GNU Lesser General Public License as published by
-  the Free Software Foundation; either version 2.1 of the License, or
-  (at your option) any later version.
-
-  systemd is distributed in the hope that it will be useful, but
-  WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-  Lesser General Public License for more details.
-
-  You should have received a copy of the GNU Lesser General Public License
-  along with systemd; If not, see http://www.gnu.org/licenses/.
-***/
-
-#include string.h
-#include unistd.h
-
-#include util.h
-#include mkdir.h
-
-int main(int argc, char *argv[]) {
-
-int i;
-const char *seat = NULL;
-char **new_argv;
-_cleanup_free_ char *path = NULL;
-int r;
-_cleanup_fclose_ FILE *f = NULL;
-
-/* This binary will go away as soon as X natively takes the
- * arguments in question as command line parameters, instead
- * of requiring them in the configuration file. */
-
-/* If this file is removed, don't forget to remove the code
- * that invokes this in gdm and other display managers. */
-
-for (i = 1; i  argc; i++)
-if (streq(argv[i], -seat))
-seat = argv[i+1];
-
-if (isempty(seat) || streq(seat, seat0)) {
-argv[0] = (char*) X_SERVER;
-execv(X_SERVER, argv);
-log_error(Failed to execute real X server: %m);
-goto fail;
-}
-
-r = mkdir_safe_label(/run/systemd/multi-session-x, 0755, 0, 0);
-if (r  0) {
-

[systemd-devel] remote-fs ordering, iSCSI and _netdev

2014-10-27 Thread Chris Leech

Hi, I was hoping someone could help me make sure I'm not overlooking
something with trying to manage mounts on iSCSI disks.

I have an iscsi.service which starts and stops sessions to iSCSI
targets.  It's set with Before=remote-fs-pre.target and
Wants=remote-fs-pre.target to ensure that remote fs ordering is enabled.
Unfortunately mount points only get configured as remote if there is a
record in /etc/fstab at the time fstab-generator is run.

At boot fstab-generator is picking up on the _netdev option in fstab,
and the generated mount units are ordered against remote-fs properly.
If I leave a filesystem mounted at shutdown, it will be unmounted before
the iSCSI session is destroyed or the network is shut down and
everything works as expected.

But there are two cases that are problematic, adding entries to fstab at
runtime and manually mounting without adding to fstab (while still using
the _netdev option, some hint is needed).  The first case actually ends
up being the second, with the possible work-around of always remembering
to run a daemon-reload after editing fstab to run fstab-generator again.

If there's no matching mount unit from fstab-generator, one gets created
dynamically when the fs is mounted by monitoring /proc/self/mountinfo.
While the core mount unit code checks for _netdev, it's never present in
mountinfo.  Back in the days of a userspace managed mtab, the _netdev
flag was stashed there and could be looked for later, but not so any
longer.

So for any mounts to remote block devices (unlike remote file system
protocols which are detected by the fs name), unless there is an fstab
entry at the time fstab-generator is run they get treated like local fs
mounts and connectivity to the storage target may be disrupted before
unmounting (possibly resulting in file system errors).

I'm currently at a loss for how to handle this, other than to claim that
if filesystems are going to be left mounted they should be added to
fstab and a daemon-reload is required.

Thanks in advance for any ideas,

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

[systemd-devel] [PATCH] journal: avoid NULL pointer dereference in chain_cache_put

2014-10-27 Thread philippedeswert

From: Philippe De Swert philippedesw...@gmail.com

ordered_hashmap_steal_first() can return NULL (and this is usually checked
except here), so there is a potential NULL pointer reference.
Thus moving the NULL check to cover both possible allocations of the
ChainCacheItem.

Found with coverity. Fixes: CID#1249723
---
 src/journal/journal-file.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index d06dbc2..1add0c7 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -1384,10 +1384,11 @@ static void chain_cache_put(
 ci = ordered_hashmap_steal_first(h);
 else {
 ci = new(ChainCacheItem, 1);
-if (!ci)
-return;
 }
 
+if (!ci)
+   return;
+
 ci-first = first;
 
 if (ordered_hashmap_put(h, ci-first, ci)  0) {
-- 
1.8.3.2

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

Re: [systemd-devel] [PATCH 3/4] manager: stop start timeout when sysinit.target is reached

On Mon, 27.10.14 20:03, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Mon, Oct 27, 2014 at 06:51:08PM +0100, Lennart Poettering wrote:
  On Sat, 25.10.14 21:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
  wrote:
  

   +if (result == JOB_DONE  unit_has_name(u, 
   SPECIAL_SYSINIT_TARGET))
   +manager_cancel_start_timeout(u-manager);
   +
  
  I'd really prefer to hook this up with manager_state(), so that we
  don't have to hardcode the target name more than once, and so that we
  know that the rescue/emergency mode is properly handled...
 Yeah, I thought about that too, but only after I sent the patch.

I'l look into hacking this up now, I really want to get the release
out of the door 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] [PATCH 1/4] manager: print a warning after 2/3 of the start timeout

On Mon, 27.10.14 20:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Mon, Oct 27, 2014 at 06:49:22PM +0100, Lennart Poettering wrote:
   +log_info(Active jobs (%u running):\n\t%s., 
   m-n_running_jobs, all);
   +} else
   +log_info(No jobs seem to be running.);
   +
   +return 0;
   +}
  
  A long-standing TODO list item has been to print something like this
  if the user hits C-A-Del 3 times within 1s or so (under the assumption
  that he might do this if shutdown gets stuck for some reason). If we have
  this function in place, maybe that's something to quickly hookup with
  C-A-Del too? (using the ratelimit infrastruturce should make the patch
  for detecting the 3-times-within-1s thing trivial)...

 I'd prefer to reserve c-a-del×3 for reboot-force now. Maybe we
 could use ^C for status instead? Or even simply 's'? As long as
 we haven't launched anything using the tty, we could interpret the
 keystrokes.

Hmm, I kinda like the fact that the C-A-Del stuff completely bypasses
the console and is handed to us directly from the kernel. I'd thus
prefer if we could stick to it. That said, force-reboot makes a lot of
sense to attach to C-a-d too? Maybe a logic like this:

- press it once, and a clean shutdown is initiated
- press it thrice, and the current job list is displayed, plus a short
  hint that pressing it seven times will result in a forced reboot
- press it seven times and we initiate a forced reboot

(Not tied to the 7 times, could be 5, or 10, or whatever...)

Seems kinda natural to me to have this scheme where we as first
emergency step we have useful information, and then as second step we
actually just reset things.

Does this make sense?

Lennart

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

Re: [systemd-devel] [PATCH] Move apparmor code before the namespace setup

On Mon, 27.10.14 20:16, Michael Scherer (m...@zarb.org) wrote:

 On Mon, Oct 27, 2014 at 03:38:37PM +0100, Lennart Poettering wrote:
  On Sat, 11.10.14 21:57, m...@zarb.org (m...@zarb.org) wrote:
  
   From: Michael Scherer m...@zarb.org
   
   Since apparmor need to access /proc to communicate with the kernel,
   any unit setting / as readonly will be unable to also use the
   AppArmorProfile setting, as found on debian bug 760526.
  
  A unit that sets /proc to read-only is broken anyway, I don't think we
  should work around that. or am I missing something here?
 
 When a unit set / as readonly, /proc seems to become readonly too.

Yes, it ReadOnlyDirectories= is recursive. People doing that should
use ReadWriteDirectories=/proc to open up /proc again.

Note that ReadOnlyDirectories= and ReadWriteDirectories= are low-level
functionality. If you use it you really should know what you do. This
is different from ProtectSystem= which is a lot more high-level and
doesn't require you to think about all the details.

 And I would count setting /proc as readonly ( or unreadable ) as a hardening 
 measure to reduce the attack surface. 

Well, people can do whatever they want, but write access to /proc is
part of the Linux API, there's ton of functionality that processes
need access to that is only available via writes to /proc. You cannot
really take this away, except for trivial programs. systemd is really
not the place to push for read-only /proc/self/... 

The APIs in /proc are generally useful APIs, you cannot just declare
them unnecessary, take them away and assume things to still work.

Lennart

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

Re: [systemd-devel] [PATCH] journal: avoid NULL pointer dereference in chain_cache_put

On Mon, 27.10.14 23:36, philippedesw...@gmail.com (philippedesw...@gmail.com) 
wrote:

 From: Philippe De Swert philippedesw...@gmail.com
 
 ordered_hashmap_steal_first() can return NULL (and this is usually checked
 except here), so there is a potential NULL pointer reference.
 Thus moving the NULL check to cover both possible allocations of the
 ChainCacheItem.

We explicitly checked the hashmap size to be = CHAIN_CACHE_MAX first,
hence there must be something in the hashmap, hence the steal
operation cannot fail.

To make this clearer I have now added an assert() here.

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] I wonder… why systemd provokes this amount of polarity and resistance

2014-10-27 Thread Dale R. Worley

 From: Lennart Poettering lenn...@poettering.net
 
 Please, let's discuss this elsewhere. Let's keep a strict technical
 focus on this ML!

I believe that you mean that outsiders are welcome here to provide
assistance to systemd as it has already been implemented.  One
difficulty is that outsiders are usually not able to provide such
assistance.

It would be useful if there was a mailing list where outsiders could
come with problems -- systemd does not implement what I need as it is
provided by the distro.  I would expect such a mailing list to be
named systemd-users.  But no such list seems to exist.  (And thus,
they show up in systemd-devel.)

This leaves users with the sense that they are expected to use systemd
as it is provided, and it makes it hard for them to customize systems
that do what they need.  This reminds them of Microsoft products and
makes them unhappy.

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

Re: [systemd-devel] [PATCH] Move apparmor code before the namespace setup

2014-10-27 Thread Reindl Harald




Am 27.10.2014 um 23:20 schrieb Lennart Poettering:

On Mon, 27.10.14 20:16, Michael Scherer (m...@zarb.org) wrote:


On Mon, Oct 27, 2014 at 03:38:37PM +0100, Lennart Poettering wrote:

On Sat, 11.10.14 21:57, m...@zarb.org (m...@zarb.org) wrote:


From: Michael Scherer m...@zarb.org

Since apparmor need to access /proc to communicate with the kernel,
any unit setting / as readonly will be unable to also use the
AppArmorProfile setting, as found on debian bug 760526.


A unit that sets /proc to read-only is broken anyway, I don't think we
should work around that. or am I missing something here?


When a unit set / as readonly, /proc seems to become readonly too.


Yes, it ReadOnlyDirectories= is recursive. People doing that should
use ReadWriteDirectories=/proc to open up /proc again.

Note that ReadOnlyDirectories= and ReadWriteDirectories= are low-level
functionality. If you use it you really should know what you do. This
is different from ProtectSystem= which is a lot more high-level and
doesn't require you to think about all the details.


And I would count setting /proc as readonly ( or unreadable ) as a hardening
measure to reduce the attack surface.


Well, people can do whatever they want, but write access to /proc is
part of the Linux API, there's ton of functionality that processes
need access to that is only available via writes to /proc. You cannot
really take this away, except for trivial programs. systemd is really
not the place to push for read-only /proc/self/...

The APIs in /proc are generally useful APIs, you cannot just declare
them unnecessary, take them away and assume things to still work


in fact you can even set

InaccessibleDirectories=/proc
InaccessibleDirectories=/sys

and httpd, trafficserver, dovecot, postfix, spamassassin, clamd and what 
not else just works without any single issue




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

[systemd-devel] Kernel module(r8712u) reload - suspend/resume - systemd

2014-10-27 Thread poma


It is tested and works, 

# systemctl suspend

[  144.218876] PM: Entering mem sleep
[  144.219249] r8712u 2-3:1.0 wlp0s4f1u3: Suspending...
[  144.219255] r8712u 2-3:1.0 wlp0s4f1u3: Unable to suspend

 RESUME

[  146.844240] r8712u 2-3:1.0 wlp0s4f1u3: Resuming...
[  146.844241] r8712u 2-3:1.0 wlp0s4f1u3: Unable to resume
[  147.015962] PM: Finishing wakeup.
[  154.029573] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  177.489082] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  200.499708] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  233.514654] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  276.498402] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  329.498037] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  392.507363] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  455.559545] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  518.540179] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  581.533404] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1

~~

# nmcli device 
DEVICE  TYPE  STATE CONNECTION 
wlp0s4f1u3  wifi  disconnected  -- 

~

/etc/systemd/system/r8712u-reload.service
[Unit]
Description=Reload rtl871x wireless lan driver after system resume
After=hibernate.target suspend.target hybrid-sleep.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/modprobe -r r8712u
ExecStart=/usr/sbin/modprobe r8712u

[Install]
WantedBy=hibernate.target suspend.target hybrid-sleep.target



# systemctl enable r8712u-reload.service

~~~

# systemctl suspend

[  616.251430] PM: Entering mem sleep
[  616.251962] r8712u 2-3:1.0 wlp0s4f1u3: Suspending...
[  616.251965] r8712u 2-3:1.0 wlp0s4f1u3: Unable to suspend

 RESUME

[  619.008122] r8712u 2-3:1.0 wlp0s4f1u3: Resuming...
[  619.008124] r8712u 2-3:1.0 wlp0s4f1u3: Unable to resume
[  619.195001] PM: Finishing wakeup.
[  620.073126] usb 2-3: reset high-speed USB device number 3 using ehci-pci
[  620.209187] r8712u: module is from the staging directory, the quality is 
unknown, you have been warned.
[  620.209785] r8712u: Staging version
[  620.209802] r8712u: register rtl8712_netdev_ops to netdev_ops
[  620.209807] usb 2-3: r8712u: USB_SPEED_HIGH with 4 endpoints
[  620.210253] usb 2-3: r8712u: Boot from EFUSE: Autoload OK
[  620.583476] usb 2-3: r8712u: CustomerID = 0x
[  620.583489] usb 2-3: r8712u: MAC Address from efuse = 00:01:02:03:04:05
[  620.583498] usb 2-3: r8712u: Loading firmware from rtlwifi/rtl8712u.bin
[  620.584238] usbcore: registered new interface driver r8712u
[  620.589721] r8712u 2-3:1.0 wlp0s4f1u3: renamed from wlan0
[  627.183840] r8712u 2-3:1.0 wlp0s4f1u3: 1 RCR=0x153f00e
[  627.184345] r8712u 2-3:1.0 wlp0s4f1u3: 2 RCR=0x553f00e
[  627.288231] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  627.592219] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  627.896222] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  628.201217] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  648.740663] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s4f1u3: link becomes ready

~~

# nmcli device 
DEVICE  TYPE  STATE CONNECTION 
wlp0s4f1u3  wifi  connected AP 


but is there a better way to do it?


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

[systemd-devel] Writing a udev rule for U2F security tokens?

2014-10-27 Thread Andy Lutomirski

Hi-

I'd like to write a generic udev rule for U2F security tokens and to
possibly get it integrated into systemd / udev, but I'm not sure how
to write it in the first place.

U2F tokens are USB HID devices that have a usage page 0xF1D0 that
contains usage 0x01.  The rule should match any hidraw device with
that property.  Can this be done without a user helper?  Is there an
existing helper in which it would make sense to add such a check?

Here's the draft USB forum allocation:

http://www.usb.org/developers/hidpage/HUTRR48.pdf

Here's the draft spec from the FIDO Alliance:

https://fidoalliance.org/specs/fido-u2f-HID-protocol-v1.0-rd-20141008.pdf

In practice, I expect little change between the draft and final specs,
since these devices are already for sale and Chromium supports them.

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

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

On Mon, 27.10.14 18:25, Dale R. Worley (wor...@alum.mit.edu) wrote:

  From: Lennart Poettering lenn...@poettering.net
  
  Please, let's discuss this elsewhere. Let's keep a strict technical
  focus on this ML!
 
 I believe that you mean that outsiders are welcome here to provide
 assistance to systemd as it has already been implemented.  One
 difficulty is that outsiders are usually not able to provide such
 assistance.
 
 It would be useful if there was a mailing list where outsiders could
 come with problems -- systemd does not implement what I need as it is
 provided by the distro.  I would expect such a mailing list to be
 named systemd-users.  But no such list seems to exist.  (And thus,
 they show up in systemd-devel.)

Well, systemd is a suite of components that people build OSes from. As
such it isn't really an app you install on top of your OS, it's more a
toolset for distro and device builders. Now, if end users have
questions about details how they can uses these devices and distros,
then I figure they should always contact the manufacturers of these
devices, and the distro developers first.

Or in other words: we are not the final product that people should
interface with, we just provide a set of components where other people
can build final products out, and by doing so they also need to take
the responsibility for providing a first level of help for it.

Now, of course, the more technical things get, sometimes its better to
ask upstream, and we currently do not have a separate ML for questions
like that, we use systemd-devel for that, which of course is primarily
used for development. But I think it's still OK that way, as the
amount of technical user question we get is still managable, and by
not making the distinction between the group of developers and the
group of users too strict I guess our community can only win.

systemd-devel is the place for *technical* discussions only though. If
you have a technical point to make, a technical question to ask, a
patch to send, a technical suggestion to make, a technical feature
request to post, it's the right place.

However, it's not the place for UNIX philosophy discussions, about
discussions what we should be and what we shouldn't be. Now we could
open a new ML for that philosphical kind of stuff, but I have serious
doubts that many of us developers would subscribe there, hence I think
it would be better to do those discussions elsewhere, maybe on blogs,
g+ posts, on twitter, on lwn, on reddit... The discussions are being
had there anyway, and that's OK that way. Some of the systemd
developers scan and post on these forums anyway[1], regularly, hence I
really don't see the need for a new ML.

Lennart

[1] I scan and sometimes post on LWN. I think Tom does the same on g+
and lwn. Daniel on twitter, and so on...

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

Re: [systemd-devel] Kernel module(r8712u) reload - suspend/resume - systemd

On Mon, 27.10.14 23:43, poma (pomidorabelis...@gmail.com) wrote:

 but is there a better way to do it?

This appears to be a kernel driver bug. Please report this issue
against the kernel driver in question, systemd is not the right place
to work around 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] I wonder… why systemd provokes this amount of polarity and resistance

On Mon, Oct 27, 2014 at 06:25:56PM -0400, Dale R. Worley wrote:
From: Lennart Poettering lenn...@poettering.net

Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!

I believe that you mean that outsiders are welcome here to provide
assistance to systemd as it has already been implemented. One
difficulty is that outsiders are usually not able to provide such
assistance.
No really, people do feature requests here and on the bug trackers all
the time [1].

Nevertheless, systemd is a low level compenent, and not really
directed at *users* as such, more at os developers, packagers, etc.
So the distinction between development and use is not clearly
cut. Questions and bug reports often lead directly to changes in
the codebase. Creating a split into two lists would only slow
things down here.

Creating a separate systemd-users list was discussed, but who would
answers the questions there? If you expect the developers do it,
then there isn't much difference than simply answering those questions
on -devel. If you expect other people to do it, then wiki style
distribution-specific documentation is better in the long run,
since systemd is a fast moving target and the best practice often
changes over time.

What I think you're really thinking about is systemd-advocy to
discuss lofty ideals and deep motivaitions. But nobody has time for
that ;)

[1]
https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFObug_status=PLEASETESTcomponent=generalknown_name=systemd%20RFEslist_id=485720product=systemdquery_based_on=systemd%20RFEsquery_format=advancedresolution=---short_desc=^RFEshort_desc_type=regexp

It would be useful if there was a mailing list where outsiders could
come with problems -- systemd does not implement what I need as it is
provided by the distro. I would expect such a mailing list to be
named systemd-users. But no such list seems to exist. (And thus,
they show up in systemd-devel.)

This leaves users with the sense that they are expected to use systemd
as it is provided, and it makes it hard for them to customize systems
that do what they need. This reminds them of Microsoft products and
makes them unhappy.
That mostly applies to people who actually don't use systemd and are
commenting from the peanut gallery. Actual *users* when they are unhappy
are unhappy about bugs.

Zbyszek

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

Re: [systemd-devel] Writing a udev rule for U2F security tokens?

2014-10-27 Thread Greg KH

On Mon, Oct 27, 2014 at 04:12:30PM -0700, Andy Lutomirski wrote:
 Hi-
 
 I'd like to write a generic udev rule for U2F security tokens and to
 possibly get it integrated into systemd / udev, but I'm not sure how
 to write it in the first place.
 
 U2F tokens are USB HID devices that have a usage page 0xF1D0 that
 contains usage 0x01.  The rule should match any hidraw device with
 that property.  Can this be done without a user helper?  Is there an
 existing helper in which it would make sense to add such a check?
 
 Here's the draft USB forum allocation:
 
 http://www.usb.org/developers/hidpage/HUTRR48.pdf
 
 Here's the draft spec from the FIDO Alliance:
 
 https://fidoalliance.org/specs/fido-u2f-HID-protocol-v1.0-rd-20141008.pdf
 
 In practice, I expect little change between the draft and final specs,
 since these devices are already for sale and Chromium supports them.

I don't understand, what would a udev rule do with these devices?
Shouldn't they be exported automatically using the hid raw interface
so that userspace can talk to them?  What else needs to be done?

thanks,

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

Re: [systemd-devel] Writing a udev rule for U2F security tokens?

2014-10-27 Thread Andy Lutomirski

On Mon, Oct 27, 2014 at 4:32 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Mon, Oct 27, 2014 at 04:12:30PM -0700, Andy Lutomirski wrote:
 Hi-

 I'd like to write a generic udev rule for U2F security tokens and to
 possibly get it integrated into systemd / udev, but I'm not sure how
 to write it in the first place.

 U2F tokens are USB HID devices that have a usage page 0xF1D0 that
 contains usage 0x01.  The rule should match any hidraw device with
 that property.  Can this be done without a user helper?  Is there an
 existing helper in which it would make sense to add such a check?

 Here's the draft USB forum allocation:

 http://www.usb.org/developers/hidpage/HUTRR48.pdf

 Here's the draft spec from the FIDO Alliance:

 https://fidoalliance.org/specs/fido-u2f-HID-protocol-v1.0-rd-20141008.pdf

 In practice, I expect little change between the draft and final specs,
 since these devices are already for sale and Chromium supports them.

 I don't understand, what would a udev rule do with these devices?
 Shouldn't they be exported automatically using the hid raw interface
 so that userspace can talk to them?  What else needs to be done?

Wow, I clearly failed to transfer my thoughts into email...

I want to set ID_SECURITY_TOKEN=1 or, more generally, cause the
uaccess tag to be set so that users have permission to use the token.

This rule works in Fedora for the existing tokens by Yubico:

KERNEL==hidraw*, SUBSYSTEM==hidraw, ATTRS{idVendor}==1050,
ATTRS{idProduct}==0113|0114|0115|0116|0120,
ENV{ID_SECURITY_TOKEN}=1

but it won't work for other brands of U2F token.

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

Re: [systemd-devel] Kernel module(r8712u) reload - suspend/resume - systemd

2014-10-27 Thread poma

On 28.10.2014 00:15, Lennart Poettering wrote:
 On Mon, 27.10.14 23:43, poma (pomidorabelis...@gmail.com) wrote:
 
 but is there a better way to do it?
 
 This appears to be a kernel driver bug. Please report this issue
 against the kernel driver in question, systemd is not the right place
 to work around that.
 
 Lennart
 

It's not a bug, it's a feature, just as true for the systemd. :)
Given the condition of the entire Linux Wireless LAN stack this can go actually.


poma

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

Re: [systemd-devel] [PATCH] core: collapse JOB_RELOAD on an inactive unit into JOB_NOP

2014-10-27 Thread Uoti Urpala

[Resending to the list, as it seems recipients were wrong in the first attempt]

The discussion on this died down. I'm bringing this back up as it's IMO
quite a significant problem.

To recap:

The core issue is that if a start job is queued for foo.service,
systemctl reload foo.service blocks until the service is started and
then ready. This is wrong: the blocking behavior is unlikely to be
useful for any real use case, but it does cause real deadlock issues and
distros already have to work around it.


The main argument in favor of this misbehavior was that if you issue a
reload, you do it with the intent to use the service, and thus it would
be positive to ensure it is usable after such a command. I think that in
practice this is not true: neither would it be a good idea to write code
that relies on such blocking, nor are people likely to do things that
way in practice (good idea or not). As in, people shouldn't, and likely
won't, write code with semantics like the following:

systemctl start --no-block foo.service
systemctl reload foo.service # let's do the blocking here!
# here we can rely on the service being up

In sane code, if you don't want to change the operation of the service,
you should be able to skip the reload call and things shouldn't break.
Any such sane code does not benefit from the extra blocking.


The blocking is actively harmful because it can cause deadlocks. One
case where this is especially likely is during boot in hook code that
changes the configuration of some service. The hook does not know
whether other components intend to use the service afterward or not.
Thus it should generally ensure that the reload is complete before
returning, and not use no-block. But if the hook is called early in the
boot and blocks, this can prevent the later service that reload is
called on from ever actually starting.


IMO the correct way to view this issue is that configuration of service
X is guaranteed to say Y and service X is up are orthogonal states.
There are several situations where it makes sense to write code that
deals with the first state only; mixing in waits for the other state to
reach a particular value only delays things unnecessarily at best or
causes deadlocks at worst.



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

[systemd-devel] [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info

2014-10-27 Thread Timofey Titovets


Good time of day, list.
I try to fix Fixme in svg.c:
/* FIXME: this works only in the simple case */

By default function try to get root=/dev/*
I write small function to determine block device name by specified 
LABEL, UUID, PARTUUID.


Please check code, its working, but i think it can look more pretty.
May be i missed(reimplemented) some internal functional of systemd?

I also attach patch to email. Thanks.

From 896ef1c040a6395375e3adcd230bf2b766db633c Mon Sep 17 00:00:00 2001
From: Timofey Titovets nefelim...@gmail.com
Date: Tue, 28 Oct 2014 03:17:40 +0300
Subject: [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info

---
 src/bootchart/svg.c | 58 
+

 1 file changed, 54 insertions(+), 4 deletions(-)

diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index faf377e..a074b71 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -32,6 +32,7 @@
 #include sys/utsname.h
 #include sys/stat.h
 #include fcntl.h
+#include dirent.h

 #include util.h
 #include macro.h
@@ -151,6 +152,57 @@ static void svg_header(void) {
 svg(]]\n   /style\n/defs\n\n);
 }

+static void get_root_disk(const char *cmdline, char *rootbdev) {
+char *ptr = strstr(cmdline, root=);
+char path[PATH_MAX]=;
+char dev_path[PATH_MAX]=;
+DIR *d;
+struct dirent *dir;
+
+if (!ptr)
+goto out;
+
+ptr = ptr[5];
+if (ptr[0] == '/') {
+ptr = ptr[5];
+strncpy(rootbdev, ptr, 3);
+rootbdev[3] = '\0';
+return;
+}
+
+d = opendir(/dev/disk/);
+if (!d)
+goto out;
+
+if (!strncmp(LABEL, ptr, 5))
+strncpy(path, /dev/disk/by-label/, 30);
+else if (!strncmp(UUID, ptr, 4))
+strncpy(path, /dev/disk/by-uuid/, 30);
+else if (!strncmp(PARTUUID, ptr, 8))
+strncpy(path, /dev/disk/by-partuuid/, 30);
+
+ptr = strstr(ptr, =);
+ptr++;
+ptr = strtok(ptr, );
+
+d = opendir(path);
+
+while ((dir = readdir(d)) != NULL) {
+if (!strncmp(dir-d_name, ptr, 32)) {
+break;
+}
+}
+
+strcat(path, ptr);
+readlink (path, dev_path, sizeof(dev_path));
+ptr = dev_path[6];
+strncpy(rootbdev, ptr, 3);
+rootbdev[3] = '\0';
+
+out:
+closedir(d);
+}
+
 static void svg_title(const char *build) {
 char cmdline[256] = ;
 char filename[PATH_MAX];
@@ -175,11 +227,9 @@ static void svg_title(const char *build) {
 }

 /* extract root fs so we can find disk model name in sysfs */
-/* FIXME: this works only in the simple case */
-c = strstr(cmdline, root=/dev/);
+c = strstr(cmdline, root=);
 if (c) {
-strncpy(rootbdev, c[10], 3);
-rootbdev[3] = '\0';
+get_root_disk(cmdline, rootbdev);
 sprintf(filename, block/%s/device/model, rootbdev);
 fd = openat(sysfd, filename, O_RDONLY);
 f = fdopen(fd, r);
--
2.1.2

From 896ef1c040a6395375e3adcd230bf2b766db633c Mon Sep 17 00:00:00 2001
From: Timofey Titovets nefelim...@gmail.com
Date: Tue, 28 Oct 2014 03:17:40 +0300
Subject: [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info

---
 src/bootchart/svg.c | 58 +
 1 file changed, 54 insertions(+), 4 deletions(-)

diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index faf377e..a074b71 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -32,6 +32,7 @@
 #include sys/utsname.h
 #include sys/stat.h
 #include fcntl.h
+#include dirent.h
 
 #include util.h
 #include macro.h
@@ -151,6 +152,57 @@ static void svg_header(void) {
 svg(]]\n   /style\n/defs\n\n);
 }
 
+static void get_root_disk(const char *cmdline, char *rootbdev) {
+char *ptr = strstr(cmdline, root=);
+char path[PATH_MAX]=;
+char dev_path[PATH_MAX]=;
+DIR *d;
+struct dirent *dir;
+
+if (!ptr)
+goto out;
+
+ptr = ptr[5];
+if (ptr[0] == '/') {
+ptr = ptr[5];
+strncpy(rootbdev, ptr, 3);
+rootbdev[3] = '\0';
+return;
+}
+
+d = opendir(/dev/disk/);
+if (!d)
+goto out;
+
+if (!strncmp(LABEL, ptr, 5))
+strncpy(path, /dev/disk/by-label/, 30);
+else if (!strncmp(UUID, ptr, 4))
+strncpy(path, /dev/disk/by-uuid/, 30);
+else if (!strncmp(PARTUUID, ptr, 8))
+strncpy(path, /dev/disk/by-partuuid/, 30);
+
+ptr = strstr(ptr, =);
+ptr++;
+ptr = strtok(ptr, );
+
+d = opendir(path);
+
+while ((dir = readdir(d)) != NULL) {
+if

Re: [systemd-devel] [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info

2014-10-27 Thread Ivan Shapovalov

On Tuesday 28 October 2014 at 03:30:13, Timofey Titovets wrote: 
 Good time of day, list.
 I try to fix Fixme in svg.c:
 /* FIXME: this works only in the simple case */
 
 By default function try to get root=/dev/*
 I write small function to determine block device name by specified 
 LABEL, UUID, PARTUUID.
 
 Please check code, its working, but i think it can look more pretty.
 May be i missed(reimplemented) some internal functional of systemd?
 
 [...]

Hi,

there is at least function fstab_node_to_udev_node() in shared/util.c
which converts TAG=value to /dev/disk/by-tag/value,
and also function canonicalize_file_name() in glibc which resolves
symlinks and (hopefully) returns /dev/sdXY.

I'm not the one to judge, but your code seems pretty messy, esp. with
extensive use of magic constants and numbers...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] remote-fs ordering, iSCSI and _netdev

On Mon, Oct 27, 2014 at 02:10:47PM -0700, Chris Leech wrote:
 Hi, I was hoping someone could help me make sure I'm not overlooking
 something with trying to manage mounts on iSCSI disks.
 
 I have an iscsi.service which starts and stops sessions to iSCSI
 targets.  It's set with Before=remote-fs-pre.target and
 Wants=remote-fs-pre.target to ensure that remote fs ordering is enabled.
 Unfortunately mount points only get configured as remote if there is a
 record in /etc/fstab at the time fstab-generator is run.
 
 At boot fstab-generator is picking up on the _netdev option in fstab,
 and the generated mount units are ordered against remote-fs properly.
 If I leave a filesystem mounted at shutdown, it will be unmounted before
 the iSCSI session is destroyed or the network is shut down and
 everything works as expected.
 
 But there are two cases that are problematic, adding entries to fstab at
 runtime and manually mounting without adding to fstab (while still using
 the _netdev option, some hint is needed).  The first case actually ends
 up being the second, with the possible work-around of always remembering
 to run a daemon-reload after editing fstab to run fstab-generator again.
 
 If there's no matching mount unit from fstab-generator, one gets created
 dynamically when the fs is mounted by monitoring /proc/self/mountinfo.
Actually, it is more correct to say that a unit *always* get created based
on /proc/self/mountinfo. If there was a unit previously, it is replaced
by the new one, but inherits the dependencies. In effect it leads to
the behaviour you described.

 So for any mounts to remote block devices (unlike remote file system
 protocols which are detected by the fs name), unless there is an fstab
 entry at the time fstab-generator is run they get treated like local fs
 mounts and connectivity to the storage target may be disrupted before
 unmounting (possibly resulting in file system errors).
Yes, that seems right. It seems reasonable to change the code which
generates units based on /p/s/mounintinfo to behave as if _netdev option
was specified, for the known network filesystem types.

 I'm currently at a loss for how to handle this, other than to claim that
 if filesystems are going to be left mounted they should be added to
 fstab and a daemon-reload is required.
That is always an option, but I think that in this case a simple patch
will be nicer.

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

Re: [systemd-devel] [PATCH] login: remove multi-seat-x

On Mon, 27.10.14 23:10, Timofey Titovets (nefelim...@gmail.com) wrote:

 2014-10-27 21:05 GMT+03:00 Lennart Poettering mzerq...@0pointer.de:
  On Mon, 27.10.14 16:00, Laércio de Sousa 
  (laercioso...@sme-mogidascruzes.sp.gov.br) wrote:
 
  Lennart,
 
  I've told you some time ago that Xorg-server since release 1.16 no longer
  requires multi-seat-x wrapper.
 
  Ah, OK!
 
  Hmm, can't get the patch to apply though, seems corrupted by the
  mailer. Timofey, can you resend the patch please, without line-breaks?
  It's OK to attach the git-format-patch formatted to an email, if your
  mailer corrupts the patch when you send it inline!
 
  Lennart
 
  --
  Lennart Poettering, Red Hat
 
 I attached it to the first message, well, this is not a problem, i
 attach it again (below). =]

OK, worked fine this time. Applied! Thanks!

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] remote-fs ordering, iSCSI and _netdev