Re: [systemd-devel] [PATCH] cgtop: raw output option (disable conversion to human-readable units)

[Umut Tezduyar Lindskog]

Hi Charles,

We have done something similar to this with the cpu accounting. The
option is --cpu=TYPE (There is also hidden key '%' on the tty output
which toggles between different display modes). If this patch will be
taken I think we should be consistent. Maybe something like --io=TYPE
or --memory=TYPE.

Umut

On Fri, May 22, 2015 at 11:56 PM, Charles Duffy  wrote:
> From: Charles Duffy 
>
> ---
>  src/cgtop/cgtop.c | 28 ++--
>  1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
> index a390cf3..0dbac7f 100644
> --- a/src/cgtop/cgtop.c
> +++ b/src/cgtop/cgtop.c
> @@ -62,6 +62,7 @@ typedef struct Group {
>  static unsigned arg_depth = 3;
>  static unsigned arg_iterations = 0;
>  static bool arg_batch = false;
> +static bool arg_raw = false;
>  static usec_t arg_delay = 1*USEC_PER_SEC;
>
>  static enum {
> @@ -533,15 +534,24 @@ static int display(Hashmap *a) {
>  printf(" %*s", maxtcpu, format_timespan(buffer, 
> sizeof(buffer), (nsec_t) (g->cpu_usage / NSEC_PER_USEC), 0));
>
>  if (g->memory_valid)
> -printf(" %8s", format_bytes(buffer, sizeof(buffer), 
> g->memory));
> +if(arg_raw) {
> +printf(" %8ld", g->memory);
> +} else {
> +printf(" %8s", format_bytes(buffer, 
> sizeof(buffer), g->memory));
> +}
>  else
>  fputs("-", stdout);
>
>  if (g->io_valid) {
> -printf(" %8s",
> -   format_bytes(buffer, sizeof(buffer), 
> g->io_input_bps));
> -printf(" %8s",
> -   format_bytes(buffer, sizeof(buffer), 
> g->io_output_bps));
> +if(arg_raw) {
> +printf(" %8ld", g->io_input_bps);
> +printf(" %8ld", g->io_output_bps);
> +} else {
> +printf(" %8s",
> +   format_bytes(buffer, sizeof(buffer), 
> g->io_input_bps));
> +printf(" %8s",
> +   format_bytes(buffer, sizeof(buffer), 
> g->io_output_bps));
> +}
>  } else
>  fputs("--", stdout);
>
> @@ -561,6 +571,7 @@ static void help(void) {
> "  -c  Order by CPU load\n"
> "  -m  Order by memory load\n"
> "  -i  Order by IO load\n"
> +   "  -r  Provide raw (not human-readable) 
> numbers\n"
> " --cpu[=TYPE] Show CPU usage as time or percentage 
> (default)\n"
> "  -d --delay=DELAYDelay between updates\n"
> "  -n --iterations=N   Run for N iterations before exiting\n"
> @@ -583,6 +594,7 @@ static int parse_argv(int argc, char *argv[]) {
>  { "delay",  required_argument, NULL, 'd' },
>  { "iterations", required_argument, NULL, 'n' },
>  { "batch",  no_argument,   NULL, 'b' },
> +{ "raw",no_argument,   NULL, 'r' },
>  { "depth",  required_argument, NULL, ARG_DEPTH   },
>  { "cpu",optional_argument, NULL, ARG_CPU_TYPE},
>  {}
> @@ -594,7 +606,7 @@ static int parse_argv(int argc, char *argv[]) {
>  assert(argc >= 1);
>  assert(argv);
>
> -while ((c = getopt_long(argc, argv, "hptcmin:bd:", options, NULL)) 
> >= 0)
> +while ((c = getopt_long(argc, argv, "hptcmin:brd:", options, NULL)) 
> >= 0)
>
>  switch (c) {
>
> @@ -649,6 +661,10 @@ static int parse_argv(int argc, char *argv[]) {
>  arg_batch = true;
>  break;
>
> +case 'r':
> +arg_raw = true;
> +break;
> +
>  case 'p':
>  arg_order = ORDER_PATH;
>  break;
> --
> 2.0.0
>
> ___
> 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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Michael Biebl]

2015-05-27 2:51 GMT+02:00 Dave Reisner :
> The fact of the matter is, the last 2 releases of systemd have been
> brown bag releases. Neither 219 nor 220 are useable as the tarballs are
> provided. v220 doesn't even build in a large number of configurations.
> v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
> before v219 was released. For the average Arch package, this is unheard
> of, let alone being a *necessity* in order to make software useable.
>
> Please, let's figure out a way to lower the amount of work that gets
> sharded out and duplicated by downstream packagers.

Glad to know that I'm not the only one who feels this way. Let me
quote myself from #systemd:

 zbyszek: looks like we want a v221 release soon
 fwiw, I think our QA for doing releases sucks
 mbiebl_: I'm working on the selinux bug currently...
 mbiebl_: I think the releases are possibly the point of
highest instability
 a bit more official planning and giving people time to test
would be a great start
 I suggested doing a week of cooling off before a release
before, but somehow that didn't stick.
 just telling people, when the release is planned, would help
 right now, that feels really amateurish
 mbiebl_: yeah, that would help. But without a rule that only
bugfix and cosmetic or documentation changes go in, it's hard to test
stuff properly.
 absolutely, just saying that atm we don't even have that
 i.e. we know when a release is planned
 that's imo the absolute minimum
 the result is broken dist tarballs
 and distros having to ship 50+ patches until it get's usable
 that sucks bigs time

-- 
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] cgtop: raw output option (disable conversion to human-readable units)

[systemd github import bot]

Patchset imported to github.
Pull request:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] cgtop: raw output option (disable conversion to human-readable units)

[Charles Duffy]

From: Charles Duffy 

---
 src/cgtop/cgtop.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index a390cf3..0dbac7f 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -62,6 +62,7 @@ typedef struct Group {
 static unsigned arg_depth = 3;
 static unsigned arg_iterations = 0;
 static bool arg_batch = false;
+static bool arg_raw = false;
 static usec_t arg_delay = 1*USEC_PER_SEC;
 
 static enum {
@@ -533,15 +534,24 @@ static int display(Hashmap *a) {
 printf(" %*s", maxtcpu, format_timespan(buffer, 
sizeof(buffer), (nsec_t) (g->cpu_usage / NSEC_PER_USEC), 0));
 
 if (g->memory_valid)
-printf(" %8s", format_bytes(buffer, sizeof(buffer), 
g->memory));
+if(arg_raw) {
+printf(" %8ld", g->memory);
+} else {
+printf(" %8s", format_bytes(buffer, 
sizeof(buffer), g->memory));
+}
 else
 fputs("-", stdout);
 
 if (g->io_valid) {
-printf(" %8s",
-   format_bytes(buffer, sizeof(buffer), 
g->io_input_bps));
-printf(" %8s",
-   format_bytes(buffer, sizeof(buffer), 
g->io_output_bps));
+if(arg_raw) {
+printf(" %8ld", g->io_input_bps);
+printf(" %8ld", g->io_output_bps);
+} else {
+printf(" %8s",
+   format_bytes(buffer, sizeof(buffer), 
g->io_input_bps));
+printf(" %8s",
+   format_bytes(buffer, sizeof(buffer), 
g->io_output_bps));
+}
 } else
 fputs("--", stdout);
 
@@ -561,6 +571,7 @@ static void help(void) {
"  -c  Order by CPU load\n"
"  -m  Order by memory load\n"
"  -i  Order by IO load\n"
+   "  -r  Provide raw (not human-readable) 
numbers\n"
" --cpu[=TYPE] Show CPU usage as time or percentage 
(default)\n"
"  -d --delay=DELAYDelay between updates\n"
"  -n --iterations=N   Run for N iterations before exiting\n"
@@ -583,6 +594,7 @@ static int parse_argv(int argc, char *argv[]) {
 { "delay",  required_argument, NULL, 'd' },
 { "iterations", required_argument, NULL, 'n' },
 { "batch",  no_argument,   NULL, 'b' },
+{ "raw",no_argument,   NULL, 'r' },
 { "depth",  required_argument, NULL, ARG_DEPTH   },
 { "cpu",optional_argument, NULL, ARG_CPU_TYPE},
 {}
@@ -594,7 +606,7 @@ static int parse_argv(int argc, char *argv[]) {
 assert(argc >= 1);
 assert(argv);
 
-while ((c = getopt_long(argc, argv, "hptcmin:bd:", options, NULL)) >= 
0)
+while ((c = getopt_long(argc, argv, "hptcmin:brd:", options, NULL)) >= 
0)
 
 switch (c) {
 
@@ -649,6 +661,10 @@ static int parse_argv(int argc, char *argv[]) {
 arg_batch = true;
 break;
 
+case 'r':
+arg_raw = true;
+break;
+
 case 'p':
 arg_order = ORDER_PATH;
 break;
-- 
2.0.0

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

[systemd-devel] [PATCH] cgtop raw output option

[Charles Duffy]

From: Charles Duffy 

At present, systemd-cgtop converts quantities in bytes (memory and IO bandwidth
values) to human-readable form unconditionally.

Given as batch mode already exists as a supported option, there clearly is
intent for cgtop to be usable with data routed to locations other than
(directly) to human eyeballs. Given such, an option to skip this processing and
emit raw numbers (in bytes) for these values is sensible.

Charles Duffy (1):
  cgtop: raw output option (disable conversion to human-readable units)

 src/cgtop/cgtop.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

-- 
2.0.0

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

Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Dave Reisner]

On Tue, May 26, 2015 at 04:17:07PM +0200, Lennart Poettering wrote:
> On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
> wrote:
> 
> > Or will there be a v220.1 release shortly with releasy fix-ups?
> 
> Well, we don't do point releases in systemd. 
>
> In systemd git we already have now the change that makes sd-bus and
> sd-event public APIs, hence v221 is going to be more than just
> bugfixes. 

Is git revert not an option? Does someone depend on this already, making
a rollback impossible (and why would you allow that)? You say that
versions are "just a label", but a project which adopts semver would be
able to create a branch in git and produce a dot release with backported
bugfixes. Surely you're familiar with this concept -- your colleague
Karel does this routinely with util-linux.

The fact of the matter is, the last 2 releases of systemd have been
brown bag releases. Neither 219 nor 220 are useable as the tarballs are
provided. v220 doesn't even build in a large number of configurations.
v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
before v219 was released. For the average Arch package, this is unheard
of, let alone being a *necessity* in order to make software useable.

Please, let's figure out a way to lower the amount of work that gets
sharded out and duplicated by downstream packagers.

> Also, next week I'll be travelling and I doubt I will be able to
> finish a new release by then. Maybe in the middle of June we can get
> out a new release.
>
> Sorry,

I'm sorry to hear this too. Please find someone else who's paid to work
on systemd and teach them how to package releases. The current state of
affairs absolutely sucks for downstreams. Currently, packaging systemd
takes more of my time than all of my other packaging responsibilities
combined.

At LPC in New Orleans, you asked me how you could make systemd easier to
work with on the downstream side. I told you that I wanted more frequent
releases. You seemed amenable to this, but it really never happened.
I'm asking again: can we have more frequent releases? Can you take the
steps to actually make this happen and not gate releases on your own
personal availability?

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

Re: [systemd-devel] ExecStart vs ExecStartPre

[Christian Seiler]

On 05/26/2015 11:12 PM, Steven Noonan wrote:
> Hi there,
> 
> I'm wondering what the functional difference is between doing:
> 
> ExecStartPre=/bin/foo
> ExecStart=/bin/bar
> 
> and
> 
> ExecStart=/bin/foo
> ExecStart=/bin/bar
> 
> From my read of the systemd.service man page, they appear to have the
> same behavior in the common use case.

Three differences come directly to mind:

 - If you have unit of type that is NOT oneshot (simple, forking,
   etc.), you can have only a single ExecStart= line, not multiple
   ones. The main service process must be started in ExecStart=
   and not ExecStartPre=.

 - Even in Type=oneshot units you must have at least one ExecStart=
   line (but can in any case have an arbitrary amount of ExecStartPre=
   lines, even zero).

 - If you set PermissionsStartOnly= or RootDirectoryStartOnly=, then
   certain settings will be applied to ExecStart= but not to
   ExecStartPre= (see manpage for details).

(There are probably more.)

Generally speaking, I follow the following guidelines when writing
units:

 - Type=oneshot: I typically use only ExecStart= and only use
   ExecStartPre= if I have to use *StartOnly=true (see above).

 - other types: ExecStart= to start the service proper, ExecStartPre=
   for preparatory things (like generating a default config if none
   is already present or something along those lines)

But it really depends on your use case and as always YMMV.

Hope that helps!

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

[systemd-devel] ExecStart vs ExecStartPre

[Steven Noonan]

Hi there,

I'm wondering what the functional difference is between doing:

ExecStartPre=/bin/foo
ExecStart=/bin/bar

and

ExecStart=/bin/foo
ExecStart=/bin/bar

From my read of the systemd.service man page, they appear to have the
same behavior in the common use case.

The only difference I can see is that groups of ExecStartPre and
ExecStart groups can be rearranged. That is, you could have an
ExecStartPre line *after* the ExecStart line in the file, and the
ExecStartPre would still be executed first. But the ordering of
multiple ExecStart (or ExecStartPre) lines in a single systemd.service
file matters, because it has explicit ordering as written in the file.

Why would someone choose one over the other? What differences am I missing?

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

Re: [systemd-devel] how to call dbus ListUnits for user units?

[Mantas Mikulėnas]

Well, the systemd side is already there – if you have kdbus, it'll create a
user bus there, and if you have traditional dbus.service + dbus.socket,
systemd will also happily connect to that.

On Tue, May 26, 2015, 23:46 Chris Morgan  wrote:

> On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas 
> wrote:
> > On Tue, May 26, 2015 at 10:32 PM, Chris Morgan 
> wrote:
> >>
> >> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas 
> >> wrote:
> >> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan 
> >> > wrote:
> >> >>
> >> >> But I can't seem to figure out how to do the same for user units.
> >> >> There doesn't seem to be an org.freedesktop.systemd1 interface on my
> >> >> current user's session bus and I wasn't able to spot anything in the
> >> >> interfaces on the system bus that had a nested interface of
> >> >> org.freedesktop.system1.Manager...
> >> >
> >> >
> >> > The first "org.freedesktop.systemd1" here is a /service/ name; the
> usual
> >> > hierarchy is bus - service - object - interface - method, no such
> thing
> >> > as
> >> > nested interfaces.
> >> >
> >> > Anyway. The user processes are not allowed to own service names on the
> >> > system bus. And `systemd --user` is a per-user service, not a
> >> > per-session
> >> > one, so it cannot be on the session bus for various reasons: it
> doesn't
> >> > know
> >> > the bus address; it needs to outlive the session bus; the user might
> >> > sometimes have multiple sessions with their own 'session bus'
> instances.
> >> >
> >> > So the idea is that `systemd --user` would be found on the /user/ bus,
> >> > which
> >> > would someday replace the 'session' bus entirely.
> >> >
> >> > But right now, the 'user' bus does not exist by default. To create it,
> >> > you
> >> > need either
> >> > a) enable/install/boot with kdbus,
> >> > or b) obtain the "dbus.service" & "dbus.socket" user units. (They're
> in
> >> > dbus-git, or various other places like
> >> > .)
> >> >
> >> > Configured this way, the 'user' bus won't replace the session bus yet,
> >> > but
> >> > you *will* be able to connect to it and reach systemd, at address
> >> > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
> >> >
> >> > --
> >> > Mantas Mikulėnas 
> >>
> >> Hmm. I guess user services aren't used as much as system ones are?
> >>
> >> Is there another way to interface with systemctl like functionality
> >> programmatically? I have a c application that today is shelling out to
> >> systemctl to start services (which is fine for me since I'm not that
> >> concerned if it fails but it would be nice to know right at that
> >
> >
> > Note that systemctl *does* report failure as the process exit status +
> > stderr output.
> >
>
> Yep. But some services fall over after being started (bugs in our code
> etc).
>
> Does this also apply when doing 'systemctl status blah' eg. a non-zero
> exit status if the service isn't running? I'm thinking that may not be
> likely.
>
>
> >>
> >> time), but once everything is started I'd like to go through the
> >> services to make sure they all got started successfully. I didn't want
> >> to shell out to 'systemctl --user status xxx' and parse the output
> >
> >
> > Well, systemctl uses a private socket, at
> $XDG_RUNTIME_DIR/systemd/private.
> > It speaks the same DBus protocol, but using a direct peer-to-peer
> connection
> > (it's not a bus address).
> >
> > Remember that it's named "private" for a reason -- it's not part of the
> > supported API and can go away at any time (e.g. it won't exist anymore
> with
> > kdbus), so use it at your own risk.
> >
>
>
> Hmm. I guess I'll fall back to parsing the output of systemctl status
> until there is some mechanism to interact with user services.
>
> Is support for user dbus manager in the TODO or is that just something
> that is waiting on other infrastructure before being implemented? eg.
> kdbus?
>
> Chris
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to call dbus ListUnits for user units?

[Chris Morgan]

On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas  wrote:
> On Tue, May 26, 2015 at 10:32 PM, Chris Morgan  wrote:
>>
>> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas 
>> wrote:
>> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan 
>> > wrote:
>> >>
>> >> But I can't seem to figure out how to do the same for user units.
>> >> There doesn't seem to be an org.freedesktop.systemd1 interface on my
>> >> current user's session bus and I wasn't able to spot anything in the
>> >> interfaces on the system bus that had a nested interface of
>> >> org.freedesktop.system1.Manager...
>> >
>> >
>> > The first "org.freedesktop.systemd1" here is a /service/ name; the usual
>> > hierarchy is bus - service - object - interface - method, no such thing
>> > as
>> > nested interfaces.
>> >
>> > Anyway. The user processes are not allowed to own service names on the
>> > system bus. And `systemd --user` is a per-user service, not a
>> > per-session
>> > one, so it cannot be on the session bus for various reasons: it doesn't
>> > know
>> > the bus address; it needs to outlive the session bus; the user might
>> > sometimes have multiple sessions with their own 'session bus' instances.
>> >
>> > So the idea is that `systemd --user` would be found on the /user/ bus,
>> > which
>> > would someday replace the 'session' bus entirely.
>> >
>> > But right now, the 'user' bus does not exist by default. To create it,
>> > you
>> > need either
>> > a) enable/install/boot with kdbus,
>> > or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
>> > dbus-git, or various other places like
>> > .)
>> >
>> > Configured this way, the 'user' bus won't replace the session bus yet,
>> > but
>> > you *will* be able to connect to it and reach systemd, at address
>> > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
>> >
>> > --
>> > Mantas Mikulėnas 
>>
>> Hmm. I guess user services aren't used as much as system ones are?
>>
>> Is there another way to interface with systemctl like functionality
>> programmatically? I have a c application that today is shelling out to
>> systemctl to start services (which is fine for me since I'm not that
>> concerned if it fails but it would be nice to know right at that
>
>
> Note that systemctl *does* report failure as the process exit status +
> stderr output.
>

Yep. But some services fall over after being started (bugs in our code etc).

Does this also apply when doing 'systemctl status blah' eg. a non-zero
exit status if the service isn't running? I'm thinking that may not be
likely.


>>
>> time), but once everything is started I'd like to go through the
>> services to make sure they all got started successfully. I didn't want
>> to shell out to 'systemctl --user status xxx' and parse the output
>
>
> Well, systemctl uses a private socket, at $XDG_RUNTIME_DIR/systemd/private.
> It speaks the same DBus protocol, but using a direct peer-to-peer connection
> (it's not a bus address).
>
> Remember that it's named "private" for a reason -- it's not part of the
> supported API and can go away at any time (e.g. it won't exist anymore with
> kdbus), so use it at your own risk.
>


Hmm. I guess I'll fall back to parsing the output of systemctl status
until there is some mechanism to interact with user services.

Is support for user dbus manager in the TODO or is that just something
that is waiting on other infrastructure before being implemented? eg.
kdbus?

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

Re: [systemd-devel] how to call dbus ListUnits for user units?

[Mantas Mikulėnas]

On Tue, May 26, 2015 at 10:32 PM, Chris Morgan  wrote:

> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas 
> wrote:
> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan 
> wrote:
> >>
> >> But I can't seem to figure out how to do the same for user units.
> >> There doesn't seem to be an org.freedesktop.systemd1 interface on my
> >> current user's session bus and I wasn't able to spot anything in the
> >> interfaces on the system bus that had a nested interface of
> >> org.freedesktop.system1.Manager...
> >
> >
> > The first "org.freedesktop.systemd1" here is a /service/ name; the usual
> > hierarchy is bus - service - object - interface - method, no such thing
> as
> > nested interfaces.
> >
> > Anyway. The user processes are not allowed to own service names on the
> > system bus. And `systemd --user` is a per-user service, not a per-session
> > one, so it cannot be on the session bus for various reasons: it doesn't
> know
> > the bus address; it needs to outlive the session bus; the user might
> > sometimes have multiple sessions with their own 'session bus' instances.
> >
> > So the idea is that `systemd --user` would be found on the /user/ bus,
> which
> > would someday replace the 'session' bus entirely.
> >
> > But right now, the 'user' bus does not exist by default. To create it,
> you
> > need either
> > a) enable/install/boot with kdbus,
> > or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
> > dbus-git, or various other places like
> > .)
> >
> > Configured this way, the 'user' bus won't replace the session bus yet,
> but
> > you *will* be able to connect to it and reach systemd, at address
> > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
> >
> > --
> > Mantas Mikulėnas 
>
> Hmm. I guess user services aren't used as much as system ones are?
>
> Is there another way to interface with systemctl like functionality
> programmatically? I have a c application that today is shelling out to
> systemctl to start services (which is fine for me since I'm not that
> concerned if it fails but it would be nice to know right at that


Note that systemctl *does* report failure as the process exit status +
stderr output.


> time), but once everything is started I'd like to go through the
> services to make sure they all got started successfully. I didn't want
> to shell out to 'systemctl --user status xxx' and parse the output
>

Well, systemctl uses a private socket, at $XDG_RUNTIME_DIR/systemd/private.
It speaks the same DBus protocol, but using a direct peer-to-peer
connection (it's not a bus address).

Remember that it's named "private" for a reason -- it's not part of the
supported API and can go away at any time (e.g. it won't exist anymore with
kdbus), so use it at your own risk.

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

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Tue, May 26, 2015 at 9:04 PM, Christian Hesse  wrote:
> Martin Pitt  on Tue, 2015/05/26 17:11:
>> Hello Tom, all,
>>
>> with 220 I get a severe boot time regression:
>>
>>   $ systemd-analyze
>>   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s
>>
>> which used to be
>>
>>   $ systemd-analyze
>>   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s
>>
>> (this is a VM)
>>
>> It seems udevd --daemon spends 30 seconds timing out in the initramfs:
>>
>>   [0.384519] systemd-udevd[55]: starting version 220
>>   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
>> to finish
>>
>> and then some more in the real root:
>>
>>$ systemd-analyze blame
>>  10.826s dev-vda1.device
>>  10.067s systemd-tmpfiles-setup-dev.service
>>  10.031s systemd-sysctl.service
>>  10.019s systemd-journald.service
>>  10.005s sys-fs-fuse-connections.mount
>>  10.001s tmp.mount
>>
>> (full journal at http://paste.ubuntu.com/11372265/, but it's not very
>> useful)
>>
>> I bisected this to
>>
>>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
>>   udevd: move file descriptors to Manager
>>
>> this is hard to revert individually as there are lots of other recent
>> changes in udev around this commit, but any version before that commit is
>> fast and doesn't give that timeout error.
>>
>> Current trunk as of commit 185abfc3 still has that problem, so it
>> wasn't fixed by one of the recent udev commits.
>>
>> Does anyone else see this too? Any idea what causes this?
>
> I do see this as well. And probably we have an upstream bug [0] already.

Oh, and this bug report is probably unrelated. It is an old one (that
I could never reproduce), and the relevant parts were reworked
(probably causing the current issues).

-t

> Wondering whether or not my report about "inotify_add_watch() failed: Bad
> file descriptor" [1] is related. Do you see that as well?
> BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
> udev_watch.c?
>
> [0] https://bugs.freedesktop.org/show_bug.cgi?id=90051
> [1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032213.html
> --
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
> putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Tue, May 26, 2015 at 9:04 PM, Christian Hesse  wrote:
> Martin Pitt  on Tue, 2015/05/26 17:11:
>> Hello Tom, all,
>>
>> with 220 I get a severe boot time regression:
>>
>>   $ systemd-analyze
>>   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s
>>
>> which used to be
>>
>>   $ systemd-analyze
>>   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s
>>
>> (this is a VM)
>>
>> It seems udevd --daemon spends 30 seconds timing out in the initramfs:
>>
>>   [0.384519] systemd-udevd[55]: starting version 220
>>   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
>> to finish
>>
>> and then some more in the real root:
>>
>>$ systemd-analyze blame
>>  10.826s dev-vda1.device
>>  10.067s systemd-tmpfiles-setup-dev.service
>>  10.031s systemd-sysctl.service
>>  10.019s systemd-journald.service
>>  10.005s sys-fs-fuse-connections.mount
>>  10.001s tmp.mount
>>
>> (full journal at http://paste.ubuntu.com/11372265/, but it's not very
>> useful)
>>
>> I bisected this to
>>
>>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
>>   udevd: move file descriptors to Manager
>>
>> this is hard to revert individually as there are lots of other recent
>> changes in udev around this commit, but any version before that commit is
>> fast and doesn't give that timeout error.
>>
>> Current trunk as of commit 185abfc3 still has that problem, so it
>> wasn't fixed by one of the recent udev commits.
>>
>> Does anyone else see this too? Any idea what causes this?
>
> I do see this as well. And probably we have an upstream bug [0] already.
>
> Wondering whether or not my report about "inotify_add_watch() failed: Bad
> file descriptor" [1] is related. Do you see that as well?
> BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
> udev_watch.c?

This is unrelated.

Cheers,

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

Re: [systemd-devel] inotify_add_watch() failed: Bad file descriptor

[Tom Gundersen]

On Tue, May 26, 2015 at 10:14 AM, Christian Hesse  wrote:
> Hello everybody,
>
> with systemd v220 I see inotify errors from udevd. I get this once:
>
> systemd-udevd: inotify_add_watch(9, /dev/sr0, 10) failed: Bad file descriptor
>
> And a lot of these:
>
> systemd-udevd: inotify_add_watch(9, /dev/dm-[0-9]+, 10) failed: Bad file
> descriptor

This was fixed by David in 185abfc3d6b4e8f804a3f7216cd8b0459593af87.

Cheers,

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

Re: [systemd-devel] nspawn: No Return key in machinectl login?

[Tobias Hunger]

This is stty -a from outside the container:

speed 38400 baud; rows 46; columns 114; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?;
eol2 = M-^?; swtch = ; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
-ixon -ixoff -iuclc ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

This is stty -a inside the nspawn-container:

speed 38400 baud; rows 46; columns 114; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl echoke

The difference is:
eol, eol2, -icrnl -ixany -imaxbel iutf8 -iexten -echoctl

stty -F /dev/ptmx is identical inside and outside of the container --
but I am not sure whether that is what you were asking in the second
part of your reply.

I tried running "stty eol ^D -F /dev/pts/0" inside the container and
got a SIGSEGV. It works outside the container.

Best Regards,
Tobias


On Tue, May 26, 2015 at 4:11 PM, Lennart Poettering
 wrote:
> On Sat, 23.05.15 00:09, Tobias Hunger (tobias.hun...@gmail.com) wrote:
>
>> Hello,
>>
>> I am having a problem with one of my containers set up with
>> systemd-nspawn. For some reason the return key will not work most of
>> the time (19 out of 20 attemps) after doing machinectl login into that
>> machine.
>>
>> This effects not all programs: bash works, fish-shell does not. Sudo
>> password entry does not work either. Git is broken (but hardly ever
>> requires user input, so that is not that tragic;-), vi works fine.
>>
>> I only have this one one container image, even though it is built
>> based on an image that is also used by container images that work
>> fine. So I think the image should have all the important bits and
>> pieces in place.
>>
>> I am kind of lost that close to the termcap:-) Does somebody have any
>> ideas on how I can debug this?
>
> What does "stty -a" say?
>
> Consider comparing stty on the pty master (host side) as well as the
> pty itself (container size) in the cases where this works, and where
> it does not.
>
> 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 to call dbus ListUnits for user units?

[Chris Morgan]

On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas  wrote:
> On Tue, May 26, 2015 at 9:33 PM, Chris Morgan  wrote:
>>
>> But I can't seem to figure out how to do the same for user units.
>> There doesn't seem to be an org.freedesktop.systemd1 interface on my
>> current user's session bus and I wasn't able to spot anything in the
>> interfaces on the system bus that had a nested interface of
>> org.freedesktop.system1.Manager...
>
>
> The first "org.freedesktop.systemd1" here is a /service/ name; the usual
> hierarchy is bus - service - object - interface - method, no such thing as
> nested interfaces.
>
> Anyway. The user processes are not allowed to own service names on the
> system bus. And `systemd --user` is a per-user service, not a per-session
> one, so it cannot be on the session bus for various reasons: it doesn't know
> the bus address; it needs to outlive the session bus; the user might
> sometimes have multiple sessions with their own 'session bus' instances.
>
> So the idea is that `systemd --user` would be found on the /user/ bus, which
> would someday replace the 'session' bus entirely.
>
> But right now, the 'user' bus does not exist by default. To create it, you
> need either
> a) enable/install/boot with kdbus,
> or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
> dbus-git, or various other places like
> .)
>
> Configured this way, the 'user' bus won't replace the session bus yet, but
> you *will* be able to connect to it and reach systemd, at address
> "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
>
> --
> Mantas Mikulėnas 

Hmm. I guess user services aren't used as much as system ones are?

Is there another way to interface with systemctl like functionality
programmatically? I have a c application that today is shelling out to
systemctl to start services (which is fine for me since I'm not that
concerned if it fails but it would be nice to know right at that
time), but once everything is started I'd like to go through the
services to make sure they all got started successfully. I didn't want
to shell out to 'systemctl --user status xxx' and parse the output

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

Re: [systemd-devel] how to call dbus ListUnits for user units?

[Mantas Mikulėnas]

On Tue, May 26, 2015 at 9:33 PM, Chris Morgan  wrote:

> But I can't seem to figure out how to do the same for user units.
> There doesn't seem to be an org.freedesktop.systemd1 interface on my
> current user's session bus and I wasn't able to spot anything in the
> interfaces on the system bus that had a nested interface of
> org.freedesktop.system1.Manager...
>

The first "org.freedesktop.systemd1" here is a /service/ name; the usual
hierarchy is bus - service - object - interface - method, no such thing as
nested interfaces.

Anyway. The user processes are not allowed to own service names on the
system bus. And `systemd --user` is a per-user service, not a per-session
one, so it cannot be on the session bus for various reasons: it doesn't
know the bus address; it needs to outlive the session bus; the user might
sometimes have multiple sessions with their own 'session bus' instances.

So the idea is that `systemd --user` would be found on the /user/ bus,
which would someday replace the 'session' bus entirely.

But right now, the 'user' bus does not exist by default. To create it, you
need either
a) enable/install/boot with kdbus,
or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
dbus-git, or various other places like <
https://wiki.archlinux.org/index.php/Systemd/User#D-Bus>.)

Configured this way, the 'user' bus won't replace the session bus yet, but
you *will* be able to connect to it and reach systemd, at address
"kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".

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

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Christian Hesse]

Martin Pitt  on Tue, 2015/05/26 17:11:
> Hello Tom, all,
> 
> with 220 I get a severe boot time regression:
> 
>   $ systemd-analyze
>   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s
> 
> which used to be
> 
>   $ systemd-analyze
>   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s
> 
> (this is a VM)
> 
> It seems udevd --daemon spends 30 seconds timing out in the initramfs:
> 
>   [0.384519] systemd-udevd[55]: starting version 220
>   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
> to finish
> 
> and then some more in the real root:
> 
>$ systemd-analyze blame
>  10.826s dev-vda1.device
>  10.067s systemd-tmpfiles-setup-dev.service
>  10.031s systemd-sysctl.service
>  10.019s systemd-journald.service
>  10.005s sys-fs-fuse-connections.mount
>  10.001s tmp.mount
> 
> (full journal at http://paste.ubuntu.com/11372265/, but it's not very
> useful)
> 
> I bisected this to
> 
>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
>   udevd: move file descriptors to Manager
> 
> this is hard to revert individually as there are lots of other recent
> changes in udev around this commit, but any version before that commit is
> fast and doesn't give that timeout error.
> 
> Current trunk as of commit 185abfc3 still has that problem, so it
> wasn't fixed by one of the recent udev commits.
> 
> Does anyone else see this too? Any idea what causes this?

I do see this as well. And probably we have an upstream bug [0] already.

Wondering whether or not my report about "inotify_add_watch() failed: Bad
file descriptor" [1] is related. Do you see that as well?
BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
udev_watch.c?

[0] https://bugs.freedesktop.org/show_bug.cgi?id=90051
[1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032213.html
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}


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

[systemd-devel] how to call dbus ListUnits for user units?

[Chris Morgan]

Hello.

I'm able to use:

dbus-send --system --print-reply --reply-timeout=2000 --type=method_call \
--dest=org.freedesktop.systemd1 \
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.ListUnits

to list system units.

But I can't seem to figure out how to do the same for user units.
There doesn't seem to be an org.freedesktop.systemd1 interface on my
current user's session bus and I wasn't able to spot anything in the
interfaces on the system bus that had a nested interface of
org.freedesktop.system1.Manager...

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

Re: [systemd-devel] [PATCH] treewide: fix typos

[Tom Gundersen]

Applied. Thanks!

Tom

On Tue, May 26, 2015 at 7:17 PM, Torstein Husebø  wrote:
> ---
>  NEWS| 4 ++--
>  man/journal-remote.conf.xml | 2 +-
>  src/libsystemd/sd-bus/bus-control.c | 2 +-
>  src/libsystemd/sd-bus/bus-creds.c   | 6 +++---
>  src/shared/architecture.c   | 2 +-
>  src/shared/architecture.h   | 2 +-
>  src/shared/capability.h | 2 +-
>  src/shared/fdset.c  | 2 +-
>  src/shared/util.c   | 2 +-
>  9 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index f72f502129..ee533b4363 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -3997,7 +3997,7 @@ CHANGES WITH 191:
>  * HandleSleepKey= in logind.conf has been split up into
>HandleSuspendKey= and HandleHibernateKey=. The old setting
>is not available anymore. X11 and the kernel are
> -  distuingishing between these keys and we should too. This
> +  distinguishing between these keys and we should too. This
>also means the inhibition lock for these keys has been split
>into two.
>
> @@ -4743,7 +4743,7 @@ CHANGES WITH 43:
>
>  * Various functionality updates to libsystemd-login.so
>
> -* Track class of PAM logins to distuingish greeters from
> +* Track class of PAM logins to distinguish greeters from
>normal user logins.
>
>  Contributions from: Kay Sievers, Lennart Poettering, Michael
> diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
> index a7b2227182..fc60258d0b 100644
> --- a/man/journal-remote.conf.xml
> +++ b/man/journal-remote.conf.xml
> @@ -83,7 +83,7 @@
>
>  ServerKeyFile=
>
> -SSL key in PEM format
> +SSL key in PEM format.
>
>
>
> diff --git a/src/libsystemd/sd-bus/bus-control.c 
> b/src/libsystemd/sd-bus/bus-control.c
> index fa4c28174d..43ddfc651d 100644
> --- a/src/libsystemd/sd-bus/bus-control.c
> +++ b/src/libsystemd/sd-bus/bus-control.c
> @@ -429,7 +429,7 @@ static int bus_populate_creds_from_items(
>  c->mask |= SD_BUS_CREDS_PPID;
>  } else if (item->pids.pid == 1) {
>  /* The structure doesn't
> - * really distuingish the case
> + * really distinguish the case
>   * where a process has no
>   * parent and where we don't
>   * know it because it could
> diff --git a/src/libsystemd/sd-bus/bus-creds.c 
> b/src/libsystemd/sd-bus/bus-creds.c
> index fed66823c7..4d67619cf8 100644
> --- a/src/libsystemd/sd-bus/bus-creds.c
> +++ b/src/libsystemd/sd-bus/bus-creds.c
> @@ -303,7 +303,7 @@ _public_ int sd_bus_creds_get_ppid(sd_bus_creds *c, pid_t 
> *ppid) {
>  if (!(c->mask & SD_BUS_CREDS_PPID))
>  return -ENODATA;
>
> -/* PID 1 has no parent process. Let's distuingish the case of
> +/* PID 1 has no parent process. Let's distinguish the case of
>   * not knowing and not having a parent process by the returned
>   * error code. */
>  if (c->ppid == 0)
> @@ -989,7 +989,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
> pid_t pid, pid_t tid) {
>  if (missing & SD_BUS_CREDS_EXE) {
>  r = get_process_exe(pid, &c->exe);
>  if (r == -ESRCH) {
> -/* Unfortunately we cannot really distuingish
> +/* Unfortunately we cannot really distinguish
>   * the case here where the process does not
>   * exist, and /proc/$PID/exe being unreadable
>   * because $PID is a kernel thread. Hence,
> @@ -1101,7 +1101,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
> pid_t pid, pid_t tid) {
>  }
>
>  /* In case only the exe path was to be read we cannot
> - * distuingish the case where the exe path was unreadable
> + * distinguish the case where the exe path was unreadable
>   * because the process was a kernel thread, or when the
>   * process didn't exist at all. Hence, let's do a final check,
>   * to be sure. */
> diff --git a/src/shared/architecture.c b/src/shared/architecture.c
> index 884abdd3ea..8e72e7a36a 100644
> --- a/src/shared/architecture.c
> +++ b/src/shared/architecture.c
> @@ -35,7 +35,7 @@ int uname_architecture(void) {
>   * 1:1. Instead we try to clean it up and break down the
>   * confusion on x86 and arm in particular.
>   *
> - * We do not try to distuingish CPUs not CPU features, but
> + * We do not try to distinguish CPUs not CPU features, but
>   * actual architectures, i.e. that have genuinely dif

Re: [systemd-devel] pre-release warnings?

[Alexander E. Patrakov]

26.05.2015 21:52, Martin Pitt wrote:

Lennart Poettering [2015-05-26 18:36 +0200]:

That said, I think even better would be to maybe make the support for
this generic in systemctl: instead of explicitly invoking chkconfig or
update-rcd, maybe we can just make systemctl invoke some fixed binary
/usr/lib/systemd/systemd-sysv-compat or so with a fixed set of
parameters. The distros could then make that a tool (maybe just a
shell script) that invokes chkconfig or update-rc.d This would then
allow us to remove any chkconfig-specific code from systemd, and would
allow all distros to plug-in the tool of their choice without having
to patch upstream. What do you think?


That sounds great. If chkconfig and update-r.cd are/were the only two
contenders then #ifdef sounds easier, but I don't know about other
distros like e. g. Gentoo.


With my Gentoo user hat on: Gentoo needs no support here. Their 
initscripts are based on OpenRC, which is not SysV-compatible enough for 
the "fall back to the initscript" logic to make sense at all (e.g., 
their initscripts have #!/sbin/runscript in the beginning, have no LSB 
header, and produce an error message if run in the system booted by 
systemd). In fact, they explicitly disable SysV compatibility in systemd:


# disable sysv compatibility
--with-sysvinit-path=
--with-sysvrcnd-path=

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

Re: [systemd-devel] non-merged /usr changes [was: pre-release warnings?]

[Michael Biebl]

2015-05-26 19:08 GMT+02:00 Lennart Poettering :
> On Tue, 26.05.15 18:52, Martin Pitt (martin.p...@ubuntu.com) wrote:
>
>> > > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
>> >
>> > Not enthusiastic about the idea. But the XML magic is mostly
>> > Zbigniew's territory (as this long got more complex than my XML-fu can
>> > still grasp ;-)).
>>
>> Heh; I had a quick look and I'm not sure how/where to define new
>> entities. I'll have a closer look when I'm bored (so, maybe in 5 years
>> or so :-) ).
>
> Daniel is interested in picking this up.

Zbyszek was sympathetic to this idea, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717491#10

-- 
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] [PATCH] treewide: fix typos

[Torstein Husebø]

---
 NEWS| 4 ++--
 man/journal-remote.conf.xml | 2 +-
 src/libsystemd/sd-bus/bus-control.c | 2 +-
 src/libsystemd/sd-bus/bus-creds.c   | 6 +++---
 src/shared/architecture.c   | 2 +-
 src/shared/architecture.h   | 2 +-
 src/shared/capability.h | 2 +-
 src/shared/fdset.c  | 2 +-
 src/shared/util.c   | 2 +-
 9 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/NEWS b/NEWS
index f72f502129..ee533b4363 100644
--- a/NEWS
+++ b/NEWS
@@ -3997,7 +3997,7 @@ CHANGES WITH 191:
 * HandleSleepKey= in logind.conf has been split up into
   HandleSuspendKey= and HandleHibernateKey=. The old setting
   is not available anymore. X11 and the kernel are
-  distuingishing between these keys and we should too. This
+  distinguishing between these keys and we should too. This
   also means the inhibition lock for these keys has been split
   into two.
 
@@ -4743,7 +4743,7 @@ CHANGES WITH 43:
 
 * Various functionality updates to libsystemd-login.so
 
-* Track class of PAM logins to distuingish greeters from
+* Track class of PAM logins to distinguish greeters from
   normal user logins.
 
 Contributions from: Kay Sievers, Lennart Poettering, Michael
diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
index a7b2227182..fc60258d0b 100644
--- a/man/journal-remote.conf.xml
+++ b/man/journal-remote.conf.xml
@@ -83,7 +83,7 @@
   
 ServerKeyFile=
 
-SSL key in PEM format
+SSL key in PEM format.
   
 
   
diff --git a/src/libsystemd/sd-bus/bus-control.c 
b/src/libsystemd/sd-bus/bus-control.c
index fa4c28174d..43ddfc651d 100644
--- a/src/libsystemd/sd-bus/bus-control.c
+++ b/src/libsystemd/sd-bus/bus-control.c
@@ -429,7 +429,7 @@ static int bus_populate_creds_from_items(
 c->mask |= SD_BUS_CREDS_PPID;
 } else if (item->pids.pid == 1) {
 /* The structure doesn't
- * really distuingish the case
+ * really distinguish the case
  * where a process has no
  * parent and where we don't
  * know it because it could
diff --git a/src/libsystemd/sd-bus/bus-creds.c 
b/src/libsystemd/sd-bus/bus-creds.c
index fed66823c7..4d67619cf8 100644
--- a/src/libsystemd/sd-bus/bus-creds.c
+++ b/src/libsystemd/sd-bus/bus-creds.c
@@ -303,7 +303,7 @@ _public_ int sd_bus_creds_get_ppid(sd_bus_creds *c, pid_t 
*ppid) {
 if (!(c->mask & SD_BUS_CREDS_PPID))
 return -ENODATA;
 
-/* PID 1 has no parent process. Let's distuingish the case of
+/* PID 1 has no parent process. Let's distinguish the case of
  * not knowing and not having a parent process by the returned
  * error code. */
 if (c->ppid == 0)
@@ -989,7 +989,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
pid_t pid, pid_t tid) {
 if (missing & SD_BUS_CREDS_EXE) {
 r = get_process_exe(pid, &c->exe);
 if (r == -ESRCH) {
-/* Unfortunately we cannot really distuingish
+/* Unfortunately we cannot really distinguish
  * the case here where the process does not
  * exist, and /proc/$PID/exe being unreadable
  * because $PID is a kernel thread. Hence,
@@ -1101,7 +1101,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
pid_t pid, pid_t tid) {
 }
 
 /* In case only the exe path was to be read we cannot
- * distuingish the case where the exe path was unreadable
+ * distinguish the case where the exe path was unreadable
  * because the process was a kernel thread, or when the
  * process didn't exist at all. Hence, let's do a final check,
  * to be sure. */
diff --git a/src/shared/architecture.c b/src/shared/architecture.c
index 884abdd3ea..8e72e7a36a 100644
--- a/src/shared/architecture.c
+++ b/src/shared/architecture.c
@@ -35,7 +35,7 @@ int uname_architecture(void) {
  * 1:1. Instead we try to clean it up and break down the
  * confusion on x86 and arm in particular.
  *
- * We do not try to distuingish CPUs not CPU features, but
+ * We do not try to distinguish CPUs not CPU features, but
  * actual architectures, i.e. that have genuinely different
  * code. */
 
diff --git a/src/shared/architecture.h b/src/shared/architecture.h
index cb82418a5e..f5bbf65a90 100644
--- a/src/shared/architecture.h
+++ b/src/shared/architecture.h
@@ -27,7 +27,7 @@
 
 /* A cleaned up architecture definition. We don't want to g

Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Lennart Poettering]

On Tue, 26.05.15 19:13, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> Am 26.05.2015 um 18:22 schrieb Lennart Poettering:
> >On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:
> >>
> >>Am 26.05.2015 um 17:29 schrieb Lennart Poettering:
> >>>On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:
> which shows that a important project like systemd playing on the same 
> level
> as the linux kernel *just needs* point releases, there is a reason that 
> the
> kernel has point-releases and not only for the latest and greatest 
> version,
> systemd as well as the kernel are not a random webbrowser
> >>>
> >>>There's a stable git tree maintained by Zbigniew, Lukas and friends,
> >>>that carries backports for the stable releases. Most vendors should
> >>>consider following that repo I figure.
> >>>
> >>>I try to help the backporting business by tagging the commits I
> >>>personally consider backport-worthy with "git notes" and the
> >>>"Backport:" field
> >>
> >>it just works poor
> >>
> >>* https://bugzilla.redhat.com/show_bug.cgi?id=1185278
> >>   never got fixed in F20 but is fixed in Fedora 21
> >
> >Well, it's not really a bug. We require util-linux to be around. If
> >you make it unavailable then you get to to keep the pieces. It's that
> >simple
> 
> sftp-chroot worked fine until Fedora 20 and started to work again with
> Fedora 21 so please don't pretend anything else than systemd is (or was)
> responsible to fail proper shutdown and termination of the recently by
> systemd invented user-session processes

Well, we still require /usr/bin/kill from util-linux to be around. We
did not fix your "bug"... Maybe this doesn't trip up anymore, but we
didn't specifically "fix" anything...

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Reindl Harald]

Am 26.05.2015 um 18:22 schrieb Lennart Poettering:

On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 26.05.2015 um 17:29 schrieb Lennart Poettering:

On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

which shows that a important project like systemd playing on the same level
as the linux kernel *just needs* point releases, there is a reason that the
kernel has point-releases and not only for the latest and greatest version,
systemd as well as the kernel are not a random webbrowser


There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with "git notes" and the
"Backport:" field


it just works poor

* https://bugzilla.redhat.com/show_bug.cgi?id=1185278
   never got fixed in F20 but is fixed in Fedora 21


Well, it's not really a bug. We require util-linux to be around. If
you make it unavailable then you get to to keep the pieces. It's that
simple


sftp-chroot worked fine until Fedora 20 and started to work again with 
Fedora 21 so please don't pretend anything else than systemd is (or was) 
responsible to fail proper shutdown and termination of the recently by 
systemd invented user-session processes




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] non-merged /usr changes [was: pre-release warnings?]

[Lennart Poettering]

On Tue, 26.05.15 18:52, Martin Pitt (martin.p...@ubuntu.com) wrote:

> > I really don't see how the xorg.conf.d drop-in should be
> > fedora-specific. That's an upstream X11 thing, and we just picked a
> > name for the file and that's it.
> > 
> > Are you saying Debian patched out supported for /etc/X11/xorg.conf.d?
> 
> No, that of course works if it's present, but Debian wants to
> configure the keyboard layout for the console and other consumers too,
> and parsing Xorg config in kbd/console-setup would be rather weird. So
> Debian uses Xorg's udev support by default, which is essentially
> 
>   KERNEL=="event*", ENV{ID_INPUT_KEY}=="?*",
>   IMPORT{file}="/etc/default/keyboard"

udev is should not be used for configuration. That's simply
wrong. 

> > That said, I think even better would be to maybe make the support for
> > this generic in systemctl: instead of explicitly invoking chkconfig or
> > update-rcd, maybe we can just make systemctl invoke some fixed binary
> > /usr/lib/systemd/systemd-sysv-compat or so with a fixed set of
> > parameters. The distros could then make that a tool (maybe just a
> > shell script) that invokes chkconfig or update-rc.d This would then
> > allow us to remove any chkconfig-specific code from systemd, and would
> > allow all distros to plug-in the tool of their choice without having
> > to patch upstream. What do you think?
> 
> That sounds great. If chkconfig and update-r.cd are/were the only two
> contenders then #ifdef sounds easier, but I don't know about other
> distros like e. g. Gentoo.

Well, chkconfig is the only implementation we support natively right
now. A new compat interface like I proposed would only have to replace
this hookup and all would be good.

> > > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
> > 
> > Not enthusiastic about the idea. But the XML magic is mostly
> > Zbigniew's territory (as this long got more complex than my XML-fu can
> > still grasp ;-)).
> 
> Heh; I had a quick look and I'm not sure how/where to define new
> entities. I'll have a closer look when I'm bored (so, maybe in 5 years
> or so :-) ).

Daniel is interested in picking this up.

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] Reduce unit-loading time

[Lennart Poettering]

On Tue, 26.05.15 09:49, Filipe Brandenburger (filbran...@google.com) wrote:

> Hi,
> 
> On Sun, May 24, 2015 at 8:41 PM, cee1  wrote:
> > I tried ureadahead, but got following error:
> >
> > """write(2, "ureadahead: Error while tracing:"..., 59ureadahead: Error
> > while tracing: No such file or directory"""
> >
> > Needs an out-of-tree kernel patch?
> 
> Yes, ureadahead needs an out-of-tree kernel patch to add trace events
> for open(), exec() and uselib() syscalls that take file paths.
> 
> http://bugs.launchpad.net/bugs/462111
> 
> AFAICT, this never went upstream because upstream was discussing a
> generic approach of tracing any system calls, but I believe that never
> really panned out...

systemd-readahead used fanotify() which requires no kernel
patching. fanotify is completely generic and perfect for this
purpose...

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] non-merged /usr changes [was: pre-release warnings?]

[Martin Pitt]

Lennart Poettering [2015-05-26 18:36 +0200]:
> /etc/locale.conf is not a fedoraism. It has not existed on Fedora
> before we introduced it. It's a systemd'ism if you so will: we looked
> at where the distros configured these things and came to the
> conclusion that all them were weird and nothing we wanted to
> support. We hence unified this in a new file. Except apparently that
> DEbian wasn't willing to migrate :-(

Or let's say it hasn't happened yet. This is also commonly sourced by
third-party/admin scripts, so doing that migration is the kind of
"tons of work/zero visible benefit/nontrivial regression potential"
thing that nobody likes to start doing.

> I really don't see how the xorg.conf.d drop-in should be
> fedora-specific. That's an upstream X11 thing, and we just picked a
> name for the file and that's it.
> 
> Are you saying Debian patched out supported for /etc/X11/xorg.conf.d?

No, that of course works if it's present, but Debian wants to
configure the keyboard layout for the console and other consumers too,
and parsing Xorg config in kbd/console-setup would be rather weird. So
Debian uses Xorg's udev support by default, which is essentially

  KERNEL=="event*", ENV{ID_INPUT_KEY}=="?*", 
IMPORT{file}="/etc/default/keyboard"

Personally I find that rather elegant as it works for the console,
Xorg, Wayland, Mir, etc, without assuming any particular configuration
format for any of those.

> > More intrusive is the removal of chkconfig and addition of
> > update-rc.d:
> >   
> > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Make-systemctl-enable-disable-call-update-rc.d-for-s.patch?h=experimental
> >   
> > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch?h=experimental
> 
> I offered to merge a patch that adds update-rc.d support side-by-side
> with chkconfig support for this upstream, many times.

Ah, you did? I must have missed that.

> That said, I think even better would be to maybe make the support for
> this generic in systemctl: instead of explicitly invoking chkconfig or
> update-rcd, maybe we can just make systemctl invoke some fixed binary
> /usr/lib/systemd/systemd-sysv-compat or so with a fixed set of
> parameters. The distros could then make that a tool (maybe just a
> shell script) that invokes chkconfig or update-rc.d This would then
> allow us to remove any chkconfig-specific code from systemd, and would
> allow all distros to plug-in the tool of their choice without having
> to patch upstream. What do you think?

That sounds great. If chkconfig and update-r.cd are/were the only two
contenders then #ifdef sounds easier, but I don't know about other
distros like e. g. Gentoo.

> > Then we have some stupid stuff like
> > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/buildsys-Don-t-default-to-gold-as-the-linker.patch?h=experimental-220
> > which got rejected, but are nevertheless still necessary on distros
> > (and not only for us, see responses to [2])
> 
> Well, there's no need to carry a patch for that, all you need is add a
> configure cmdline param, no?

Maybe, I haven't checked. This is the kind of patch which rebases for
years without trouble :-)

> Also, this is really just working around issues with gold, and
> craziness in the suse build system. I am pretty sure bugs should be
> fixed wherever they are

Yes, agreed. TBH, I wasn't blaming you for not taking this (or the
other stuff above), just explaining what kind of "nasty real-life
s***" patches distros have to deal with as you seemed surprised about
their number. It's still better to keep upstream clean of hacks.

> > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
> 
> Not enthusiastic about the idea. But the XML magic is mostly
> Zbigniew's territory (as this long got more complex than my XML-fu can
> still grasp ;-)).

Heh; I had a quick look and I'm not sure how/where to define new
entities. I'll have a closer look when I'm bored (so, maybe in 5 years
or so :-) ).

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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

Re: [systemd-devel] Reduce unit-loading time

[Filipe Brandenburger]

Hi,

On Sun, May 24, 2015 at 8:41 PM, cee1  wrote:
> I tried ureadahead, but got following error:
>
> """write(2, "ureadahead: Error while tracing:"..., 59ureadahead: Error
> while tracing: No such file or directory"""
>
> Needs an out-of-tree kernel patch?

Yes, ureadahead needs an out-of-tree kernel patch to add trace events
for open(), exec() and uselib() syscalls that take file paths.

http://bugs.launchpad.net/bugs/462111

AFAICT, this never went upstream because upstream was discussing a
generic approach of tracing any system calls, but I believe that never
really panned out...

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

Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Martin Pitt]

Lennart Poettering [2015-05-26 18:22 +0200]:
> Well, I certainly have enough things to do. We have trouble keeping up
> with he amount of work that we already get, and I have no intention to
> make things even more complex by maintaining multiple branches for
> you, if the distros already do this anyway.

Honestly, git format-patch (or even more convenient proper packaging
tools like Debian's git-buildpackages "pq") make it a trivial
operation to get one or several upstream fixes, it's not more work
(usually less) than packaging an entire new upstream release.

Bugs that affect the tarball are a tad harder, but adding

  rm -f src/journal/audit_type-to-name.h src/udev/keyboard-keys-from-name.gperf

to the build script until we get 221 isn't rocket science either.

So I agree that maintaining more branches and upstream releases would
cause a lot of low-benefit work. I'd much rather get some distro-side
testing before we do an upstream release (see my other reply).

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] non-merged /usr changes [was: pre-release warnings?]

[Lennart Poettering]

On Tue, 26.05.15 18:06, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hey Lennart,
> 
> Lennart Poettering [2015-05-26 17:31 +0200]:
> > But note that upstream is supposed to be non-redhat centric, and is
> > supposed to support non-merged /usr. If it's really about that, I#d be
> > inetersted to know what these patches are about, and maybe we can move
> > some upstream.
> 
> There's a bunch of different config files, such as /etc/locale.conf
> and /etc/X11/xorg.conf.d/00-keyboard.conf (Fedora) vs.
> /etc/default/locale and /etc/default/keyboard (Debian) (Debian uses
> just one keyboard layout for both console and X), but these got
> removed upstream to avoid some #ifdeffery [1]. Not much to worry
> about.

/etc/locale.conf is not a fedoraism. It has not existed on Fedora
before we introduced it. It's a systemd'ism if you so will: we looked
at where the distros configured these things and came to the
conclusion that all them were weird and nothing we wanted to
support. We hence unified this in a new file. Except apparently that
DEbian wasn't willing to migrate :-(

I really don't see how the xorg.conf.d drop-in should be
fedora-specific. That's an upstream X11 thing, and we just picked a
name for the file and that's it.

Are you saying Debian patched out supported for /etc/X11/xorg.conf.d?

Or does it have that dir at a different place? if so: why? but we
could certainly make that path configurable with a configure switch...

> More intrusive is the removal of chkconfig and addition of
> update-rc.d:
>   
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Make-systemctl-enable-disable-call-update-rc.d-for-s.patch?h=experimental
>   
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch?h=experimental

I offered to merge a patch that adds update-rc.d support side-by-side
with chkconfig support for this upstream, many times.

That said, I think even better would be to maybe make the support for
this generic in systemctl: instead of explicitly invoking chkconfig or
update-rcd, maybe we can just make systemctl invoke some fixed binary
/usr/lib/systemd/systemd-sysv-compat or so with a fixed set of
parameters. The distros could then make that a tool (maybe just a
shell script) that invokes chkconfig or update-rc.d This would then
allow us to remove any chkconfig-specific code from systemd, and would
allow all distros to plug-in the tool of their choice without having
to patch upstream. What do you think?

> Then there's the (now completely separate) fsckd which you also
> already rejected:
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/fsckd-daemon-for-inter-fsckd-communication.patch?h=experimental-220
> I'd be happy to put that back and maintain it upstream, perhaps with a
> --configure option. But it rebases well as the changes to existing
> files are minimal.

If at all I think this should better be added to ply natively.

> Then we have some stupid stuff like
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/buildsys-Don-t-default-to-gold-as-the-linker.patch?h=experimental-220
> which got rejected, but are nevertheless still necessary on distros
> (and not only for us, see responses to [2])

Well, there's no need to carry a patch for that, all you need is add a
configure cmdline param, no?

Also, this is really just working around issues with gold, and
craziness in the suse build system. I am pretty sure bugs should be
fixed wherever they are, and if that's not possible, then a configure
parameter is certainly OK too.

> The single one which I'd *really* like to get rid of is this 91 kB
> patch beast:
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
> This fixes the manpages to give correct paths for non-merged /usr. I
> think the correct upstream fix would be to replace the hardcoded
> "/usr/lib/systemd/" bits with XML entities like &systemunitdir; or
> perhaps more generically &rootlibdir; (even with --enable-split-usr
> and --with-rootprefix=/ some bits still land in /usr/, like
> /usr/lib/systemd/user{,-generators} and /usr/lib/systemd/catalog/. If
> you'd accept a patch for that, I'll work on that.

Not enthusiastic about the idea. But the XML magic is mostly
Zbigniew's territory (as this long got more complex than my XML-fu can
still grasp ;-)).

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 now crashes in daemon mode

[Mantas Mikulėnas]

Thanks, finally got around to rebooting, and udev now starts properly.
However, when the cleanuphook calls "udevadm control --exit", it takes
quite a while (though the system later boots normally). With --debug
enabled, I see:

> udevd message (EXIT) received
> [10-20 seconds pass]
> timeout, giving up waiting for workers to finish

I tried running it manually from the initramfs shell, and udev had no
workers at all at that point.

This is with the latest 185abfc3d6b build.

On Sun, May 24, 2015 at 4:30 PM, Tom Gundersen  wrote:

> Hi Mantas,
>
>
>
> On Sun, May 24, 2015 at 11:40 AM, Mantas Mikulėnas 
> wrote:
> > So, udev v220 crashes in my initramfs with the following message:
> >
> >> starting version v220
> >> Assertion 'manager->pid == getpid()' failed at src/udev/udevd.c:568,
> >> function ev
> >> Aborting.
> >
> > It seems main calls manager_new() before forking, so the parent PID is
> > stored instead of child PID.
> >
> > (I'm using Arch Linux with the traditional mkinitcpio-based initramfs,
> which
> > starts udev using "systemd-udevd --daemon --resolve-names=never".)
>
> Thanks for the report. This should be fixed now in git, please let me
> know if that is not the case.
>
> Cheers,
>
> Tom
>



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

Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Lennart Poettering]

On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> Am 26.05.2015 um 17:29 schrieb Lennart Poettering:
> >On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:
> >>which shows that a important project like systemd playing on the same level
> >>as the linux kernel *just needs* point releases, there is a reason that the
> >>kernel has point-releases and not only for the latest and greatest version,
> >>systemd as well as the kernel are not a random webbrowser
> >
> >There's a stable git tree maintained by Zbigniew, Lukas and friends,
> >that carries backports for the stable releases. Most vendors should
> >consider following that repo I figure.
> >
> >I try to help the backporting business by tagging the commits I
> >personally consider backport-worthy with "git notes" and the
> >"Backport:" field
> 
> it just works poor
> 
> * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
>   never got fixed in F20 but is fixed in Fedora 21

Well, it's not really a bug. We require util-linux to be around. If
you make it unavailable then you get to to keep the pieces. It's that
simple.

> * https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for
>   months

I wasn't aware there was a reproducer for this issue now. Good to
know.

> and in general a bunch of git commits don't replace a upstream changelog of
> a minor release where as user you never have any idea what your current
> installed package really is.

Nah, this is not how this works. We simply do not provide turn-key
ready versions of systemd. systemd is not an app, it needs to be
integrated by the distributions, and they will have to adapt it to
their needs. Hence: if you want minor release information check the
RPM changelog, but don't expect that from us. We are not a product, we
are just a building block others may build a product from, and thus
need to polish it.

> with a 220.1 and a usptream download of 220.1 containing a changelog things
> are entirely different (besides that the version numbers for a project
> existing just a few years are strange to say it nicely)

Well, I certainly have enough things to do. We have trouble keeping up
with he amount of work that we already get, and I have no intention to
make things even more complex by maintaining multiple branches for
you, if the distros already do this anyway.

And again, there's already the stable tree maintained by Zbigniew and
friends. It comes with a change history "git log" and it's constantly
updated. Zbigniew doesn't tag releases in it, but if that's what you
need you can just tag it yourself and count each commit up that is
applied based on a stable branch...

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Michael Biebl]

2015-05-26 17:57 GMT+02:00 Reindl Harald :
>> There's a stable git tree maintained by Zbigniew, Lukas and friends,
>> that carries backports for the stable releases. Most vendors should
>> consider following that repo I figure.
>>
>> I try to help the backporting business by tagging the commits I
>> personally consider backport-worthy with "git notes" and the
>> "Backport:" field
>
>
> it just works poor
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
>   never got fixed in F20 but is fixed in Fedora 21
> * https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for months
>
> and in general a bunch of git commits don't replace a upstream changelog of
> a minor release where as user you never have any idea what your current
> installed package really is
>
> with a 220.1 and a usptream download of 220.1 containing a changelog things
> are entirely different (besides that the version numbers for a project
> existing just a few years are strange to say it nicely)

Maybe we(distro maintainers included) could work together with
Zbigniew and cut releases from the stable-branches?



-- 
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] udev now crashes in daemon mode

[Filipe Brandenburger]

Hi Tom,

On Sun, May 24, 2015 at 6:30 AM, Tom Gundersen  wrote:
> On Sun, May 24, 2015 at 11:40 AM, Mantas Mikulėnas  wrote:
>> So, udev v220 crashes in my initramfs with the following message:
>>
>>> starting version v220
>>> Assertion 'manager->pid == getpid()' failed at src/udev/udevd.c:568,
>>> function ev
>>> Aborting.
>>
>> It seems main calls manager_new() before forking, so the parent PID is
>> stored instead of child PID.
>>
>> (I'm using Arch Linux with the traditional mkinitcpio-based initramfs, which
>> starts udev using "systemd-udevd --daemon --resolve-names=never".)
>
> Thanks for the report. This should be fixed now in git, please let me
> know if that is not the case.

I was testing the same setup (ArchLinux with mkinitcpio), seeing the
same crash in udevd from initramfs and I can confirm that
040e689654ef08 ("udevd: event - fix event queue in daemenozied mode")
fixed it. Thanks!

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

[systemd-devel] non-merged /usr changes [was: pre-release warnings?]

[Martin Pitt]

Hey Lennart,

Lennart Poettering [2015-05-26 17:31 +0200]:
> But note that upstream is supposed to be non-redhat centric, and is
> supposed to support non-merged /usr. If it's really about that, I#d be
> inetersted to know what these patches are about, and maybe we can move
> some upstream.

There's a bunch of different config files, such as /etc/locale.conf
and /etc/X11/xorg.conf.d/00-keyboard.conf (Fedora) vs.
/etc/default/locale and /etc/default/keyboard (Debian) (Debian uses
just one keyboard layout for both console and X), but these got
removed upstream to avoid some #ifdeffery [1]. Not much to worry
about.

More intrusive is the removal of chkconfig and addition of
update-rc.d:
  
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Make-systemctl-enable-disable-call-update-rc.d-for-s.patch?h=experimental
  
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch?h=experimental

but again moving these upstream would just mean more #ifdeffery.

Then there's the (now completely separate) fsckd which you also
already rejected:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/fsckd-daemon-for-inter-fsckd-communication.patch?h=experimental-220
I'd be happy to put that back and maintain it upstream, perhaps with a
--configure option. But it rebases well as the changes to existing
files are minimal.

Then we have some stupid stuff like
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/buildsys-Don-t-default-to-gold-as-the-linker.patch?h=experimental-220
which got rejected, but are nevertheless still necessary on distros
(and not only for us, see responses to [2])

The single one which I'd *really* like to get rid of is this 91 kB
patch beast:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
This fixes the manpages to give correct paths for non-merged /usr. I
think the correct upstream fix would be to replace the hardcoded
"/usr/lib/systemd/" bits with XML entities like &systemunitdir; or
perhaps more generically &rootlibdir; (even with --enable-split-usr
and --with-rootprefix=/ some bits still land in /usr/, like
/usr/lib/systemd/user{,-generators} and /usr/lib/systemd/catalog/. If
you'd accept a patch for that, I'll work on that.

That's just a random sample; I'm happy to go through our patches [3] in
more details if you want. The manpage one is the one that causes more
work to update than all other patches together, so getting rid of that
would be quite an improvement!

Martin


[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=46a2911bf
[2] 
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028544.html
[3] 
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches?h=experimental-220
-- 
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] journal, coredump: allow relative values in some configuration options

[Lennart Poettering]

On Mon, 25.05.15 13:48, jsyna...@redhat.com (jsyna...@redhat.com) wrote:

> -static off_t arg_process_size_max = PROCESS_SIZE_MAX;
> -static off_t arg_external_size_max = EXTERNAL_SIZE_MAX;
> -static size_t arg_journal_size_max = JOURNAL_SIZE_MAX;
> -static off_t arg_keep_free = (off_t) -1;
> -static off_t arg_max_use = (off_t) -1;
> +static SizeParameter arg_process_size_max = {PROCESS_SIZE_MAX, false};
> +static SizeParameter arg_external_size_max = {EXTERNAL_SIZE_MAX, false};
> +static SizeParameter arg_journal_size_max = {JOURNAL_SIZE_MAX, false};
> +static SizeParameter arg_keep_free = {(uint64_t) -1, false};
> +static SizeParameter arg_max_use = {(uint64_t) -1, false};

So far we placed a space between { and the first word, and before }...

That said, I think it would make ton of sense to introduce a macro:

#define SIZE_PARAMETER_ABSOLUTE(x) { .value = (x), .relative = false }

And then use that everywhere.

>  
>  static int parse_config(void) {
>  static const ConfigTableItem items[] = {
> @@ -109,7 +111,7 @@ static int parse_config(void) {
>  { "Coredump", "Compress", config_parse_bool, 
>  0, &arg_compress  },
>  { "Coredump", "ProcessSizeMax",   config_parse_iec_off,  
>  0, &arg_process_size_max  },
>  { "Coredump", "ExternalSizeMax",  config_parse_iec_off,  
>  0, &arg_external_size_max },
> -{ "Coredump", "JournalSizeMax",   config_parse_iec_size, 
>  0, &arg_journal_size_max  },
> +{ "Coredump", "JournalSizeMax",   config_parse_iec_off,  
>  0, &arg_journal_size_max  },
>  { "Coredump", "KeepFree", config_parse_iec_off,  
>  0, &arg_keep_free },
>  { "Coredump", "MaxUse",   config_parse_iec_off,  
>  0, &arg_max_use   },
>  {}

I am pretty sure "config_parse_iec_off" should be renamed to
"config_parse_size_parameter" or so if it's now parsing things into that.

> @@ -122,6 +124,15 @@ static int parse_config(void) {
>   false, NULL);
>  }
>  
> +static uint64_t get_available(void) {
> +struct statvfs ss;
> +
> +if (statvfs("/var/lib/systemd/coredump", &ss) >= 0)
> +return ss.f_bsize * ss.f_bavail;
> +
> +return 0;
> +}

I'd be careful with this. Turning failure to query the disk space into
0, sounds wrong, because validly the disk space might be zero, which
cannot be distinguished then. And more importantly, if we cannot query
the disk space we should probably warn about that, and then fall back
to some constant absolute values, and not 0...

>  
> +journal_size_max =
> size_parameter_evaluate(&arg_journal_size_max, available);

I don't think that we should really do any such logic for the journal
size limit. This should stay an absolute value I am sure. In
particular since the journal does not store its data in
/var/lib/coredump, which you base your evaluation on.

>  static int journal_file_setup_data_hash_table(JournalFile *f) {
>  uint64_t s, p;
>  Object *o;
> +struct statvfs ss;
>  int r;
>  
>  assert(f);
>  
> +if (fstatvfs(f->fd, &ss) < 0)
> +return -errno;
> +
>  /* We estimate that we need 1 hash table entry per 768 of
> journal file and we want to make sure we never get beyond
> 75% fill level. Calculate the hash table size for the
> maximum file size based on these metrics. */
>  
> -s = (f->metrics.max_size * 4 / 768 / 3) * sizeof(HashItem);
> +s = (size_parameter_evaluate(&f->metrics.max_size, ss.f_bsize * 
> ss.f_bavail) * 4 / 768 / 3) * sizeof(HashItem);
>  if (s < DEFAULT_DATA_HASH_TABLE_SIZE)
>  s = DEFAULT_DATA_HASH_TABLE_SIZE;

Hmm, this doesn't look right. here we choose the hash table sizes to
use for a file, and I doubt we should base this on the currently
available disk space, since sizing the hashtable will have an effect
on the entire lifetime of the file, during which the available disk
space might change wildly.

I think it would be best not to do relative sizes for the journal file
max size at all, and continue to only support and absolute value for
that. 

> +
> +uint64_t size_parameter_evaluate(const SizeParameter *sp, uint64_t 
> available) {
> +if (sp->value == (uint64_t) -1)
> +return (uint64_t) -1;
> +
> +if (sp->relative)
> +return sp->value * 0.01 * available;

Hmm, so this implements this as percentage after all. as mentioned in
my earlier mail, I think this should be normalized to 2^32 instead, so
that 2^32 maps to 100%...

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Reindl Harald]

Am 26.05.2015 um 17:29 schrieb Lennart Poettering:

On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

which shows that a important project like systemd playing on the same level
as the linux kernel *just needs* point releases, there is a reason that the
kernel has point-releases and not only for the latest and greatest version,
systemd as well as the kernel are not a random webbrowser


There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with "git notes" and the
"Backport:" field


it just works poor

* https://bugzilla.redhat.com/show_bug.cgi?id=1185278
  never got fixed in F20 but is fixed in Fedora 21
* https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for months

and in general a bunch of git commits don't replace a upstream changelog 
of a minor release where as user you never have any idea what your 
current installed package really is


with a 220.1 and a usptream download of 220.1 containing a changelog 
things are entirely different (besides that the version numbers for a 
project existing just a few years are strange to say it nicely)




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] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Tue, May 26, 2015 at 5:11 PM, Martin Pitt  wrote:
> Hello Tom, all,
>
> with 220 I get a severe boot time regression:
>
>   $ systemd-analyze
>   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s
>
> which used to be
>
>   $ systemd-analyze
>   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s
>
> (this is a VM)
>
> It seems udevd --daemon spends 30 seconds timing out in the initramfs:
>
>   [0.384519] systemd-udevd[55]: starting version 220
>   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers to 
> finish
>
> and then some more in the real root:
>
>$ systemd-analyze blame
>  10.826s dev-vda1.device
>  10.067s systemd-tmpfiles-setup-dev.service
>  10.031s systemd-sysctl.service
>  10.019s systemd-journald.service
>  10.005s sys-fs-fuse-connections.mount
>  10.001s tmp.mount
>
> (full journal at http://paste.ubuntu.com/11372265/, but it's not very
> useful)
>
> I bisected this to
>
>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
>   udevd: move file descriptors to Manager
>
> this is hard to revert individually as there are lots of other recent changes
> in udev around this commit, but any version before that commit is fast
> and doesn't give that timeout error.
>
> Current trunk as of commit 185abfc3 still has that problem, so it
> wasn't fixed by one of the recent udev commits.
>
> Does anyone else see this too? Any idea what causes this?

FWIW, I'm looking into this.

Cheers,

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

Re: [systemd-devel] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

[Lennart Poettering]

BOn Tue, 26.05.15 16:58, Martin Pitt (martin.p...@ubuntu.com) wrote:

> > 50 non-backport patches? That sounds like a lot...
> 
> It's not that bad, most of them are trivial, like tweaking tmpfiles.d
> or some extra historic udev rules. We have quite a bunch of patches to
> get rid of Fedora/RedHat-isms and replace them with Debianisms, and
> then there's a lot for having a non-merged /usr (which Debian didn't
> do yet). Aside from two or three which keep breaking most of them just
> tag along, but there's always enough noise to break completely
> automatically building packages from git master. Anyway, this is
> completely tangential.. :-)

But note that upstream is supposed to be non-redhat centric, and is
supposed to support non-merged /usr. If it's really about that, I#d be
inetersted to know what these patches are about, and maybe we can move
some 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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Lennart Poettering]

On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> Am 26.05.2015 um 16:17 schrieb Lennart Poettering:
> >On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
> >wrote:
> >
> >>Or will there be a v220.1 release shortly with releasy fix-ups?
> >
> >Well, we don't do point releases in systemd.
> 
> and why?
> 
> just "because don't do" is not enough

it's just a label after all and I like my bikesheds green without
points.

> >In systemd git we already have now the change that makes sd-bus and
> >sd-event public APIs, hence v221 is going to be more than just
> >bugfixes.
> 
> that don't fix 220
> 
> >Also, next week I'll be travelling and I doubt I will be able to
> >finish a new release by then. Maybe in the middle of June we can get
> >out a new release
> 
> which shows that a important project like systemd playing on the same level
> as the linux kernel *just needs* point releases, there is a reason that the
> kernel has point-releases and not only for the latest and greatest version,
> systemd as well as the kernel are not a random webbrowser

There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with "git notes" and the
"Backport:" field.

Lennart

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

[systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Martin Pitt]

Hello Tom, all,

with 220 I get a severe boot time regression:

  $ systemd-analyze
  Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

which used to be

  $ systemd-analyze
  Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

(this is a VM)

It seems udevd --daemon spends 30 seconds timing out in the initramfs:

  [0.384519] systemd-udevd[55]: starting version 220
  [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers to 
finish

and then some more in the real root:

   $ systemd-analyze blame
 10.826s dev-vda1.device
 10.067s systemd-tmpfiles-setup-dev.service
 10.031s systemd-sysctl.service
 10.019s systemd-journald.service
 10.005s sys-fs-fuse-connections.mount
 10.001s tmp.mount

(full journal at http://paste.ubuntu.com/11372265/, but it's not very
useful)

I bisected this to

  http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
  udevd: move file descriptors to Manager

this is hard to revert individually as there are lots of other recent changes
in udev around this commit, but any version before that commit is fast
and doesn't give that timeout error.

Current trunk as of commit 185abfc3 still has that problem, so it
wasn't fixed by one of the recent udev commits.

Does anyone else see this too? Any idea what causes this?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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

Re: [systemd-devel] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

[Martin Pitt]

Lennart Poettering [2015-05-26 16:43 +0200]:
> Well, I had been trying to stabilize things since 3 weeks before the
> release

Ah, that's roughly when I did my last "build packages from upstream
trunk" test, and indeed it looked fairly well back then.

> I didn't announce this on the ML though, but I figure I could do
> that too, for the next cycle...

That would be nice. Let's give it a try and see how it goes? From your
end it's just an extra mail when you are ready to release (and maybe
giving packagers two days or so), and from our end it's just moving
all the heavy-lifting around a bit.

> 50 non-backport patches? That sounds like a lot...

It's not that bad, most of them are trivial, like tweaking tmpfiles.d
or some extra historic udev rules. We have quite a bunch of patches to
get rid of Fedora/RedHat-isms and replace them with Debianisms, and
then there's a lot for having a non-merged /usr (which Debian didn't
do yet). Aside from two or three which keep breaking most of them just
tag along, but there's always enough noise to break completely
automatically building packages from git master. Anyway, this is
completely tangential.. :-)

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] How to wait for specific interface/IP?

[Alexander E. Patrakov]

26.05.2015 19:03, Lennart Poettering wrote:

On Sat, 23.05.15 11:03, Ian Pilcher (arequip...@gmail.com) wrote:


Is there a simple way to make a service require that a specific network
interface/IP address be active?

I have a manually set up bridge and dnsmasq configuration for my VM
traffic, but dnsmasq is getting started before NetworkManager has
configured the bridge and failing because it cannot bind to the bridge's
IP address.


Well, for networkd, there's the systemd-networkd-wait-online tool that
allows you to wait until a specific interface is up. Maybe NM supports
something similar? Please ask NM folks for help.

Also, dnsmasq should probably use IP_FREEBIND or so (at least
optionally) so that it can work without requiring the interface to be
up.


dnsmasq supports "--bind-dynamic" option, which is based not on 
IP_FREEBIND, but on notifications about new or disappearing interfaces 
and addresses.


The real problem here is with non-C languages. E.g. node.js, Java, 
Python 2.7 and even Go still have absolutely no support for IP_FREEBIND.


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

Re: [systemd-devel] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

[Lennart Poettering]

On Tue, 26.05.15 16:26, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello all,
> 
> Dimitri John Ledkov [2015-05-26 15:12 +0100]:
> > Or will there be a v220.1 release shortly with releasy fix-ups?
> 
> Can we perhaps flip that around? I did a make dist/port our
> patches/build packackages/run our tests round on May 11, but that was
> before most of the recent "hiccups" landed in master. I'd rather love
> to do that once I know that a release is around the corner, but as we
> don't currently have "release is imminent" warnings none of the
> packagers can do this as a pre-release exercise.
> 
> So Lennart: WDYT about announcing your intent to do a stable release
> on the ML, and then us packagers can do a "make dist", test an actual
> tarball, and thus find all these little tarball errors, udev
> regressions and what not before the official release is cut?

Well, I had been trying to stabilize things since 3 weeks before the
release, I did mention it on IRC back then. I didn't announce this on
the ML though, but I figure I could do that too, for the next cycle...

I tend to ping some people before the release, who I know have
independent test suites or care for last-minute fixes... 

> At least for me, the biggest part of updating to a new release is to
> rebase our ~ 50 patches; doing that against a near-release tarball
> will be the same amount of work; running automatic tests is negligible
> human effort, and running manual tests doesn't take that long for me
> (that's the point which might vastly differ for other packagers -- but
> then again, testing pre-release tarballs means that not much will
> change any more until the real release, so the second time testing
> will be faster).

50 non-backport patches? That sounds like a lot...

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Reindl Harald]

Am 26.05.2015 um 16:17 schrieb Lennart Poettering:

On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:


Or will there be a v220.1 release shortly with releasy fix-ups?


Well, we don't do point releases in systemd.


and why?

just "because don't do" is not enough


In systemd git we already have now the change that makes sd-bus and
sd-event public APIs, hence v221 is going to be more than just
bugfixes.


that don't fix 220


Also, next week I'll be travelling and I doubt I will be able to
finish a new release by then. Maybe in the middle of June we can get
out a new release


which shows that a important project like systemd playing on the same 
level as the linux kernel *just needs* point releases, there is a reason 
that the kernel has point-releases and not only for the latest and 
greatest version, systemd as well as the kernel are not a random webbrowser




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] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

[Martin Pitt]

Hello all,

Dimitri John Ledkov [2015-05-26 15:12 +0100]:
> Or will there be a v220.1 release shortly with releasy fix-ups?

Can we perhaps flip that around? I did a make dist/port our
patches/build packackages/run our tests round on May 11, but that was
before most of the recent "hiccups" landed in master. I'd rather love
to do that once I know that a release is around the corner, but as we
don't currently have "release is imminent" warnings none of the
packagers can do this as a pre-release exercise.

So Lennart: WDYT about announcing your intent to do a stable release
on the ML, and then us packagers can do a "make dist", test an actual
tarball, and thus find all these little tarball errors, udev
regressions and what not before the official release is cut?

At least for me, the biggest part of updating to a new release is to
rebase our ~ 50 patches; doing that against a near-release tarball
will be the same amount of work; running automatic tests is negligible
human effort, and running manual tests doesn't take that long for me
(that's the point which might vastly differ for other packagers -- but
then again, testing pre-release tarballs means that not much will
change any more until the real release, so the second time testing
will be faster).

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Lennart Poettering]

On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

> Or will there be a v220.1 release shortly with releasy fix-ups?

Well, we don't do point releases in systemd. 

In systemd git we already have now the change that makes sd-bus and
sd-event public APIs, hence v221 is going to be more than just
bugfixes. 

Also, next week I'll be travelling and I doubt I will be able to
finish a new release by then. Maybe in the middle of June we can get
out a new release.

Sorry,

Lennart

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

Re: [systemd-devel] Vendor default masked service

[Lennart Poettering]

On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> Hi,
> 
> I was wondering if we have a way to provide vendor default masked
> service?

Well, so far our thinking was that if the vendor wants to make a unit
completely unavailable he should simply not ship it in the first
place.

What's the usecase for a vendor masking a unit, but installing it? Why
not remove it in the first place entirely?

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Dimitri John Ledkov]

On 26 May 2015 at 15:10, Martin Pitt  wrote:
> Lennart Poettering [2015-05-26 16:06 +0200]:
>> I think this has been fixed now with Tom's commit
>> ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.
>
> Confirmed this morning. Sorry, I should have followed up to the ML
> immediately. Thanks Tom!

Can stable-v220 branch be started with these please?

Or will there be a v220.1 release shortly with releasy fix-ups?
-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] nspawn: No Return key in machinectl login?

[Lennart Poettering]

On Sat, 23.05.15 00:09, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> Hello,
> 
> I am having a problem with one of my containers set up with
> systemd-nspawn. For some reason the return key will not work most of
> the time (19 out of 20 attemps) after doing machinectl login into that
> machine.
> 
> This effects not all programs: bash works, fish-shell does not. Sudo
> password entry does not work either. Git is broken (but hardly ever
> requires user input, so that is not that tragic;-), vi works fine.
> 
> I only have this one one container image, even though it is built
> based on an image that is also used by container images that work
> fine. So I think the image should have all the important bits and
> pieces in place.
> 
> I am kind of lost that close to the termcap:-) Does somebody have any
> ideas on how I can debug this?

What does "stty -a" say?

Consider comparing stty on the pty master (host side) as well as the
pty itself (container size) in the cases where this works, and where
it does not.

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Martin Pitt]

Lennart Poettering [2015-05-26 16:06 +0200]:
> I think this has been fixed now with Tom's commit
> ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

Confirmed this morning. Sorry, I should have followed up to the ML
immediately. Thanks Tom!

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] 220: --disable-audit broken?

[Lennart Poettering]

On Fri, 22.05.15 11:27, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote:

> Hi,
> 
> On 22 May 2015 at 11:16,   wrote:
> > hello,
> >
> > while building 220 I get:
> >
> > In file included from src/journal/audit-type.c:32:0:
> > src/journal/audit_type-to-name.h: In function 'audit_type_to_string':
> > src/journal/audit_type-to-name.h:23:14: error: 'AUDIT_USER_AUTH' 
> > undeclared (first use in this function)
> >  case AUDIT_USER_AUTH: return "USER_AUTH";
> >   ^
> 
> I got the same here
> 
> rm src/journal/audit_type-to-name.h src/udev/keyboard-keys-from-name.gperf
> 
> Solved this one and another udev-related. These generated files are in
> the tarball when they shouldn't.

I think this is now solved with Tom's commit
ee3c31bf69746c5afc764c3d0337feec1bf25f0e of your patch.

> Btw src/boot/efi is missing from the tarball, too.

I think this is now solved with Tom's commit
f80099c06fd12c87da4d2207fb2e2f31ffaec6ed of your patch.

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Lennart Poettering]

On Fri, 22.05.15 17:28, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello,
> 
> while packaging 220, I got the audit related build failure that was
> already reported [1], but also another one:

I think this has been fixed now with Tom's commit
ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

Please verify.

Lennart

> 
> | In file included from ../src/udev/udev-builtin-keyboard.c:29:0:
> | ./src/udev/keyboard-keys-from-name.h: In function 'keyboard_lookup_key':
> | ./src/udev/keyboard-keys-from-name.h:253:21: error: 'KEY_NUMERIC_A' 
> undeclared (first use in this function)
> |{"numeric_a", KEY_NUMERIC_A},
> |  ^
> | ./src/udev/keyboard-keys-from-name.h:253:21: note: each undeclared 
> identifier is reported only once for each function it appears in
> | ./src/udev/keyboard-keys-from-name.h:275:21: error: 'KEY_NUMERIC_C' 
> undeclared (first use in this function)
> |{"numeric_c", KEY_NUMERIC_C},
> |  ^
> | ./src/udev/keyboard-keys-from-name.h:347:21: error: 'KEY_NUMERIC_D' 
> undeclared (first use in this function)
> |{"numeric_d", KEY_NUMERIC_D},
> |  ^
> | ./src/udev/keyboard-keys-from-name.h:420:21: error: 'KEY_NUMERIC_B' 
> undeclared (first use in this function)
> |{"numeric_b", KEY_NUMERIC_B},
> |  ^
> | ./src/udev/keyboard-keys-from-name.h:464:26: error: 'KEY_ROTATE_DISPLAY' 
> undeclared (first use in this function)
> |{"rotate_display", KEY_ROTATE_DISPLAY},
> 
> This is because unlike 219 and earlier, the 220 tarball ships a
> pregenerated src/udev/keyboard-keys-from-name.gperf. In Debian sid,
> the above constants are not defined (in the kernel headers, I
> presume). I think src/udev/keyboard-keys-from-name.gperf is supposed
> to be built during package build? I see that somewhere between 219 and
> 220 this happened in Makefile.am:
> 
> -CLEANFILES += \
> -   src/udev/keyboard-keys-from-name.gperf \
> -   src/udev/keyboard-keys.txt \
> -   src/udev/net/link-config-gperf.c
> 
> but apparently this wasn't put back someplace else?
> 
> Thanks,
> 
> Martin
> 
> [1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032148.html
> -- 
> 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


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-nspawn: cannot join existing macvlan

[Lennart Poettering]

On Mon, 25.05.15 16:26, Kai Krakow (hurikha...@gmail.com) wrote:

> Lennart Poettering  schrieb:
> 
> > On Fri, 08.05.15 20:53, Kai Krakow (hurikha...@gmail.com) wrote:
> > 
> >> > # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0
> >> > # --
> >> > bind=/usr/portage --bind-ro=/usr/src --machine=test
> >> > Spawning container test on /var/lib/machines/test.
> >> > Press ^] three times within 1s to kill container.
> >> > Failed to add new macvlan interfaces: File exists
> >> > 
> >> > I still don't think that systemd-nspawn should insist on creating the
> >> > host- side macvlan bridge and fail, if it cannot. It should just accept
> >> > that it is already there.
> >> 
> >> My findings show that it actually does accept this case. But I had to
> >> explicitly order the machines after network.target to successfully start
> >> at boot time.
> > 
> > I changed git now to order nspawn units by default after
> > network.target now. In the long run we should replace this by calling
> > into networkd though, without waiting for "all" networking, for
> > whatever that means...
> 
> Well, now, with v220, we are back to the original problem:
> 
> machines # systemd-nspawn --boot --link-journal=try-guest --machine=test --
> network-macvlan=enp5s0
> Spawning container test on /var/lib/machines/test.
> Press ^] three times within 1s to kill container.
> Failed to add new macvlan interfaces: File exists
> 
> If mv-enp5s0 is already there (maybe by means of another machine), it no 
> longer starts any other machine on the same macvlan. I don't think this is 
> how it should work.

Well, there can only be one machine with the same name, and we use
that name in the macvlan interface name. Please assign different names
to your containers so that they will also get differently named
macvlan names, and all should be good.

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 to wait for specific interface/IP?

[Lennart Poettering]

On Sat, 23.05.15 11:03, Ian Pilcher (arequip...@gmail.com) wrote:

> Is there a simple way to make a service require that a specific network
> interface/IP address be active?
> 
> I have a manually set up bridge and dnsmasq configuration for my VM
> traffic, but dnsmasq is getting started before NetworkManager has
> configured the bridge and failing because it cannot bind to the bridge's
> IP address.

Well, for networkd, there's the systemd-networkd-wait-online tool that
allows you to wait until a specific interface is up. Maybe NM supports
something similar? Please ask NM folks for help.

Also, dnsmasq should probably use IP_FREEBIND or so (at least
optionally) so that it can work without requiring the interface to be
up.

Either way, this is something to contact the NM and dnsmasq people
about.

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] 220 regression: path_is_mount_point() for non-directories

[Lennart Poettering]

On Mon, 25.05.15 21:06, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello all,
> 
> in 220, path_is_mount_point() now always fails with "-20 ENOTDIR" when
> calling it on files. This is problematic as it's perfectly valid to
> have bind-mounted files; in fact, systemd's machine_id_setup() itself
> creates a /run/machine-id → /etc/machine-id bind mount if /etc is
> read-only at that time (and systemd-machine-id-commit will write it
> once root fs becomes writable).
> 
> This was first introduced here:
> 
>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=27cc6f166
>   path-util: fix path_is_mount_point() for symlinks
> 
> which added O_DIRECTORY, so that openat() fails with the above error.
> It also replaced path_get_parent() (which works fine for files) with
> name_to_handle_at(fd, "..", ...) which only works for directories.
> 
> In fd_is_mount_point() we obviously don't have access to the file name
> any more, and presumably we do want to keep it for efficiently
> implementing the "rm-rf: never cross mount points" commit f25afeb.
> 
> Since all possible checks in fd_is_mount_point() rely on *at(, "..")
> which doesn't work for files, one solution that I see
> is to add a fallback path_is_mountpoint() if fd_is_mount_point() fails
> with ENOTDIR; in that case, should we implement all fallbacks again
> (lots of duplicated code), or just one (st_dev comparison, which seems
> the most widely supported one)?
> 
> Alternatively we could pass a "parent_path" to fd_is_mount_point(),
> compute that in path_is_mountpoint(), and don't specify one (or maybe
> we even can specify it easily, I didn't check) in rm_rf_children() as
> file bind mounts don't seem relevant there. This would be simpler, but
> it would technically be an API break (unless we want to add
> fd_is_mount_point_with_parent).

Not an API break. Only calls prefixed with "sd_" are API, we never
export any others.

But yeah, path_is_mount_point() should be reworked to operate like
openat() and similar calls, i.e. taking an fd to a dir, plus a
filename below that dir, instead of directly and only an fd to the
file below that dir.

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] 219/Fedora22: NFS mounts do not set SELINUX label to nfs_t: errno=-22

[Lennart Poettering]

On Sun, 24.05.15 15:01, Anthony Alba (ascanio.al...@gmail.com) wrote:

> Hi,
> 
> On Fedora 22, systemd 219, NFS mounts no longer acquire a default label nfs_t.
> 
> mount 192.168.1.6:/var/exports/1 1 -orootcontext=system_u:object_r:nfs_t
> mount.nfs: an incorrect mount option was specified
> [ 8316.276744] SELinux:
> security_context_to_sid(system_u:object_r:nfs_t) failed for (dev 0:51,
> type nfs4) errno=-22
> 
> 
> To my surprise, it seems to acquire labels from the NFS server (Fedora
> 22/nfs4)  - how is this possible?
> 
> But..it breaks libvirtd/kvm: it sees the "right" label if this were a
> local filesystem but audit2allow complains:
> 
> 
> ls -lZ guestfs/centos7.img
> -rw-r--r--. 1 qemu qemu system_u:object_r:virt_image_t:s0 22987538432
> May 24 14:56 guestfs/centos7.img
> ## for a image in /var/lib/libvirt this is the correct label.
> ## I do not know how it figured that from the NFS server
> 
> SELinux is preventing qemu-system-x86 from read access on the file
> centos7.img (on NFS share).
> 
> On Fedora 21, the files acquire the label nfs_t and setsebool -P 
> virt_use_nfs=on

This is unlikely to be related to systemd, we don't really do anything
special with NFS and especially not its selinux support. We simply
invoke util-linux' mount command, which in turn calls mount.nfs of the
nfs-utils package.

Please contact the nfs-utils guys,

thank you,

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] core: if PR_SET_CHILD_SUBREAPER fails, log_error instead of warning

[Lennart Poettering]

On Sun, 24.05.15 22:41, Tom Gundersen (t...@jklm.no) wrote:

> On Sat, May 23, 2015 at 6:04 PM, Cristian Rodríguez
>  wrote:
> > It was a warning when we still supported kernel < 3.4. current
> > minimum version is 3.7.
> 
> Hm, we don't actually fail out here, but we still try to continue.
> Isn't 'warning' more appropriate in that case?

Yes.

The warning should stay a warning, but the EINVAL check with its info
message should indeed go.

> 
> Cheers,
> Tom
> 
> >  src/core/main.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/src/core/main.c b/src/core/main.c
> > index c39815b..3bebc98 100644
> > --- a/src/core/main.c
> > +++ b/src/core/main.c
> > @@ -1608,9 +1608,7 @@ int main(int argc, char *argv[]) {
> >  if (arg_running_as == MANAGER_USER) {
> >  /* Become reaper of our children */
> >  if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
> > -log_warning_errno(errno, "Failed to make us a 
> > subreaper: %m");
> > -if (errno == EINVAL)
> > -log_info("Perhaps the kernel version is 
> > too old (< 3.4?)");
> > +log_error_errno(errno, "Failed to make us a 
> > subreaper: %m");
> >  }
> >  }
> >
> > --
> > 2.4.1
> >
> > ___
> > 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


Lennart

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

[systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

Hi,

I was wondering if we have a way to provide vendor default masked service?

Vendor default masked service has advantages like:
 - systemctl start won't work
 - dbus activation won't work

It is common that an embedded system doesn't use packages, rather it
ships everything in monolithic image. Enabling, disabling, presetting
is great to prevent a service from starting as part of the target but
it doesn't stop anyone trying to start it with systemd (systemctl
start, or dbus activation).

I have come up with my way but obviously "systemctl unmask" doesn't
mean anything in this case. I was wondering if there is a way I am not
aware of.

/usr/lib/systemd/system:
aa.service: Service file implementation
a.target.wants/a.service: Start the service with a.target.
a.service: Can either be a link to aa.service (start the service) or
/dev/null (service is masked, won't start).

If the service is masked (a.service -> /dev/null), to enable it we
need to create (/etc/systemd/system/a.service ->
/usr/lib/systemd/system/aa.service).

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

[systemd-devel] crda broken with systemd 220

[Michał Bartoszkiewicz]

Hello,

it seems that udev from systemd 220 does passes empty environment to a
process spawned by a RUN rule.
execve("/usr/sbin/crda", ["/usr/sbin/crda"], [/* 0 vars */]) = 0
This breaks crda, as it expects to see COUNTRY in its environment.

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

Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[David Härdeman]

On 2015-05-26 00:05, Alberto Bertogli wrote:
I hit this issue after upgrading a system that used keyscript to 
Jessie,

and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, 
and/or

creating a generic one that would invoke keyscripts as a workaround...



...

On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:

On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
> b) the password agent implementation in systemd doesn't seem to
> handle binary strings (i.e. strings with '\0'), as can be seen by
> calls to e.g. "strlen()"...
>
> Whether making it binary safe would be a major change or not is
> something I haven't researched yet but it seems like a change that
> should be generally useful upstream...

I'd be OK with this, as discussed at FOSDEM, and I see you already
posted a ptach for this.


Has this been merged?


No, the last word was basically this thread:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021246.html

I don't have the time to implement a "complete" solution...


Is it safe for a password agent to write content with \0 back to the
socket?


Haven't checked but I'd be surprised if that was the case.

//David

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

[systemd-devel] inotify_add_watch() failed: Bad file descriptor

[Christian Hesse]

Hello everybody,

with systemd v220 I see inotify errors from udevd. I get this once:

systemd-udevd: inotify_add_watch(9, /dev/sr0, 10) failed: Bad file descriptor

And a lot of these:

systemd-udevd: inotify_add_watch(9, /dev/dm-[0-9]+, 10) failed: Bad file
descriptor
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}


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