date:20150203

On Tue, 03.02.15 02:36, Mikhail Morfikov (mmorfi...@gmail.com) wrote:

 So, everything works pretty well. 
 
 Now there's a problem, how to add socket activation to this
 container?

Well, the sockets for socket activated containers are created on the
host's namespace, not the container's namespace. They are then passed
into the container namespace, but they still belong to the host's
namespace. This means to connect to them you must connect to one of
the host'S IP addresses, not the container's IP addresses.

If the container's and host namesapces are identical (which is the
case if you don't use --private-network or any of the --network-xyz
switches), then the distinction goes away of course.

Also note that using socket activation for cotnainers means that
systemd instance inside the container also needs to have configuration
for the socket, to pass it on to the service that ultimately shall
answer for it. Are you sure that apache2 has support for that, and
that you set it 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] [PATCH v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

2015-02-03 Thread Kay Sievers

On Tue, Feb 3, 2015 at 3:09 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Feb 03, 2015 at 01:34:23PM +0100, Lennart Poettering wrote:
 On Thu, 29.01.15 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
 wrote:

  On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote:
   On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl mbi...@gmail.com wrote:
Updated patch which the correct version information.
  
   Applied.
 
  Hm, I think this was an unintentional ABI break. udev_queue_flush @@ 
  LIBUDEV_183
  was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker cannot 
  know
  that this is the same symbol.

 Hmm can you elaborate on this? I missing the context? Is there
 something to fix here?
 For two releases systemd had a symbol, which then got removed.
 Anyone compiling during that time and using it, would get a crashing
 binary after installing systemd from the latest version.

 Although this happened a while ago and nobody complained suggests
 that there were few users, and any there were got recompiled anyway.

There should be no external users of these symbols, they were just
exported for consistency.

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

Re: [systemd-devel] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

On Tue, 30.12.14 06:49, Simon Peeters (peeters.si...@gmail.com) wrote:

 2014-12-29 14:14 GMT+00:00 Tom Gundersen t...@jklm.no:
  On Mon, Dec 29, 2014 at 2:34 PM, Lennart Poettering
  lenn...@poettering.net wrote:
 snip
  I am open to adding support for this, but I think the allocation of
  the UID ranges should really happen automatically, and not be
  something the admin has to manually assign.
 
  Which means we'd enter dynamic UID allocation terroritory, and that
  opens a huge can of worms...
 
  Would we not also need to support explicit assignment, in case someone
  has a preexisting image they want to match in a specific way? In that
  case we could start off without the dynamic allocation and add that
  later. It certainly would make testing a lot simpler if we had userns
  support sooner rather than later (at least in the case of netlink it
  appears to be quite a mess).
 
 Inspired by this topic I wrote a quick'n'dirty uid allocator[1]
 this allocator manages the upper 2G uid's, which using Matthias Urlichs 
 example
 of 2048 uid's per container, still allows for 1M containers.
 
 It curently can't persist these allocations, but that is on my
 0.0.1 todolist.

Hmm, so, I thought a lot about this in the past weeks. I think the way
I'd really like to see this work in the end is that we never have to
persist the UID mappings. This could work if the kernel would provide
us with the ability to bind mount a file system into the container
applying a fixed UID shift. That way, the shifted UIDs would never hit
the actual disk, and hence we wouldn't have to persist their mappings.

Instead on each container startup we'd look for a new UID range, and
release it entirely when the container shuts down. The bind mount with
UID shift would then shift the UIDs up, the userns stuff would shift
it down from inside the container again.

Of course, this all depends on whether the kernel will get an
extension to apply uid shifts to bind mounts. I hear they want to
provide this, but let's see.

I kinda would prefer to see how that works out before we add any
infrastructure for automatic allocation to systemd, since only then we
have the full picture to consider.

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] path: conditionally depend on the triggered unit

On Mon, 29.12.14 14:07, Jouke Witteveen (j.wittev...@gmail.com) wrote:

heya,

sorry for the late review, still busy catching up with all the queued
mail.

 Path units having either PathExists=, PathExistsGlob=, or
 DirectoryNotEmpty= want the service they trigger when the condition is
 met. This way it becomes meaningful to include StopWhenUnneeded=true in
 the triggered service.

Hmm, I see how this could be useful, but the patch like this is not
OK. Dependencies in systemd are strictly additive. The only way to get
rid of dependencies is by doing a full reload of the configuration. We
coalesce dependencies from a variety of sources, and if we really
wanted to allow dynamically dropping deps again we'd couldn't do that
anymore and would have to track precisely the reason for each dep that
is added.

I wonder if we can find a better way to handle this...

So far the issue never came up since we expected that services would
exit-in-idle on their own, so that we never need an external trigger
to automatically shut something down, but the daemons would do so on
their own.

Can you elaborate on your precise usecase for this?

I mean, even if we added the facility you propose this would require
the services to operate in a certain way to be fully safe and
race-free. But if that's the case, then they might as well shut down
on their own at the right time?

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] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

On Tue, 03.02.15 15:03, Daniel P. Berrange (berra...@redhat.com) wrote:

  Hmm, so, I thought a lot about this in the past weeks. I think the way
  I'd really like to see this work in the end is that we never have to
  persist the UID mappings. This could work if the kernel would provide
  us with the ability to bind mount a file system into the container
  applying a fixed UID shift. That way, the shifted UIDs would never hit
  the actual disk, and hence we wouldn't have to persist their mappings.
  
  Instead on each container startup we'd look for a new UID range, and
  release it entirely when the container shuts down. The bind mount with
  UID shift would then shift the UIDs up, the userns stuff would shift
  it down from inside the container again.
  
  Of course, this all depends on whether the kernel will get an
  extension to apply uid shifts to bind mounts. I hear they want to
  provide this, but let's see.
 
 I would dearly love to see that happen. Having to recursively change
 the UID/GID on entire filesystem sub-trees given to containers with
 userns is a real unpleasant thing to have to deal with. I'd not want
 the filesystem UID shift to only apply to bind mounts though. It is
 not uncommon to use a disk image[1] for a container's filesystem, so
 being able to request a UID shift on *any* filesystem mount is pretty
 desirable, rather than having to mount the image and then bind mount
 it onto itself just to apply the UID shift.

Well, you can always change the bind mount flags without creating a
new bind mount with MS_BIND|MS_REMOUNT.

 [1] Using a separate disk image per container means a container can't
 DOS other containers by exhausting inodes for example with $millions
 of small files.

Indeed. I'd claim that without such a concept of mount point uid
shifting the whole userns story is not very useful IRL...

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] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

2015-02-03 Thread David Herrmann

Hi

On Tue, Feb 3, 2015 at 3:41 PM, Lennart Poettering
lenn...@poettering.net wrote:
 Hmm, so, I thought a lot about this in the past weeks. I think the way
 I'd really like to see this work in the end is that we never have to
 persist the UID mappings. This could work if the kernel would provide
 us with the ability to bind mount a file system into the container
 applying a fixed UID shift. That way, the shifted UIDs would never hit
 the actual disk, and hence we wouldn't have to persist their mappings.

An alternative would be to map UIDs to the owning user-namespace of
the current mount-namespace when accessing disks (which is the
user-namespace active at the time the mount-namespace was created).

Anyway, this all depends on kernel people to accept this..

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

Re: [systemd-devel] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

2015-02-03 Thread Daniel P. Berrange

On Tue, Feb 03, 2015 at 03:41:22PM +0100, Lennart Poettering wrote:
 On Tue, 30.12.14 06:49, Simon Peeters (peeters.si...@gmail.com) wrote:
 
  2014-12-29 14:14 GMT+00:00 Tom Gundersen t...@jklm.no:
   On Mon, Dec 29, 2014 at 2:34 PM, Lennart Poettering
   lenn...@poettering.net wrote:
  snip
   I am open to adding support for this, but I think the allocation of
   the UID ranges should really happen automatically, and not be
   something the admin has to manually assign.
  
   Which means we'd enter dynamic UID allocation terroritory, and that
   opens a huge can of worms...
  
   Would we not also need to support explicit assignment, in case someone
   has a preexisting image they want to match in a specific way? In that
   case we could start off without the dynamic allocation and add that
   later. It certainly would make testing a lot simpler if we had userns
   support sooner rather than later (at least in the case of netlink it
   appears to be quite a mess).
  
  Inspired by this topic I wrote a quick'n'dirty uid allocator[1]
  this allocator manages the upper 2G uid's, which using Matthias Urlichs 
  example
  of 2048 uid's per container, still allows for 1M containers.
  
  It curently can't persist these allocations, but that is on my
  0.0.1 todolist.
 
 Hmm, so, I thought a lot about this in the past weeks. I think the way
 I'd really like to see this work in the end is that we never have to
 persist the UID mappings. This could work if the kernel would provide
 us with the ability to bind mount a file system into the container
 applying a fixed UID shift. That way, the shifted UIDs would never hit
 the actual disk, and hence we wouldn't have to persist their mappings.
 
 Instead on each container startup we'd look for a new UID range, and
 release it entirely when the container shuts down. The bind mount with
 UID shift would then shift the UIDs up, the userns stuff would shift
 it down from inside the container again.
 
 Of course, this all depends on whether the kernel will get an
 extension to apply uid shifts to bind mounts. I hear they want to
 provide this, but let's see.

I would dearly love to see that happen. Having to recursively change
the UID/GID on entire filesystem sub-trees given to containers with
userns is a real unpleasant thing to have to deal with. I'd not want
the filesystem UID shift to only apply to bind mounts though. It is
not uncommon to use a disk image[1] for a container's filesystem, so
being able to request a UID shift on *any* filesystem mount is pretty
desirable, rather than having to mount the image and then bind mount
it onto itself just to apply the UID shift.


Regards,
Daniel

[1] Using a separate disk image per container means a container can't
DOS other containers by exhausting inodes for example with $millions
of small files.
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] src/bus-proxyd src/login src/machine src/nspawn src/tmpfiles

2015-02-03 Thread Thomas H.P. Andersen

On Tue, Feb 3, 2015 at 12:50 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Mon, Feb 02, 2015 at 02:07:37PM -0800, Thomas H.P. Andersen wrote:
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
 @@ -3610,7 +3610,6 @@ int main(int argc, char *argv[]) {
  }

  if (arg_ephemeral) {
 -_cleanup_release_lock_file_ LockFile original_lock 
 = LOCK_FILE_INIT;
  char *np;

  /* If the specified path is a mount point we
 diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
 index 930b9a6..443851a 100644
 --- a/src/tmpfiles/tmpfiles.c
 +++ b/src/tmpfiles/tmpfiles.c
 @@ -630,7 +630,7 @@ static int get_xattrs_from_arg(Item *i) {

  while ((r = unquote_first_word(p, xattr, false))  0) {
  _cleanup_free_ char *tmp = NULL, *name = NULL,
 -*value = NULL, *value2 = NULL, *_xattr = xattr;
 +*value = NULL, *value2 = NULL;
 This leaks xattr, no?
oh, you are right. I will revert that.

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

Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

2015-02-03 Thread Rauta, Alin

Yes, since the concept of UFD group is not exposed. 
/Alin

-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net] 
Sent: Monday, February 2, 2015 5:24 PM
To: Rauta, Alin
Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List
Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) 
support to networkd

On Thu, 29.01.15 11:20, Rauta, Alin (alin.ra...@intel.com) wrote:

heya,

 Regarding the networkctl update to show the UFD groups in a user 
 friendly fashion, what about that ?

Well, I am not particularly convinced we should expose the concept of an UFD 
group at all. However, I think it would make a ton of sense to show which 
interfaces are downlinks to an uplink interface, and which interface is an 
uplink for a downlink interface, all based on the relation expressed with 
BindCarrier=.

 # networkctl ufd 1
 ● UFD Group: 1
   State: configured
 Uplinks:
→ 12: sw0p10
   Downlinks:
→ 51: sw0p49
→ 53: sw0p51
→ 7: sw0p5
→ 9: sw0p7

For this example, I think networkctl should show:

# networkctl status sw0p10
...
Carrier Bound By: sw0p49
  sw0p51
  sw0p5
  sw0p7
...
# netwokctl status sw0p49
...
Carrier Bound To: sw0p10
...

If that makes sense?

Lennart

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

Re: [systemd-devel] I see Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory in systemd journal when I log in as root via ssh.

On Tue, 03.02.15 12:51, crocket (crockabisc...@gmail.com) wrote:

 Below is the relevant part of the systemd journal log.
 /usr/lib/systemd/systemd exists, but the journal says it doesn't exist
 sometimes when I log in as root via ssh.

Any chance you can use strace -f -p 1 -s 500 -o /tmp/pid1-strace to
trace PID 1 when this happens? Just run that command, try to trigger
this, and then paste the last 250 lines or so this generates here, in
particular all output around any lines that mention at step
CGROUP...

Thanks,

Lennart

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

Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down

2015-02-03 22:38 GMT+01:00 Lennart Poettering lenn...@poettering.net:
On Tue, 03.02.15 22:22, Michael Biebl (mbi...@gmail.com) wrote:

2015-02-03 22:10 GMT+01:00 Lennart Poettering lenn...@poettering.net:
I don't see how this would apply to non-sysv code. I mean, code that
is written with systemd semantics in mind should be able to issue a
service reload during any time it wants to, if it keeps the ordering
issues in mind. For example, if I have a service that has
DefaultDependencies=no (and hence ordered against nothing at all by
default), and I want to issue systemctl reload on it, knowing that
this cannot really deadlock, since there are no deps that could cause
deadlocks, then i should be able to do so. With your patch you turn
these reloads into NOPs...

During shutdown (and early boot), yes. But why would you want to
schedule a restart or reload during shutdown?

Well, we try to keep reloads out of the default codepaths, but it's
easy to construct cases where people might want to deviate fromt the
default codepaths.

Do you have a real-world example for that?

Consider systemd-journald.service. It's a service with
DefaultDependencies=no. We don't terminate it as part of the normal
shutdown, we leave that to the final killing spree, so that we have
logging for as long as possible.

Now, people might want to hack something up that changes journald
configuration to forward logs to kmsg during the last part of
shutdown, so that they can see it in netconsole or so. SO they write
their little service that patches journald.conf and restarts journald,
and this is done during shutdown from a normal service's ExecStop=
line. This normally works fine, since journald is not ordered against
anything that matters. But it doesn't work on Debian, because on
Debian there's no way anymore to restart journald as soon as shutdown
commenced...

While I just made this scenario up I think it's actually quite
realistic, and I think it's a valid thing for admins to do

Well, we could easily check if DefaultDependencies=yes in this case.
Actually, this is already what we do for the boot case. [1]

So even with your made-up example, it would work.

The thing is, you have to be extra careful to never, ever call a
restart/reload from such hook scripts. If those are triggered via
service or systemctl on a native or SysV script doesn't make a
difference.

It is completely fine to enqueue restarts and reloads from hook
scripts. However the emphasis is on *enqueue*. The issue is that you
block on it, you shouldn't do that.

On Fedora, iscsi is reloaded from an NM callout. If you ask me that's
frickin' ugly, but it *is* supported as long as iscsi's reload is
queued asynchronously instead of requested synchronously. In Fedora,
the logic to make this async sits on the client side of things, it's
not enforced by the engine in PID 1.

The same really applies to Debian too...

It's simply to easy to cause a dead lock this way, and I think systemd
should try much harder to avoid such situations.

Well, it would be great if we could solve the halting problem. But we
can't.

I mean, I am all ears regarding adding deadlock detection code. But I
am really not convinced that breaking the engine for *everybody* just
because *some* clients are weird is an option.

Calling it breaking the engine for everybody is hyperbole.

That said, do you have better ideas how we could avoid having systemd
easily being dead-locked on shutdown?
I'm all for solving it in a nicer way. But simply throwing the hands
in the air and saying, not our problem, doesn't help.
Things like that hurt our users badly. systemd should always try to
get into a usable state, i.e. to boot into state where one can log in,
or shutdown/reboot successfully.
As much as I like systemd, it's really easy to break it currently and
it would be awesome if it was more robust in such situations.

Michael

[1]
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Avoid-reload-and-re-start-requests-during-early-boot.patch

--
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 2/4] systemctl: edit: improve error messages, report actual error for units which could not be loaded

On Fri, 19.12.14 17:08, Ivan Shapovalov (intelfx...@gmail.com) wrote:

What happened to this patch series actually? I think only 1/4 was ever
commited, what about the other ones? Ivan, any chance you can rebase
the rest with Zbigniew's requested changes and post again?

Thanks,

Lennart

 Not found condition in find_paths_to_edit() has been made non-fatal
 because the error message in edit() (Cannot find any units to edit)
 suggests that.
 
 Error messages in edit() themselves have been removed because
 - result of expand_names() is not checked anywhere else
 - an extra cannot find any units to edit is redundant due to error reporting
   for each unit in unit_find_paths() and find_paths_to_edit()
 ---
  src/systemctl/systemctl.c | 53 
 +++
  1 file changed, 40 insertions(+), 13 deletions(-)
 
 diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
 index 7af111c..658793e 100644
 --- a/src/systemctl/systemctl.c
 +++ b/src/systemctl/systemctl.c
 @@ -2325,9 +2325,12 @@ static int unit_find_paths(sd_bus *bus,
  
  if (!avoid_bus_cache  !unit_name_is_template(unit_name)) {
  _cleanup_bus_error_free_ sd_bus_error error = 
 SD_BUS_ERROR_NULL;
 +_cleanup_bus_message_unref_ sd_bus_message *unit_load_error 
 = NULL;
  _cleanup_free_ char *unit = NULL;
  _cleanup_free_ char *path = NULL;
  _cleanup_strv_free_ char **dropins = NULL;
 +_cleanup_strv_free_ char **load_error = NULL;
 +char *unit_load_error_name, *unit_load_error_message;
  
  unit = unit_dbus_path_from_name(unit_name);
  if (!unit)
 @@ -2336,6 +2339,31 @@ static int unit_find_paths(sd_bus *bus,
  if (need_daemon_reload(bus, unit_name)  0)
  warn_unit_file_changed(unit_name);
  
 +r = sd_bus_get_property(
 +bus,
 +org.freedesktop.systemd1,
 +unit,
 +org.freedesktop.systemd1.Unit,
 +LoadError,
 +error,
 +unit_load_error,
 +(ss));
 +if (r  0)
 +return log_error_errno(r, Failed to get LoadError: 
 %s, bus_error_message(error, r));
 +
 +r = sd_bus_message_read(
 +unit_load_error,
 +(ss),
 +unit_load_error_name,
 +unit_load_error_message);
 +if (r  0)
 +return bus_log_parse_error(r);
 +
 +if (!isempty(unit_load_error_name)) {
 +log_error(Unit %s is not loaded, ignoring: %s, 
 unit_name, unit_load_error_message);
 +return 0;
 +}
 +
  r = sd_bus_get_property_string(
  bus,
  org.freedesktop.systemd1,
 @@ -2403,6 +2431,10 @@ static int unit_find_paths(sd_bus *bus,
  r = unit_file_find_dropin_paths(lp-unit_path, NULL, 
 names, dropin_paths);
  }
  
 +if (r == 0) {
 +log_error(No files found for unit %s, ignoring., 
 unit_name);
 +}
 +
  return r;
  }
  
 @@ -4780,10 +4812,8 @@ static int cat(sd_bus *bus, char **args) {
  r = unit_find_paths(bus, *name, avoid_bus_cache, lp, 
 fragment_path, dropin_paths);
  if (r  0)
  return r;
 -else if (r == 0) {
 -log_warning(Unit %s does not have any files on 
 disk, *name);
 +else if (r == 0)
  continue;
 -}
  
  if (first)
  first = false;
 @@ -6114,9 +6144,13 @@ static int find_paths_to_edit(sd_bus *bus, char 
 **names, char ***paths) {
  r = unit_find_paths(bus, *name, avoid_bus_cache, lp, path, 
 NULL);
  if (r  0)
  return r;
 -else if (r == 0 || !path)
 +else if (r == 0)
 +continue;
 +else if (!path) {
  // FIXME: support units with path==NULL (no 
 FragmentPath)
 -return log_error_errno(ENOENT, Unit %s not found, 
 cannot edit., *name);
 +log_error(No fragment exists for unit %s, 
 ignoring.);
 +continue;
 +}
  
  if (arg_full)
  r = unit_file_create_copy(*name, path, user_home, 
 user_runtime, new_path, tmp_path);
 @@ -6155,19 +6189,12 @@ static int edit(sd_bus *bus, char **args) {
  if (r

Re: [systemd-devel] [PATCH] libabc: Make things hold a reference to their context

2015-02-03 Thread Kay Sievers

On Mon, Dec 8, 2014 at 10:12 PM, Josh Triplett j...@joshtriplett.org wrote:
 The sample libabc includes functions to get a thing, as a sample
 sub-object of the overall library context.  Each thing has a reference
 to the parent library context, and a function to return that reference.
 Given that, abc_thing_new_from_string should call abc_ref, and
 abc_thing_unref should call abc_unref when freeing a thing.
 ---
  src/libabc.c | 3 ++-

Applied.

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

Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random

2015-02-03 Thread Josh Triplett

On Mon, Feb 02, 2015 at 04:42:21PM +0100, Lennart Poettering wrote:
 On Mon, 02.02.15 12:06, Cristian Rodríguez (crrodriguez at opensuse.org) 
 wrote:
 
  Using /dev/urandom as a key is valid for swap, do not
  warn if this devices are world readable.
  ---
   src/cryptsetup/cryptsetup.c | 6 --
   1 file changed, 4 insertions(+), 2 deletions(-)
  
  diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
  index e6b37ac..38930ae 100644
  --- a/src/cryptsetup/cryptsetup.c
  +++ b/src/cryptsetup/cryptsetup.c
  @@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {
   
   /* Ideally we'd do this on the open fd, but since 
  this is just a
* warning it's OK to do this in two steps. */
  -if (stat(key_file, st) = 0  (st.st_mode  
  0005))
  -log_warning(Key file %s is 
  world-readable. This is not a good idea!, key_file);
  +if (stat(key_file, st) = 0  (st.st_mode  
  0005)) {
  +if(!STR_IN_SET(key_file, /dev/urandom, 
  /dev/random, /dev/hw_random))
  +log_warning(Key file %s is 
  world-readable. This is not a good idea!, key_file);
  +}
 
 I'd prefer if we'd change the check instead to only apply to
 S_ISREG() files. This way we wouldn't have to list all RNG device
 nodes.

With the exception of /dev/*random, you don't want a world-readable
device used for a key either.  Some people have setups that use a USB
device (e.g. /dev/sd* or /dev/disk/by-*/*) as a keyfile, and in that
case, the file should *not* be world-readable.

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

Re: [systemd-devel] Container, private network and socket activation

2015-02-03 Thread Christian Seiler

Am 03.02.2015 um 22:06 schrieb Lennart Poettering:
 Socket activation is somethings daemons need to support
 explicitly. Many do these days, but I don't think Apache is one of
 them.

FYI: all released versions (i.e. up to 2.4.x) of Apache httpd don't
support it yet, but the current development version does - at least if
you compile it with the corresponding options (no module needs to be
loaded for that, it's in the core).

There's a proposal to backport that and sd_notify integration[1] to the
stable 2.4.x branch, but nothing's happened so far:

http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?revision=1656674view=markup#l138

[1] Although Fedora apparently already includes sd_notify integration
for quite a while now, but no socket activation...

Christian

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

Re: [systemd-devel] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

2015-02-03 Thread Josh Triplett

Lennart Poettering wrote:
 Hmm, so, I thought a lot about this in the past weeks. I think the way
 I'd really like to see this work in the end is that we never have to
 persist the UID mappings. This could work if the kernel would provide
 us with the ability to bind mount a file system into the container
 applying a fixed UID shift. That way, the shifted UIDs would never hit
 the actual disk, and hence we wouldn't have to persist their mappings.

It ought to be possible to run an arbitrary distribution inside a
container, even a distribution that itself wants to run sandboxed
applications in containers.  Nesting matters, so a bare shift may not
suffice.  On the other hand, a shift is the simplest solution for simple
utility containers, such as those launched by systemd-nspawn.  nspawn
could trivially avoid persisting the UID map by applying a shift, while
a full container solution might want to construct persistent dynamic UID
maps, or integrate with special PAM/NSS modules, or any number of other
creative solutions.

Container UID handling was exactly what I had in mind when I sent in a
kernel patch for the setusers() system call.  If an unprivileged user on
the host system can have a pile of UIDs handed to them by the host
system, and can use any of those IDs in their UID map, then they can set
up any arbitrary container UID handling without further assistance from
host root.  A PAM module on the host could then, by policy, hand some or
all unprivileged users a substantial stack of host UIDs that they can
arbitrarily map to container UIDs; together with support for applying
UID maps to a mounted filesystem, that would provide all the necessary
kernel support.

In addition to containers, that would also provide a sensible solution
for a smarter fakeroot-style tool that lets a user construct filesystems
with slightly more complicated policies than root owns everything,
again without any help from host root other than here, have a pile of
subordinate UIDs.

I'd be happy to revisit kernel setusers() support if anyone would be
interested in saying yes, this is the solution we want.

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

Re: [systemd-devel] [PATCH] gpt-auto-generator: honor read-only attribute for native rootfs, post-initrd.

On Mon, 29.12.14 14:33, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

Heya,

Sorry for the late review, still busy keeping up with all the unmerged
patches and unreplied mails that queued up...

Is this issue still relevant?

 Signed-off-by: Dimitri John Ledkov dimitri.j.led...@intel.com

(We do not use S-o-b, we are not the kernel...)

  This is not yet really ready for application, as ultimately this is
  only solution for part of the problem.
 
  With this patch, post-initrd -.mount unit will have correct
  Options=rw if READ_ONLY flag is not set and ro/rw was not specified
  on the kernel cmdline. In the initrd the -.mount unit will continue
  to be mounted ro by default (honoring cmdline rw flag, but ignoring
  unset READ_ONLY flag).
 
  However, remount-fs only considers /etc/fstab and only remounts
  things with options as specified in the /etc/fstab. Thus the fact
  that -.mount unit changed Options=ro - Options=rw between
  initramfs and pivoted system does not result in the root filesystem
  getting remounted as rw.

Hmm, what precisely is the issue again here? You are looking for a way
to make the root disk writable when using gpt auto discovery after
boot, without shipping an /etc/fstab that would result in remounting
after boot? Why wouldn't specifying rw on the kernel cmdline suffice
for that?

Lennart

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

Re: [systemd-devel] [PATCH][Resend][RFC] core: Fix wrong timestamps in rtc-in-local time mode.

On Thu, 25.12.14 22:00, Chunhui He (hchun...@mail.ustc.edu.cn) wrote:

Sorry for the late response, still busy processing all the queued
mails and patches...

 Thanks David! Yes, I missed Lennart's reply.
 
 Thanks Lennart!
 Yes, I agree rtc-in-local-time is a compatibility hack.
 
 But I think similar issues in other components is orthogonal to this bug.
 The key is that systemd records _inconsistent_ timestamps. It's surely a
 logic _error_ introduced in commit 3a170f3d3358135a39ac6eafe66f18aef0bd67d,
 even though this bug appears in compatibility hack.
 
 rtc-in-utc is orthogonal too. In contrast, using rtc-in-utc is a workaround
 in this situation. Since we provide the compatibility, we have to fix it.

Hmm, so you are saying there's a bug in rtc-in-utc behaviour here too?
Could you elaborate, please?

I mean, I think we should accept that wallclock time is not linear (I
mean, the fact that it isn't linear is acknowledged by the existance
of CLOCK_MONOTONIC...), and I think it's a really good idea to record
the kernel's notion of the wallclock time at the point some event
happened, even if it's likely to be incorrectly set. 

Note that we do a lot of things before the initial timewarp is done,
including loading of the SELinux policy. Given how time consuming
loading of SELinux policy is, and that it might result in log messages
on its own, we really should not confuse the user by reporting some
very selected early, specific events adjusted, while leaving the usual
events unadjusted... 

We are really interested in making logging timestamps relatable to
each other, regardless where they come from. This only works, if the
all sources use the unaltered kernel timestamps, so that everybody's
time axis makes a jump at the same time when the timewarp is first
enforced. Adjusting some logged timestamps but not others would be
really confusing...

I hope this makes any sense. But maybe I misunderstood what precsiely
you are actually intending to change with 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] [PATCH] gpt-auto-generator: honor read-only attribute for native rootfs, post-initrd.

On Tue, 03.02.15 16:11, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

  Hmm, what precisely is the issue again here? You are looking for a way
  to make the root disk writable when using gpt auto discovery after
  boot, without shipping an /etc/fstab that would result in remounting
  after boot? Why wouldn't specifying rw on the kernel cmdline suffice
  for that?
 
 The issue is that without specifying neither ro nor rw on the
 kernel command line (nor via any other configuration - e.g.
 /etc/fstab, explicit mount unit etc.), the partition flags are not
 honoured for the root partition by gpt-auto-generator and one ends up
 with a ro mounted rootfs, instead of a rw one.

Well, I'd claim it *is* honoured... After all the flag is called
read-only, and hence when set it ensures that things are read-only,
but it doesn't make any claim about what happens when writable... But
of course, that's nitpicking... ;-)

Maybe we should turn the gpt part flags into a tri-state, by adding a
second bit to it:

  00 → default behaviour, which means ro for root parts, rw for other parts
  10 → always read-only, regardless if root or not
  01 → always writable, regardless if root or not

And the existing bit would be the first of the two bits
above. Combination 11 would be invalid, but treated as 00 for now...

And the kernel options ro and rw would always override the flags
for the root disk, and so would fstab.

Would that work for you?

Would be happy to take a patch for this!

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] Avoid reloading services when shutting down

2015-02-03 Thread Martin Pitt

Lennart Poettering [2015-02-03 17:29 +0100]:
 Hmm, why precisely does this stall for 90s? 

The current transaction has final.target and all other jobs which need
to be shut down. One of these now trigger systemctl reload
postfix.service, but that reload isn't going to actually run in the
same transaction but in the next one. OTOH systemctl reload
waits for the reloading to finish, thus we have a deadlock.

 Isn't this a case where people should just use --no-block?

Kind of. Not using this is the right thing while the machine is
running, so that the reload is actually done after calling systemctl
reload, and you can go on using postfix or whatever. --no-block should
help during shutdown, or early boot (same principal bug, but slightly
different patch, see http://bugs.debian.org/624599).

So every time you call reload you'd have to check whether or not you
are in early boot/during shutdown, or in the running system, and
conditionally use --no-block. However, as such scripts should never
call systemctl directly, but service foo reload (to work with other
init systems or chroot), it would be also possible to move that check
there, and conditionally add --no-block. It would just be another
thing that every distro has to re-discover :-)

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] test-dhcp-client failing in mock builds

On Tue, Feb 03, 2015 at 06:49:21AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Tue, Feb 03, 2015 at 02:42:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
  On Mon, Feb 02, 2015 at 08:30:43AM +0100, Jan Synacek wrote:
   http://lists.freedesktop.org/archives/systemd-devel/2014-December/026190.html
  
   I haven't got time to properly analyze the problem since then...
  It sounded familiar ;)
  
  
  On Mon, Feb 02, 2015 at 01:36:29PM +0200, Patrik Flykt wrote:
   Operation not permitted is what is printed for EPERM. But EPERM is not
   present in the client code itself, so I'm inclined towards a permission
   problem somewhere when running mock.
  EPERM is also returned when using /dev/null in epoll_ctl_add.
  I think I fixed it now.
  
  Which leads to a failure on arm in test-network:
  FAIL: test-network
  ==
  Assertion '!address_equal(a1, a2)' failed at 
  ../src/network/test-network.c:161, function test_address_equality(). 
  Aborting.
  
  I got out my chromebook to see what going on here.
 Ha, undefined behaviour on right shift. Gotta love C ;)
 
 So the tests pass in mock on all three primary arches.
 
 I'll let it spin on arm64 just to see what comes up.
And that passes too. 

Zbyszek

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

Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217

2015-02-03 Thread Patrik Flykt

On Tue, 2015-02-03 at 11:46 +0100, Lennart Poettering wrote:
 On Mon, 02.02.15 23:12, Charles Devereaux (syst...@guylhem.net) wrote:
 
  Another problem with systemd-networkd is that the lease is not renewed
  after sleep.
  
  This is a basic feature, a laptop is frequently physicially moved, which
  means another DHCP lease should be acquired, but I don't see how to
  do that.
 
 Hmm, I figure all DHCP leases should be refreshed when we come back
 from suspend. Hooking that up should be pretty easy. Added to the TODO
 list.
 
 That said, isn't the link beat lost anyway during suspend, and thus we
 should refresh automatically, anyway? 
 
 Either way refreshing on resume can't hurt...

Is the resume event detected somehow in systemd? I'd assume that links
are lost when suspending and reconnected on resume, so maybe that is the
only event needing attention. I'll take a quick look into what my laptop
thinks about the issue...


Cheers,

Patrik

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

Re: [systemd-devel] serialization bug, swap bug, etc.

On Tue, 16.12.14 17:22, Filipe Brandenburger (filbran...@google.com) wrote:

 On Wed, Dec 10, 2014 at 4:11 AM, Lennart Poettering
 lenn...@poettering.net wrote:
  In fact, I think we should drop the
  libcap dependency altogether and just do the two syscalls it offers to
  us natively in systemd code. Neither is libcap a particularly nice
  library, nor is the stuff it does particularly complex, hence we can
  as well wrap the two calls we need in our code.
 
 I started looking at this and I just sent a patch set to remove the
 include of sys/capability.h where it was not really in use.
 
 Regarding the valid uses of libcap, it looks like the non-trivial part
 is cap_to_text/cap_from_text which we would have to reimplement and
 possibly keep them in sync with libcap.

Yeah, this is indeed not the nicest code to hack up, but should be
quite doable still.

 libcap also tries to support kernels which only support 32-bit
 capabilities. If we replace that code, should we make an assumption of
 64-bit capabilities and just use a uint64_t to represent the bits?

I think 64bit caps have been standard since a lng time
already. AFAIK though the kernel/userspace API is built around arrays
of 64bit values currently though, to allow extension one day. This is
how we expose it in sd-bus for the message metadata caps currently,
maybe we should do it everywhere the same.

 Let me know if you think this is something worth doing and I can
 contribute an implementation.

Absolutely. Would love to drop the dep!

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] gpt-auto-generator: honor read-only attribute for native rootfs, post-initrd.

2015-02-03 Thread Dimitri John Ledkov

On 3 February 2015 at 15:50, Lennart Poettering lenn...@poettering.net wrote:
 On Mon, 29.12.14 14:33, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 Heya,

 Sorry for the late review, still busy keeping up with all the unmerged
 patches and unreplied mails that queued up...

 Is this issue still relevant?


I believe it is relevant, but I gave up working on it at the moment.

 Signed-off-by: Dimitri John Ledkov dimitri.j.led...@intel.com

 (We do not use S-o-b, we are not the kernel...)

  This is not yet really ready for application, as ultimately this is
  only solution for part of the problem.

  With this patch, post-initrd -.mount unit will have correct
  Options=rw if READ_ONLY flag is not set and ro/rw was not specified
  on the kernel cmdline. In the initrd the -.mount unit will continue
  to be mounted ro by default (honoring cmdline rw flag, but ignoring
  unset READ_ONLY flag).

  However, remount-fs only considers /etc/fstab and only remounts
  things with options as specified in the /etc/fstab. Thus the fact
  that -.mount unit changed Options=ro - Options=rw between
  initramfs and pivoted system does not result in the root filesystem
  getting remounted as rw.

 Hmm, what precisely is the issue again here? You are looking for a way
 to make the root disk writable when using gpt auto discovery after
 boot, without shipping an /etc/fstab that would result in remounting
 after boot? Why wouldn't specifying rw on the kernel cmdline suffice
 for that?

The issue is that without specifying neither ro nor rw on the
kernel command line (nor via any other configuration - e.g.
/etc/fstab, explicit mount unit etc.), the partition flags are not
honoured for the root partition by gpt-auto-generator and one ends up
with a ro mounted rootfs, instead of a rw one.

I guess at the very least we could document that from
http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/:

For the root, server data and home partitions the partition flag bit
60 (read-only) may be used to mark a partition for read-only mounts
only. If set the partition will be mounted read-only instead of
read-write.

Is not implemented for root partition by gpt-auto-generator, but only
for the server data  home partitions.

-- 
Regards,

Dimitri.

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] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

On Tue, 03.02.15 16:34, Serge Hallyn (serge.hal...@ubuntu.com) wrote:

   the UID/GID on entire filesystem sub-trees given to containers with
   userns is a real unpleasant thing to have to deal with. I'd not want
 
 Of course you would *not* want to take a stock rootfs where uid == 0
 and shift that into the container, as that would give root in the
 container a chance to write root-owned files on the host to leverage
 later in a convoluted attack :)  

Is this really a problem? I mean, the only way how this could be
exploitable is if people make the container hierarchy accessible to
other users, but that should be easy to prohibit by making the
container's parent dir 0700, which we already do for nspawn's
container in /var/lib/machines... The only other risk I can see here
is that if people use traditional ext4 quota, then the container's
disk usage will be added to the host's usage. But that's easy to
avoid, by simply never placing container images and the host on the
same quota device...

Also, in the case of systemd-nspawn we strongly emphasize usage with
loopback devices. In that case there's no vulnerability at all, since
the device is completely seperate from the host fs, and it will only
be mounted in the container, but not in the host...

 We might want to come up with a containers concensus that container
 rootfs's are always shipped with uid range 0-65535 - 10-165535.
 That still leaves a chance for container A (mapped to 20-265535)
 to write valid setuid-root binary for container B (mapped to
 30-365535), which isn't possible otherwise.  But that's better
 than doing so for host-root.

Well, ultimately I'd recommend an automatism like this for container
managers: 

   a) if not otherwise configured, let's give each container their own
  16bit of uids. This would mean each 32bit uid could be neatly
  split into the upper 16bit that would become a container id,
  plus the lower 16bit for the actual virtual UID.

   b) we will never set up UID ranges orthogonal from GID ranges.

   c) when a container image is started, the container manager first
  checks the UID/GID owner of the root of the root file system. It
  masks the lower 16bit away, and only looks for the upper 16bit.

   d) It will then look for an unused container id (which means, an
  unused range of 64K UIDs), and then shifts the offset it
  identified following c) to this new container id.

With that in place it doesn't really matter which base people use in
their containers, the container manager would do the right thing, and
shift everything into the right place. Paranoid people could ship
their container images shifted to some ID of their choice, and lazy
folks could just ship their container images with base 0, but then
must make sure they don't give anybody else access to the hierarchy,
and don't confuse quota...

   [1] Using a separate disk image per container means a container can't
   DOS other containers by exhausting inodes for example with $millions
   of small files.
  
  Indeed. I'd claim that without such a concept of mount point uid
  shifting the whole userns story is not very useful IRL...
 
 I had always thought this would eventually be done using a stackable
 filesystem, but doing it at bind mount time would be neat too, and
 less objectionable to the kernel folks.  (Though overlayfs is in now,
 so shrug)
 
 I'm actually quite surprised noone has sat down and written a
 stackable uid-shifting fs yet.

If it's done as part of bind mounts, or as an extension of overlayfs,
or in a completely new fs, doesn't really matter to me. I'd certainly
welcome a solution based on any of these options!

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] Avoid reloading services when shutting down

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

 Lennart Poettering [2015-02-03 17:29 +0100]:
  Hmm, why precisely does this stall for 90s? 
 
 The current transaction has final.target and all other jobs which need
 to be shut down. One of these now trigger systemctl reload
 postfix.service, but that reload isn't going to actually run in the
 same transaction but in the next one. OTOH systemctl reload
 waits for the reloading to finish, thus we have a deadlock.
 
  Isn't this a case where people should just use --no-block?
 
 Kind of. Not using this is the right thing while the machine is
 running, so that the reload is actually done after calling systemctl
 reload, and you can go on using postfix or whatever. --no-block should
 help during shutdown, or early boot (same principal bug, but slightly
 different patch, see http://bugs.debian.org/624599).
 
 So every time you call reload you'd have to check whether or not you
 are in early boot/during shutdown, or in the running system, and
 conditionally use --no-block. However, as such scripts should never
 call systemctl directly, but service foo reload (to work with other
 init systems or chroot), it would be also possible to move that check
 there, and conditionally add --no-block. It would just be another
 thing that every distro has to re-discover :-)

I am very strongly against adding hacky work-arounds like this to PID
1. The deadlocks are deadlocks, and implying --no-block if we are in
shutdown mode is a pretty drastic hack I think that special cases one
peculiar case way too much.

My recommendation would be to stick this into your /usr/bin/service
compat glue. Use the state string systemctl is-system-running
outputs to check if you are shutting down. If so, add --no-block to
the params you pass to systemctl.

Another option might be to pass --job-mode=ignore-dependencies instead
of --no-block, which was created for usecases like this, even though
it is frickin' ugly...

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] Avoid reloading services when shutting down

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

 Hey all,
 
 I'm currently reviewing our Debian patches for systemd, and came
 across this one which sounds important for other distributions, too.
 This was reported and fixed two years ago in
 https://bugs.debian.org/635777 which has all the details and logs, but
 the summary is:
 
 Distributions have quite a lot of run scripts in this .d/ directory
 if stuff happens; e. g. the ISC DHCP client has
 /etc/dhcp/dhclient-{enter,exit}-hooks.d/, Debian's ifupdown has
 /etc/network/if-{up,down}.d/, and of course init.d scripts themselves
 also occasionally call service foo reload and similar. It can happen
 that when requesting a shutdown, a script of the above kind reloads or
 restarts another service. In this case, postfix wants to reload itself
 after a network interface goes up or down; during runtime that works
 fine, but if it happens during shutdown, that systemctl reload
 postfix will cause the entire shutdown to stall for 90s (the default
 timeout).

Hmm, why precisely does this stall for 90s? 

Isn't this a case where people should just use --no-block?

Lennart

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

[systemd-devel] [PATCH] Avoid reloading services when shutting down

2015-02-03 Thread Martin Pitt

Hey all,

I'm currently reviewing our Debian patches for systemd, and came
across this one which sounds important for other distributions, too.
This was reported and fixed two years ago in
https://bugs.debian.org/635777 which has all the details and logs, but
the summary is:

Distributions have quite a lot of run scripts in this .d/ directory
if stuff happens; e. g. the ISC DHCP client has
/etc/dhcp/dhclient-{enter,exit}-hooks.d/, Debian's ifupdown has
/etc/network/if-{up,down}.d/, and of course init.d scripts themselves
also occasionally call service foo reload and similar. It can happen
that when requesting a shutdown, a script of the above kind reloads or
restarts another service. In this case, postfix wants to reload itself
after a network interface goes up or down; during runtime that works
fine, but if it happens during shutdown, that systemctl reload
postfix will cause the entire shutdown to stall for 90s (the default
timeout).

Michael Stapelberg wrote the attached patch which fixes this by
disallowing unit reloads/restarts when final.target is queued. This is
admittedly not very elegant as it hardcodes the final.target name
(and also, for upstream the comment should be adjusted of course), but
it does fix the issue. I can still reproduce the problem with 218 in a
VM.

Is this something which we can fix upstream in a more elegant manner?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From: Tollef Fog Heen tfh...@err.no
Date: Tue, 16 Oct 2012 18:39:27 +0200
Subject: Avoid reloading services when shutting down

Doing so won't work and makes no sense.  Thanks to Michael Stapelberg
for the patch.  Closes: #624599.
---
 src/core/manager.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/src/core/manager.c b/src/core/manager.c
index 6382400..acef626 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1147,6 +1147,8 @@ int manager_startup(Manager *m, FILE *serialization, FDSet *fds) {
 int manager_add_job(Manager *m, JobType type, Unit *unit, JobMode mode, bool override, sd_bus_error *e, Job **_ret) {
 int r;
 Transaction *tr;
+Job *j;
+Iterator i;
 
 assert(m);
 assert(type  _JOB_TYPE_MAX);
@@ -1156,6 +1158,29 @@ int manager_add_job(Manager *m, JobType type, Unit *unit, JobMode mode, bool ove
 if (mode == JOB_ISOLATE  type != JOB_START)
 return sd_bus_error_setf(e, SD_BUS_ERROR_INVALID_ARGS, Isolate is only valid for start.);
 
+if (type == JOB_RELOAD || type == JOB_RELOAD_OR_START || type == JOB_RESTART || type == JOB_TRY_RESTART) {
+HASHMAP_FOREACH(j, m-jobs, i) {
+assert(j-installed);
+
+/* If final.target is queued (happens on poweroff, reboot and
+ * halt), we will not accept new reload jobs. They would not be
+ * executed ever anyways (since the shutdown comes first), but
+ * they block the shutdown process: when systemd tries to stop
+ * a unit such as ifup@eth0.service, that unit might invoke a
+ * systemctl reload command, which blockingly waits (but only
+ * gets executed after all other queued units for the shutdown
+ * have been executed).
+ *
+ * See http://bugs.debian.org/624599 and
+ * http://bugs.debian.org/635777 */
+if (strcmp(j-unit-id, final.target) == 0) {
+log_debug(final.target is queued, ignoring %s request for unit %s, job_type_to_string(type), unit-id);
+sd_bus_error_setf(e, BUS_ERROR_SHUTTING_DOWN, final.target is queued, ignoring %s request for unit %s, job_type_to_string(type), unit-id);
+return -EINVAL;
+}
+}
+}
+
 if (mode == JOB_ISOLATE  !unit-allow_isolate)
 return sd_bus_error_setf(e, BUS_ERROR_NO_ISOLATION, Operation refused, unit may not be isolated.);
 


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] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

2015-02-03 Thread Serge Hallyn

Quoting Lennart Poettering (lenn...@poettering.net):
 On Tue, 03.02.15 15:03, Daniel P. Berrange (berra...@redhat.com) wrote:
 
   Hmm, so, I thought a lot about this in the past weeks. I think the way
   I'd really like to see this work in the end is that we never have to
   persist the UID mappings. This could work if the kernel would provide
   us with the ability to bind mount a file system into the container
   applying a fixed UID shift. That way, the shifted UIDs would never hit
   the actual disk, and hence we wouldn't have to persist their mappings.
   
   Instead on each container startup we'd look for a new UID range, and
   release it entirely when the container shuts down. The bind mount with
   UID shift would then shift the UIDs up, the userns stuff would shift
   it down from inside the container again.
   
   Of course, this all depends on whether the kernel will get an
   extension to apply uid shifts to bind mounts. I hear they want to
   provide this, but let's see.
  
  I would dearly love to see that happen. Having to recursively change

It'd definately be useful (though not without issues).

  the UID/GID on entire filesystem sub-trees given to containers with
  userns is a real unpleasant thing to have to deal with. I'd not want

Of course you would *not* want to take a stock rootfs where uid == 0
and shift that into the container, as that would give root in the
container a chance to write root-owned files on the host to leverage
later in a convoluted attack :)  We might want to come up with a
containers concensus that container rootfs's are always shipped with
uid range 0-65535 - 10-165535.  That still leaves a chance for
container A (mapped to 20-265535) to write valid setuid-root
binary for container B (mapped to 30-365535), which isn't possible
otherwise.  But that's better than doing so for host-root.

  the filesystem UID shift to only apply to bind mounts though. It is
  not uncommon to use a disk image[1] for a container's filesystem, so
  being able to request a UID shift on *any* filesystem mount is pretty
  desirable, rather than having to mount the image and then bind mount
  it onto itself just to apply the UID shift.
 
 Well, you can always change the bind mount flags without creating a
 new bind mount with MS_BIND|MS_REMOUNT.
 
  [1] Using a separate disk image per container means a container can't
  DOS other containers by exhausting inodes for example with $millions
  of small files.
 
 Indeed. I'd claim that without such a concept of mount point uid
 shifting the whole userns story is not very useful IRL...

I had always thought this would eventually be done using a stackable
filesystem, but doing it at bind mount time would be neat too, and
less objectionable to the kernel folks.  (Though overlayfs is in now,
so shrug)

I'm actually quite surprised noone has sat down and written a
stackable uid-shifting fs yet.

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

Re: [systemd-devel] logind, su - sessions and initscripts compatibility

On Thu, 18.12.14 11:05, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 As far as I know, systemd still officially retains compatibility with
 initscripts. Unfortunately, session management now at least partially
 broke it.
 
 Any initscript that is using su - would create logind session; this
 session will persist until processes started by initscript are
 runing.

Any initscript that uses su - is broken I am very much
convinced. For two reasons. First of all, the dash means that you want
a login shell, i.e. one that feels like a real user login. That's
very inappropriate for daemons.

Secondly, su goes through the whole PAM stack. PAM is really for
setting up user sessions, it has no place when setting up the
environment for a daemon. If you want to set up the environment for a
daemon, use start-stop-daemon, runuser, or simply systemd's User=
setting. None of them goes through PAM.

If you go through PAM, then you not only get a new systemd session
opened for it, but also an audit session, selinux session, ... And you
clearly don't want that.

This is unfortunately little documented, but it's really how it is. 

Do not use su for init scripts. Never, ever. It's a user command,
not a command to use in codepaths outside of user sessions.

All this is wrong outside of the systemd context, and just a slightly
bit more inside the systemd context, but the correct fix is certainly
outside of the scope of systemd.

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] slow systemd-networkd DHCP client on wlan0 with systemd v217

On Tue, 03.02.15 18:20, Patrik Flykt (patrik.fl...@linux.intel.com) wrote:

 On Tue, 2015-02-03 at 11:46 +0100, Lennart Poettering wrote:
  On Mon, 02.02.15 23:12, Charles Devereaux (syst...@guylhem.net) wrote:
  
   Another problem with systemd-networkd is that the lease is not renewed
   after sleep.
   
   This is a basic feature, a laptop is frequently physicially moved, which
   means another DHCP lease should be acquired, but I don't see how to
   do that.
  
  Hmm, I figure all DHCP leases should be refreshed when we come back
  from suspend. Hooking that up should be pretty easy. Added to the TODO
  list.
  
  That said, isn't the link beat lost anyway during suspend, and thus we
  should refresh automatically, anyway? 
  
  Either way refreshing on resume can't hurt...
 
 Is the resume event detected somehow in systemd? 

The kernel unfortunately provides no API for this right now. However,
if logind is the one suspending the machine, then it sends out a
PrepareForSleep() signal before doing so. systemd-resolved already
hooks into that:

http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684

Tom mentioned he's already looking into adding similar code to
networkd to handle this properly.

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] Added UFD (Uplink failure detection) support to networkd

On Tue, 03.02.15 13:03, Rauta, Alin (alin.ra...@intel.com) wrote:

 Hi Lennart,
 
 I agree that BindCarrier= should suffice.

Perfect!

I have added this to the TODO list now, and of course we'd be
happy to take a 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] Questions regarding dbus started via systemd --user

2015-02-03 Thread Simon McVittie


On 03/02/15 12:08, Lennart Poettering wrote:

Do you need more than systemctl import DISPLAY?


That's the main one, but for it to not be a regression on current 
general-purpose distributions, the equivalent of `systemctl 
import-environment` needs to upload into the dbus-daemon too (so that 
D-Bus-activated, non-systemd services will get the variables), and there 
are a bunch of other variables set in /etc/X11/Xsession.d or equivalent 
that should also be uploaded if present.


--
Simon McVittie
Collabora Ltd. http://www.collabora.com/

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

Re: [systemd-devel] User sessions, session buses, user buses

2015-02-03 Thread Simon McVittie

On 03/02/15 10:16, Stef Bon wrote:
 I've never understood why the session bus is started through dbus-launch.

If we move from a per-login-session to a per-user-session bus, then it
won't be; dbus-launch will become solely for the people who run twm
under xdm or something, but who still want to run (say) Firefox.

 Leave it to the login manager (not PAM), or provide the socket and
 activate the session bus only when
 some app is connecting to it, which can be a graphical session, but
 may be also a console.

That is what I plan to do.

S


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

Re: [systemd-devel] [PATCH v2] bootchart: ship a configuration that will boot without sysvinit compat

On Tue, 06.01.15 19:05, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Sun, Dec 28, 2014 at 07:18:16PM +0100, Gabriel de Perthuis wrote:
  Change the default through /etc/systemd/bootchart.conf.
  Keep the /sbin/init default in the source code, in case
  some users rely on that.
 No, as a rule, all files in /etc installed by systemd can only
 contain comments. Boot-with-empty-/etc would be broken otherwise.
 
  bootchart defaults to chaining to /sbin/init, which is sensible,
  but in a pure systemd environment (without systemd-sysvinit)
  will make the machine unbootable.
 bootchart is a part of systemd, so if it makes sense for us to
 use /usr/lib/systemd/systemd, than we should just change the source
 code to do it.

This has now been implemented in this patch:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=6e1bf7ab998e30b23202192b5b47c119e7a3697d

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 v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

On Tue, Feb 03, 2015 at 01:34:23PM +0100, Lennart Poettering wrote:
 On Thu, 29.01.15 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
  On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote:
   On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl mbi...@gmail.com wrote:
Updated patch which the correct version information.
   
   Applied.
 
  Hm, I think this was an unintentional ABI break. udev_queue_flush @@ 
  LIBUDEV_183
  was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker cannot 
  know
  that this is the same symbol.
 
 Hmm can you elaborate on this? I missing the context? Is there
 something to fix here?
For two releases systemd had a symbol, which then got removed.
Anyone compiling during that time and using it, would get a crashing
binary after installing systemd from the latest version.

Although this happened a while ago and nobody complained suggests
that there were few users, and any there were got recompiled anyway.

My reason for mentioning this is:
- to raise the problem should a similar situation come up again
- to ask whether we can fix it anyway. Can we add udev_queue_flush @@ 
LIBUDEV_183
  back, without removing udev_queue_flush @@ LIBUDEV_215?

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

Re: [systemd-devel] [PATCH v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

On Thu, 29.01.15 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote:
  On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl mbi...@gmail.com wrote:
   Updated patch which the correct version information.
  
  Applied.

 Hm, I think this was an unintentional ABI break. udev_queue_flush @@ 
 LIBUDEV_183
 was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker cannot know
 that this is the same symbol.

Hmm can you elaborate on this? I missing the context? Is there
something to fix here?

Lennart

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

Re: [systemd-devel] [PATCH] loopback setup in unprivileged containers

On Mon, 29.12.14 15:14, Tom Gundersen (t...@jklm.no) wrote:

 On Mon, Dec 29, 2014 at 2:34 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Mon, 29.12.14 09:07, Matthias Urlichs (matth...@urlichs.de) wrote:
 
   On Sun, Dec 28, 2014 at 6:18 PM, Stéphane Graber
   stephane.gra...@canonical.com wrote:
My host system doesn't have nspawn so I can't easily test it this way,
but it was my understanding that nspawn didn't support user namespaces
and uid/gid mappings which is what I'm working with here.
  
   Indeed, that is not supported by nspawn (which explains why I cannot
   reproduce). I was able to reproduce using the userns_child_exec test
   program from [0], so I'll take a look.
  
  Hmm. IMHO it would be reasonable to add a mapping option
  (--{user,group}map=inside:outside[:length]) to nspawn.
 
  I am open to adding support for this, but I think the allocation of
  the UID ranges should really happen automatically, and not be
  something the admin has to manually assign.
 
  Which means we'd enter dynamic UID allocation terroritory, and that
  opens a huge can of worms...
 
 Would we not also need to support explicit assignment, in case someone
 has a preexisting image they want to match in a specific way? In that
 case we could start off without the dynamic allocation and add that
 later. It certainly would make testing a lot simpler if we had userns
 support sooner rather than later (at least in the case of netlink it
 appears to be quite a mess).

Yeah, I think we could add --uids= or so, which either takes a single
UID (which would use 65536 UIDs from that point), a UID range, or the
word auto. In that case we'd determine the start UID value from the
container's root directory owner. 

I think in the long run useful user namespacing support would only be
supported if the kernel would get a way how to bind mount a directory
tree with an UID shift. This could either be part of bind mounts, or
part of overlayfs or whatever else, but only with that in place
automatic userns would be fun, because it would not require patching
all uid/gids of all files in a container tree anymore...

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] Questions regarding dbus started via systemd --user

On Tue, 03.02.15 11:52, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

 On 02/02/15 22:47, Lennart Poettering wrote:
 Well, I mean, we only ever put this altogether for kdbus, where
 systemd itself is the one setting up the bus. But yeah, if you want to
 make this all work with dbus-daemon, then you would have to teach it
 bus activation support. Most likely that should be really easy, and
 just involves also installing a dbus.socket and dbus.service into the
 user unit dir.
 
 It is this easy, and I do think dbus should support this model, as I
 outlined in a longer mail on Friday.
 https://bugs.freedesktop.org/show_bug.cgi?id=61301 (reviews welcome).
 
 The harder part is getting environment variables pushed around, for which I
 don't have a complete patch yet (but I'm going to work on that within the
 next couple of weeks).

Do you need more than systemctl import DISPLAY?

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] Added UFD (Uplink failure detection) support to networkd

2015-02-03 Thread Rauta, Alin

Hi Lennart,

I agree that BindCarrier= should suffice.

Best Regards,
Alin

-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net] 
Sent: Tuesday, February 3, 2015 10:50 AM
To: Rauta, Alin
Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List
Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) 
support to networkd

On Tue, 03.02.15 09:05, Rauta, Alin (alin.ra...@intel.com) wrote:

 Yes, since the concept of UFD group is not exposed.

Does this mean we have agreement that the simply BindCarrier= option I proposed 
would be sufficient for your usecases? That would be great!

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] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux

2015-02-03 Thread poma

On 02.02.2015 19:58, David Herrmann wrote:
 Hi
 
 On Sun, Feb 1, 2015 at 10:50 AM, poma pomidorabelis...@gmail.com wrote:
 MiracleCast - Howto
 Current State
 
 [snip]
 
 Can folks from the NetworkManager team  systemd-networkd team answer 
 regarding the current status in this matter?
 
 As people continuously ask me about this, I'll just try to answer it
 on the public ML:
 
 To make Miracast work, we need access to a Wifi P2P API. The kernel
 implements Wifi P2P and wpa_supplicant provides access to it via it's
 ctrl-interface (and I think recently even gained a dbus API). In
 MiracleCast I wrote a miracle-wifid daemon that wraps wpa_supplicant
 and provides P2P to MircaleCast. However, this does not work well in
 parallel to NetworkManager/wicd/connman/... running. You really cannot
 run wpa_supplicant multiple times on the same interface. Hence,
 MiracleCast development is currently stalled until the different
 network-managers provide a P2P API.
 

Are you for to make the request for improvement towards NetworkManager?

 Intel recently added such an API to ConnMan and provides a WFD
 implementation on its own [1]. I highly recommend looking into it.
 It's now up to NetworkManager to catch up. systemd-networkd doesn't do
 L2 setup, so it's not really related. wicd is kinda dead [2], so I
 doubt they'll come up with something.
 
 Furthermore, P2P support is pretty limited right now. Officially,
 almost all recent devices support it, but it's particularly annoying
 to set it up, due to major bugs across all the stacks (in no way
 limited to linux drivers). I mean, 3 of 4 of my connection attempts
 between Android and Windows devices fails.. not even talking about my
 wpa_supplicant hacks.
 

Thank you for your comprehensive explanation!

 As I'm not really interested in hacking on network-managers, I've
 decided to stop working on MiracleCast. If, some day, there's a
 working P2P stack on linux, I might resurrect it. But it sounds more
 likely that I'll refer to the Intel solution (WYSIWIDI) instead.
 There're also gstreamer plugins for WFD now, so maybe give them a try?
 

gst-rtsp-server-wfd
https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md

Pre-conditions:

This module is running on established p2p connection with wifi direct, which 
means that you have to setup this network environment to run this module. I 
hope this link would be very helpful. ( 
http://cgit.freedesktop.org/~dvdhrm/miracle )

You are referring to them, they are referring to you. :)

 Thanks
 David
 
 [1] https://github.com/01org/wysiwidi
 [2] https://answers.launchpad.net/wicd/+question/227789
 

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

Re: [systemd-devel] pam_limits: Could not set limit for ...: Operation not permitted

On Mon, 15.12.14 22:42, Kai Krakow (hurikha...@gmail.com) wrote:

 Hello!
 
 I'm seeing the following errors in systemd's journal:
 
 Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): 
 Could not set limit for 'memlock': Operation not permitted
 Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): 
 Could not set limit for 'nice': Operation not permitted
 Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): 
 Could not set limit for 'rtprio': Operation not permitted
 Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message() failed: 
 Operation not permitted
 Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning 
 /usr/lib/systemd/systemd: Operation not permitted
 
 Is it meaningless? Do I have to worry? Or which configuration do I miss?

Hmm, this is certainly weird. It indicates some issue with your PAM
setup maybe? Do you have SELinux enabled? Is this in some container or so?

Lennart

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

Re: [systemd-devel] [PATCH v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

2015-02-03 15:18 GMT+01:00 Kay Sievers k...@vrfy.org:
 On Tue, Feb 3, 2015 at 3:09 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
 On Tue, Feb 03, 2015 at 01:34:23PM +0100, Lennart Poettering wrote:
 On Thu, 29.01.15 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
 wrote:

  On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote:
   On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl mbi...@gmail.com wrote:
Updated patch which the correct version information.
  
   Applied.
 
  Hm, I think this was an unintentional ABI break. udev_queue_flush @@ 
  LIBUDEV_183
  was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker cannot 
  know
  that this is the same symbol.

 Hmm can you elaborate on this? I missing the context? Is there
 something to fix here?
 For two releases systemd had a symbol, which then got removed.
 Anyone compiling during that time and using it, would get a crashing
 binary after installing systemd from the latest version.

 Although this happened a while ago and nobody complained suggests
 that there were few users, and any there were got recompiled anyway.

 There should be no external users of these symbols, they were just
 exported for consistency.


http://codesearch.debian.net/results/udev_queue_flush
confirms that there are no external users.

If there are only for internal use, maybe we should consider hiding them.

-- 
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] test-dhcp-client failing in mock builds

2015-02-03 Thread Tom Gundersen

On Tue, Feb 3, 2015 at 5:08 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Feb 03, 2015 at 06:49:21AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Tue, Feb 03, 2015 at 02:42:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
  On Mon, Feb 02, 2015 at 08:30:43AM +0100, Jan Synacek wrote:
   http://lists.freedesktop.org/archives/systemd-devel/2014-December/026190.html
  
   I haven't got time to properly analyze the problem since then...
  It sounded familiar ;)
 
 
  On Mon, Feb 02, 2015 at 01:36:29PM +0200, Patrik Flykt wrote:
   Operation not permitted is what is printed for EPERM. But EPERM is not
   present in the client code itself, so I'm inclined towards a permission
   problem somewhere when running mock.
  EPERM is also returned when using /dev/null in epoll_ctl_add.
  I think I fixed it now.
 
  Which leads to a failure on arm in test-network:
  FAIL: test-network
  ==
  Assertion '!address_equal(a1, a2)' failed at 
  ../src/network/test-network.c:161, function test_address_equality(). 
  Aborting.
 
  I got out my chromebook to see what going on here.
 Ha, undefined behaviour on right shift. Gotta love C ;)

 So the tests pass in mock on all three primary arches.

 I'll let it spin on arm64 just to see what comes up.
 And that passes too.


Great stuff! Thanks!

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

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

On Tue, 16.12.14 08:45, David Herrmann (dh.herrm...@gmail.com) wrote:

 Hi
 
 On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams d...@redhat.com wrote:
  On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
  systemd tries to launch logind service which now waits for services it
  is ordered After and eventually times out.
 
  NM patch filed for review by NM dev team:
 
  https://bugzilla.gnome.org/show_bug.cgi?id=741572
 
 Thanks a lot!
 
  Also, I don't think logind should fail if there is no network; no reason
  for it to crash and burn just because everything isn't quite ready
  when

It doesn't crash and burn. If you talk to logind before its
dependencies are fulfilled, and you do so synchronously, the method
call will simply block until logind is up. There are two ways out
here: a) not triggering activation by marking this in the bus message,
or b) doing the method call asynchronously, rather than synchronously.

Fix a) seems to be the right one here, since you'd really create a
deadlock here otherwise. And I see that this is how you fixed it, so
all is great.

  it starts.  I presume it's got capability to deal with sporadic network
  outages, and that's not really different than waiting for networking to
  show up soon after it starts.  But not my department...
 
 When a user loggs in, we resolve the name to UID. As the initial
 logind binary was only used for login management, it was reasonable to
 avoid starting up before the nss-user-lookup is initialized. Now that
 systemd-logind provides other independent APIs, it might be ok to drop
 that requirement again.
 If the nss user lookup is not ready at the time someone logs in, we
 will print a warning and skip tracking that session. Sounds fine to
 me, but Lennart might have more comments.

I am pretty sure we shouldn't allow user logins before the user
database is fully accessible. If a user los in, he should see correct
information about other users in ls -l output, and so on.

It's OK to allow root to login earlier (and we do, via sulogin and
stuff), but normal users during normal operation should not be allowed
to do that.

I am pretty sure we should leave the existing ordering as is.

Lennart

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

Re: [systemd-devel] DefaultDependencies=false on scopes

On Mon, 15.12.14 17:44, Brandon Philips (bran...@ifup.co) wrote:

 Hello-
 
 How is a user supposed to disable DefaultDependencies on a scope? From
 the docs it seems like it should work:
 
 Unless DefaultDependencies=false is used, scope units will implicitly
 have dependencies of type Conflicts= and Before= on
 shutdown.target.

Well, currenlty not all our props are exposed for transient units
yet. Many are, but we were too lazy to add them all. If you need more
properties, then let me know, and we can add them.

I have added DefaultDependencies= for you now:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=261420ba2a20305ad271b6f5f380aa74c5c9dd50

 But, in practice:
 
 systemd-run --scope --property=DefaultDependencies=false /usr/bin/sleep 
 5
 Unknown assignment DefaultDependencies=false.
 Failed to create message: Invalid argument

This works now.

Lennart

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

Re: [systemd-devel] DefaultDependencies=false on scopes

2015-02-03 Thread Brandon Philips

On Tue, Feb 3, 2015 at 10:20 AM, Lennart Poettering
lenn...@poettering.net wrote:
 I have added DefaultDependencies= for you now:

 http://cgit.freedesktop.org/systemd/systemd/commit/?id=261420ba2a20305ad271b6f5f380aa74c5c9dd50

Thank you. I will work on getting Docker fixed up to fix this annoying behavior.

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

Re: [systemd-devel] Execute custom command whenever network interface appears

On Sun, 14.12.14 11:50, DimanNe (dima...@ya.ru) wrote:

 Hello,

 I read manual about systemd-networkd module
 (http://www.freedesktop.org/software/systemd/man/systemd.network.html),
 and as far as I know, I can do only basic actions (like run dhcp, or
 assign static addresses/mac/routes and so on), but in general I want
 to run some script or command.
 
 Here is real world example - 
 https://wiki.archlinux.org/index.php/ZTE_MF_823_(Megafon_M100-3)_4G_Modem
 If you are using usb modem, you should
 1) run dhcp
 2) run curl/wget with special url
 
 so, my question, it it possible just now (how?)? If not, what is the best 
 approach to accomplish described above task?

No, this is currently not supported, and it is unlikely that we ever
will. In general we are not really convinced that doing callouts from
lower layers into higher layers of the stack is something to support.

If you want to do something like this make the higher stack subscribe
to changes from the lower stack. In scripts you can use
systemd-networkd-wait-online for that, to a certain level...

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 v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

On Tue, Feb 03, 2015 at 07:29:06PM +0100, Michael Biebl wrote:
 2015-02-03 15:18 GMT+01:00 Kay Sievers k...@vrfy.org:
  On Tue, Feb 3, 2015 at 3:09 PM, Zbigniew Jędrzejewski-Szmek
  zbys...@in.waw.pl wrote:
  On Tue, Feb 03, 2015 at 01:34:23PM +0100, Lennart Poettering wrote:
  On Thu, 29.01.15 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
  wrote:
 
   On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote:
On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl mbi...@gmail.com 
wrote:
 Updated patch which the correct version information.
   
Applied.
  
   Hm, I think this was an unintentional ABI break. udev_queue_flush @@ 
   LIBUDEV_183
   was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker 
   cannot know
   that this is the same symbol.
 
  Hmm can you elaborate on this? I missing the context? Is there
  something to fix here?
  For two releases systemd had a symbol, which then got removed.
  Anyone compiling during that time and using it, would get a crashing
  binary after installing systemd from the latest version.
 
  Although this happened a while ago and nobody complained suggests
  that there were few users, and any there were got recompiled anyway.
 
  There should be no external users of these symbols, they were just
  exported for consistency.
 
 
 http://codesearch.debian.net/results/udev_queue_flush
 confirms that there are no external users.
 
 If there are only for internal use, maybe we should consider hiding them.
Please don't. Once they're public, they're public. We can consider doing that
when bumping so version for another reason.

Zbyszek

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

[systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured

2015-02-03 Thread Keller, Jacob E

Hey,

I've recently been using systemd-networkd to great success on a few of
my machines here. However I ran into an interesting problem on at least
2 machines so far. I've included the output of journal for
systemd-networkd with Environment=SYSTEMD_LOG_LEVEL=debug as was
suggested on another post. In addition the only network file I have
configured is em0.network which contains the following,

$cat /etc/systemd/network/em0.network
[Match]
Name=em0

[Network]
DHCP=Yes

The journalctl for systemd-networkd after bootup is,

-- Logs begin at Mon 2012-12-31 20:02:09 PST, end at Tue 2015-02-03 10:57:09 
PST. --
Feb 03 10:37:44 jekeller-copperpass systemd-networkd[1055]: timestamp of 
'/etc/systemd/network' changed
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
flags change: +MULTICAST +BROADCAST
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
link 7 added
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
udev initialized link
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
saved original MTU: 1500
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
flags change: +MULTICAST +BROADCAST
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
link 8 added
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
udev initialized link
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
saved original MTU: 1500
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.DBus 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello 
cookie=1 reply_cookie=0 error=n/a
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
MAC address: 7e:5e:7c:31:44:4d
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
MAC address: b6:ec:a9:4b:e5:42
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
getting address failed: Device or resource busy
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
link state is up-to-date
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
unmanaged
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message 
type=method_return sender=org.freedesktop.DBus destination=:1.7 object=n/a 
interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message 
type=signal sender=org.freedesktop.DBus destination=:1.7 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired 
cookie=2 reply_cookie=0 error=n/a
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
link state is up-to-date
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
unmanaged
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
address for a nonexistent link (1), ignoring
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
address for a nonexistent link (1), ignoring
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
flags change: +MULTICAST +BROADCAST
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
link 9 added
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
udev initialized link
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
saved original MTU: 1500
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
link state is up-to-date
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
unmanaged
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
address for a nonexistent link (1), ignoring
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
address for a nonexistent link (1), ignoring
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
flags change: +MULTICAST +BROADCAST
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
link 10 added
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
udev initialized link
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
saved original MTU: 1500
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
MAC address: 52:54:00:84:d2:d5
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
link state is up-to-date
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
unmanaged
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
address for a nonexistent link (1), ignoring
Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
address for a

Re: [systemd-devel] [PATCH v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

2015-02-03 19:52 GMT+01:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 On Tue, Feb 03, 2015 at 07:29:06PM +0100, Michael Biebl wrote:
 If there are only for internal use, maybe we should consider hiding them.
 Please don't. Once they're public, they're public. We can consider doing that
 when bumping so version for another reason.

You're right, of course.


-- 
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] slow systemd-networkd DHCP client on wlan0 with systemd v217

On Tue, 03.02.15 14:15, Charles Devereaux (syst...@guylhem.net) wrote:

 My current solution with dhcpcd is a sleep service sending signals to
 dhcpcd (give back the lease/reclaim it), something which could be extended
 to systemd-networkd, with other signals for other meanings that you may not
 want by default, like:
  - removing the configuration it did (which is currently kept when
 systemd-networkd is stopped, which could be useful in some scenarios to
 avoid asking an additional IP address every time)
  - starting or stopping the DHCP servers services (which once started keep
 running)
 
 Even if systemd-networkd does not support a fine grained logic as I
 regretted in another message about br0, this would at least support most of
 the basic scenarios many people will need.

I am pretty sure signals are not a particularly good interface for
this. We should add a proper bus API for this one day, but this kinda
has to wait until kdbus is a done deal, since networkd runs in early
boot, and dbus-daemon is not available in early boot.

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] Container, private network and socket activation

2015-02-03 Thread Mikhail Morfikov

 Also note that using socket activation for cotnainers means that
 systemd instance inside the container also needs to have configuration
 for the socket, to pass it on to the service that ultimately shall
 answer for it. Are you sure that apache2 has support for that, and
 that you set it up?

Actually, I just want to start the container when someone else tries to
connect to the port 80 of the host, just using the container's IP
address. So, for instance, my host has IP 192.168.1.150, the container
has IP 192.168.10.10 , and I want to type the second address in a web
browser so the system in the container could boot and start apache.
Then I could browse the page that is hosted by the apache server inside
of the container. I'm not sure if that's even possible, but apache
inside of the container starts at boot automatically, so I think there's
no need for setting anything in the container -- please correct me if
I'm wrong.


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

Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down

2015-02-03 20:36 GMT+01:00 Martin Pitt martin.p...@ubuntu.com:
 Lennart Poettering [2015-02-03 18:10 +0100]:
 I am very strongly against adding hacky work-arounds like this to PID

 Yeah, indeed. This is why I asked for a more elegant approach, and
 indeed the --no-block or --job-mode=ignore-dependencies sound like
 slightly better approaches to this. I'll test these more thoroughly
 tomorrow, thanks for pointing out!

The current patch we ship in Debian is admittedly not the nicest one,
but it solves a very real issue which affects a lot of non-trivial
setups.

 1. The deadlocks are deadlocks, and implying --no-block if we are in
 shutdown mode is a pretty drastic hack I think that special cases one
 peculiar case way too much.

 Right, the problem is of course more generic. Any set of jobs (i. e. a
 transaction) which causes (maybe through some indirection) one of its
 job members to get restarted/reloaded will suffer from this deadlock
 problem, AFAIUI. Booting and shutdown are therefore mostly affected by
 this as pretty much every other time there the pending transactions
 are only very small.

 My recommendation would be to stick this into your /usr/bin/service
 compat glue. Use the state string systemctl is-system-running
 outputs to check if you are shutting down. If so, add --no-block to
 the params you pass to systemctl.

 That actually sounds like just what's needed here. is-system-running
 will also neatly cover the corresponding case on bootup.

 Another option might be to pass --job-mode=ignore-dependencies instead
 of --no-block, which was created for usecases like this, even though
 it is frickin' ugly...

 For reload that should be fairly okay, as reload will quickly fail if
 the unit isn't actually running, and if it is running its dependencies
 already ought to be satisfied.

 I'll look into both, thanks for the hints!

Keep in mind though, that you'll need to not only update service,
but also invoke-rc.d and the lsb-hook, which is used when someone
calls /etc/init.d/foo directly.

It's also magnitudes less efficient to spawn external binaries to get
the system state then doing this check from within systemd itself.

So I'm not really convinced that shifting the responsibility here to
the scripts themselves is the better approach.


Michael


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

Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217

2015-02-03 Thread Charles Devereaux

On Tue, Feb 3, 2015 at 2:29 PM, Lennart Poettering lenn...@poettering.net
wrote:

 I am pretty sure signals are not a particularly good interface for
 this. We should add a proper bus API for this one day, but this kinda
 has to wait until kdbus is a done deal, since networkd runs in early
 boot, and dbus-daemon is not available in early boot.


Which would be a good usecase for signals (until kdbus happens, which might
take some time)

In an ideal world, kdbus will be the perfect solution, but at the moment,
the few signals mentioned would immediately solve some serious limitations
of systemd-networkd.

Also, in the future, having 2 ways to do the same thing might be a good
thing, especially for something as important as networking (ex: in case
some distribution do not want to use kdbus, or waits a while to implement
it, and in the meantime has to use weird hack. signals could lessen the
pain)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a way to limit restarts?

On Wed, 10.12.14 09:41, Ivan Shapovalov (intelfx...@gmail.com) wrote:

 On Tuesday 09 December 2014 at 13:11:41, Nekrasov, Alexander wrote:   
  Totally missed those. Thanks. Will OnFailure= be activated when the limit 
  is hit? The manual only directly describes StartLimitAction= which isn’t 
  exactly what’s required
 
 OnFailure= will be activated each time the unit enters failed state, i. e.
 at the same time it is restarted.
 
 There is apparently no way to start a special unit when the start limit is 
 reached.
 However, I may have missed it as well...

Hmm, we should either change bbehaviour of OnFailure, to only trigger
after the star limit is hit, or introduce some option to make this
configurable I guess.

Also see:

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

Lennart

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

[systemd-devel] Open-Source Miracast - Wifi-Display on linux

2015-02-03 Thread Jussi Kukkonen

Hi,

This should be a reply to Davids message on Feb 2 but I'm not a
subscriber and just happened to see this on the web archive... I
apologize for the relative off-topicness and suggest that any followup
questions be sent to wysiwidi mailing list:
https://lists.01.org/mailman/listinfo/wysiwidi-dev.

David Herrmann wrote:
 As people continuously ask me about this, I'll just try to answer it
 on the public ML:

 To make Miracast work, we need access to a Wifi P2P API. The kernel
 implements Wifi P2P and wpa_supplicant provides access to it via it's
 ctrl-interface (and I think recently even gained a dbus API). In
 MiracleCast I wrote a miracle-wifid daemon that wraps wpa_supplicant
 and provides P2P to MircaleCast. However, this does not work well in
 parallel to NetworkManager/wicd/connman/... running. You really cannot
 run wpa_supplicant multiple times on the same interface. Hence,
 MiracleCast development is currently stalled until the different
 network-managers provide a P2P API.

 Intel recently added such an API to ConnMan and provides a WFD
 implementation on its own [1]. I highly recommend looking into it.
 It's now up to NetworkManager to catch up. systemd-networkd doesn't do
 L2 setup, so it's not really related. wicd is kinda dead [2], so I
 doubt they'll come up with something.

I'm one of the people working on this new implementation (Wysiwidi).
We haven't made much noise yet as we didn't have a whole lot of
demonstrably working code to show -- but that has changed in the last
month or so and the project may well be worth a look now.

I'll try to get a blog post with more details up Any Day Now but in
short: The test sink included in Wysiwidi currently works with an
Android source. It doesn't look pretty yet, you may hit GStreamer
problems and the latency is higher than it should be, but 95% of the
time it works every time.

As far as Wifi P2P goes, the parts required by a Miracast
implementation now work quite reliably with newish Intel wifi hardware
(e.g. 7260) using _very_ recent Connman and wpa_supplicant.

 Furthermore, P2P support is pretty limited right now. Officially,
 almost all recent devices support it, but it's particularly annoying
 to set it up, due to major bugs across all the stacks (in no way
 limited to linux drivers). I mean, 3 of 4 of my connection attempts
 between Android and Windows devices fails.. not even talking about my
 wpa_supplicant hacks.

This. I've previously worked on DLNA (notorious for interoperability
problems) and frankly Miracast seems worse. The good news is that
after two months of bug fixes wpa_supplicant and connman actually do a
pretty good job -- but again, all testing has been done on Intel
hardware: YMMV.

My quick IOP test results are here
https://github.com/01org/wysiwidi/wiki/Interoperability. It's still
pretty red  -- but note that in December it was red all over.


Thanks,
  Jussi

 As I'm not really interested in hacking on network-managers, I've
 decided to stop working on MiracleCast. If, some day, there's a
 working P2P stack on linux, I might resurrect it. But it sounds more
 likely that I'll refer to the Intel solution (WYSIWIDI) instead.
 There're also gstreamer plugins for WFD now, so maybe give them a try?

 Thanks
 David

 [1] https://github.com/01org/wysiwidi
 [2] https://answers.launchpad.net/wicd/+question/227789
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217

2015-02-03 Thread Charles Devereaux

My current solution with dhcpcd is a sleep service sending signals to
dhcpcd (give back the lease/reclaim it), something which could be extended
to systemd-networkd, with other signals for other meanings that you may not
want by default, like:
 - removing the configuration it did (which is currently kept when
systemd-networkd is stopped, which could be useful in some scenarios to
avoid asking an additional IP address every time)
 - starting or stopping the DHCP servers services (which once started keep
running)

Even if systemd-networkd does not support a fine grained logic as I
regretted in another message about br0, this would at least support most of
the basic scenarios many people will need.

$ cat /dhcpcd-sleep.service
[Unit]
Description=DHCP client sleep hook
Before=sleep.target
ConditionVirtualization=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/killall -USR1 dhcpcd
ExecStop=/usr/bin/killall -SIGALRM dhcpcd

[Install]
WantedBy=sleep.target



On Tue, Feb 3, 2015 at 11:27 AM, Lennart Poettering lenn...@poettering.net
wrote:

 On Tue, 03.02.15 18:20, Patrik Flykt (patrik.fl...@linux.intel.com) wrote:

  On Tue, 2015-02-03 at 11:46 +0100, Lennart Poettering wrote:
   On Mon, 02.02.15 23:12, Charles Devereaux (syst...@guylhem.net) wrote:
  
Another problem with systemd-networkd is that the lease is not
 renewed
after sleep.
   
This is a basic feature, a laptop is frequently physicially moved,
 which
means another DHCP lease should be acquired, but I don't see how to
do that.
  
   Hmm, I figure all DHCP leases should be refreshed when we come back
   from suspend. Hooking that up should be pretty easy. Added to the TODO
   list.
  
   That said, isn't the link beat lost anyway during suspend, and thus we
   should refresh automatically, anyway?
  
   Either way refreshing on resume can't hurt...
 
  Is the resume event detected somehow in systemd?

 The kernel unfortunately provides no API for this right now. However,
 if logind is the one suspending the machine, then it sends out a
 PrepareForSleep() signal before doing so. systemd-resolved already
 hooks into that:


 http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684

 Tom mentioned he's already looking into adding similar code to
 networkd to handle this properly.

 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] Avoid reloading services when shutting down

2015-02-03 Thread Martin Pitt

Lennart Poettering [2015-02-03 18:10 +0100]:
 I am very strongly against adding hacky work-arounds like this to PID

Yeah, indeed. This is why I asked for a more elegant approach, and
indeed the --no-block or --job-mode=ignore-dependencies sound like
slightly better approaches to this. I'll test these more thoroughly
tomorrow, thanks for pointing out!

 1. The deadlocks are deadlocks, and implying --no-block if we are in
 shutdown mode is a pretty drastic hack I think that special cases one
 peculiar case way too much.

Right, the problem is of course more generic. Any set of jobs (i. e. a
transaction) which causes (maybe through some indirection) one of its
job members to get restarted/reloaded will suffer from this deadlock
problem, AFAIUI. Booting and shutdown are therefore mostly affected by
this as pretty much every other time there the pending transactions
are only very small.

 My recommendation would be to stick this into your /usr/bin/service
 compat glue. Use the state string systemctl is-system-running
 outputs to check if you are shutting down. If so, add --no-block to
 the params you pass to systemctl.

That actually sounds like just what's needed here. is-system-running
will also neatly cover the corresponding case on bootup.

 Another option might be to pass --job-mode=ignore-dependencies instead
 of --no-block, which was created for usecases like this, even though
 it is frickin' ugly...

For reload that should be fairly okay, as reload will quickly fail if
the unit isn't actually running, and if it is running its dependencies
already ought to be satisfied.

I'll look into both, thanks for the hints!

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

Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random

On Tue, 03.02.15 14:18, Josh Triplett (j...@joshtriplett.org) wrote:

 On Mon, Feb 02, 2015 at 04:42:21PM +0100, Lennart Poettering wrote:
  On Mon, 02.02.15 12:06, Cristian Rodríguez (crrodriguez at opensuse.org) 
  wrote:
  
   Using /dev/urandom as a key is valid for swap, do not
   warn if this devices are world readable.
   ---
src/cryptsetup/cryptsetup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
   
   diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
   index e6b37ac..38930ae 100644
   --- a/src/cryptsetup/cryptsetup.c
   +++ b/src/cryptsetup/cryptsetup.c
   @@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {

/* Ideally we'd do this on the open fd, but 
   since this is just a
 * warning it's OK to do this in two steps. */
   -if (stat(key_file, st) = 0  (st.st_mode  
   0005))
   -log_warning(Key file %s is 
   world-readable. This is not a good idea!, key_file);
   +if (stat(key_file, st) = 0  (st.st_mode  
   0005)) {
   +if(!STR_IN_SET(key_file, /dev/urandom, 
   /dev/random, /dev/hw_random))
   +log_warning(Key file %s is 
   world-readable. This is not a good idea!, key_file);
   +}
  
  I'd prefer if we'd change the check instead to only apply to
  S_ISREG() files. This way we wouldn't have to list all RNG device
  nodes.
 
 With the exception of /dev/*random, you don't want a world-readable
 device used for a key either.  Some people have setups that use a USB
 device (e.g. /dev/sd* or /dev/disk/by-*/*) as a keyfile, and in that
 case, the file should *not* be world-readable.

Strictly speaking that is true. But this is really just a safety net
(and only a warning) for files people create, where they forgot to set
the right perms. However, device nodes are not created by people, but
by devtmpfs and adjusted by udev, and hence are very unlikely to be
incorrect. I mean, there's little point to protect systemd-cryptsetup
from systemd-udevd, if you follow what I mean. 

I really prefer not having to include the whitelist of devices here...

Lennart

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

Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down

On Tue, 03.02.15 23:03, Michael Biebl (mbi...@gmail.com) wrote:

  While I just made this scenario up I think it's actually quite
  realistic, and I think it's a valid thing for admins to do
 
 Well, we could easily check if DefaultDependencies=yes in this case.
 Actually, this is already what we do for the boot case. [1]
 
 So even with your made-up example, it would work.
 
  The thing is, you have to be extra careful to never, ever call a
  restart/reload from such hook scripts. If those are triggered via
  service or systemctl on a native or SysV script doesn't make a
  difference.
 
  It is completely fine to enqueue restarts and reloads from hook
  scripts. However the emphasis is on *enqueue*. The issue is that you
  block on it, you shouldn't do that.
 
  On Fedora, iscsi is reloaded from an NM callout. If you ask me that's
  frickin' ugly, but it *is* supported as long as iscsi's reload is
  queued asynchronously instead of requested synchronously. In Fedora,
  the logic to make this async sits on the client side of things, it's
  not enforced by the engine in PID 1.
 
  The same really applies to Debian too...
 
  It's simply to easy to cause a dead lock this way, and I think systemd
  should try much harder to avoid such situations.
 
  Well, it would be great if we could solve the halting problem. But we
  can't.
 
  I mean, I am all ears regarding adding deadlock detection code. But I
  am really not convinced that breaking the engine for *everybody* just
  because *some* clients are weird is an option.
 
 Calling it breaking the engine for everybody is hyperbole.
 
 That said, do you have better ideas how we could avoid having systemd
 easily being dead-locked on shutdown?
 I'm all for solving it in a nicer way. But simply throwing the hands
 in the air and saying, not our problem, doesn't help.

I made a clear recommendation: whenever commands are converted from
sysv operations into systemctl operations, then add --no-block or
--job-mode=ignore-deps to the systemctl command line, after checking
that you are in startup or shutdown mode. Why wouldn't that suffice?

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] /proc and /sys get unmounted during boot from NFS, which results in boot error

On Tue, 03.02.15 23:00, Olaf Leidinger (ol...@mescharet.de) wrote:

 Dear systemd-devel list,
 
 I'm trying to debug the following problem:
 
 For some unknown reason, /proc and /sys get unmounted during boot
 from a NFS mounted rootfs. Booting to an emergency shell, I can observe
 them disappear by first calling mount (which reads from /proc due to 
 /etc/mtab 
 being a symlink) and then calling ls /proc. After calling ls, mount 
 obviously
 complains about not being able to read mtab, instead of listing the mounts as 
 before.
 
 A 2nd or 3rd call of mount before listing /proc works fine, too.

That's certainly weird. The log you pasted below doesn't show any
other commands running, which is particularly weird.

Maybe something from your initrd is acting weird?

systemd itself mounts /proc and /sys very early during boot, and then
never touches them anymore. They are excluded from the usual .mount
unit logic in order to ensure they never accidentally disappear...

 Booting with debug options yields no further information, no new
 messages appear while the debug shell is running and the messages
 before are not very interesting (as far as I can tell) [-- end of
 mail].

It might be interesting to strace PID 1 while you are doing this. And
if that doesn't help strace the other processes you run, to see if any
of them unmounts 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] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux

2015-02-03 Thread poma

On 03.02.2015 18:43, David Herrmann wrote:
 Hi
 
 On Tue, Feb 3, 2015 at 6:36 PM, poma pomidorabelis...@gmail.com wrote:
 On 02.02.2015 19:58, David Herrmann wrote:
 As I'm not really interested in hacking on network-managers, I've
 decided to stop working on MiracleCast. If, some day, there's a
 working P2P stack on linux, I might resurrect it. But it sounds more
 likely that I'll refer to the Intel solution (WYSIWIDI) instead.
 There're also gstreamer plugins for WFD now, so maybe give them a try?


 gst-rtsp-server-wfd
 https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md

 Pre-conditions:

 This module is running on established p2p connection with wifi direct, which 
 means that you have to setup this network environment to run this module. I 
 hope this link would be very helpful. ( 
 http://cgit.freedesktop.org/~dvdhrm/miracle )

 You are referring to them, they are referring to you. :)
 
 They provide a gstreamer plugin for Miracast, but quite frankly didn't
 bother hacking on Wifi P2P. Hence, they refer to my miracle-wifid hack
 to provide a P2P link. If NM provides a P2P API, you can just set it
 up via nmcli and then use the gst modules to run Miracast (or you can
 just use the ConnMan API right now).
 
 Thanks
 David
 


Well at least there is an open RFE - Network Manager
[enh] Add support for WiFi P2P (aka WiFi Direct)
https://bugzilla.gnome.org/show_bug.cgi?id=734073

And in this thread I see Patrik Flykt - ConnMan.
Connman WiFi p2p API evaluation
https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html

Let's see if NetworkMan can learn from ConnMan. :)

Thanks again for the occurrence.


poma

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

Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured

2015-02-03 Thread Keller, Jacob E

On Tue, 2015-02-03 at 19:00 +, Keller, Jacob E wrote:
 Hey,
 
 I've recently been using systemd-networkd to great success on a few of
 my machines here. However I ran into an interesting problem on at least
 2 machines so far. I've included the output of journal for
 systemd-networkd with Environment=SYSTEMD_LOG_LEVEL=debug as was
 suggested on another post. In addition the only network file I have
 configured is em0.network which contains the following,
 

Short answer: I removed biosdevname and then it was all happy. This
seems like a problem or delay in how long biosdevname takes to indicate
the name and honestly systemd persistent names are better anyways.

Regards,
Jake

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

[systemd-devel] /proc and /sys get unmounted during boot from NFS, which results in boot error

2015-02-03 Thread Olaf Leidinger

Dear systemd-devel list,

I'm trying to debug the following problem:


For some unknown reason, /proc and /sys get unmounted during boot
from a NFS mounted rootfs. Booting to an emergency shell, I can observe
them disappear by first calling mount (which reads from /proc due to /etc/mtab 
being a symlink) and then calling ls /proc. After calling ls, mount obviously
complains about not being able to read mtab, instead of listing the mounts as 
before.

A 2nd or 3rd call of mount before listing /proc works fine, too.


This happens on an gentoo-amd64 system using kernel 3.18.5 and systemd-218.

Booting with debug options yields no further information, no new
messages appear while the debug shell is running and the messages
before are not very interesting (as far as I can tell) [-- end of mail].

Booting the very same installation with the same initramfs from a disk works 
fine, 
even when forcing the disk to be mounted read-only, as the NFS share is.

About a year ago, I installed a number-crunching cluster, whose nodes are 
running
from a read-only NFS share. This was also a gentoo based system running 
systemd-215. 
Stuff works fine, there. Thus, I tried version 215 and even 216 for the new 
installation, too, yet without success. 


What might cause systemd to unmount /proc and /sys? Or might this issue not be 
related to systemd at all?

Thanks for your input!


Olaf

#

[] [leading kernel messages skipped]
[   17.857082] systemd[1]: Mounting cgroup to /sys/fs/cgroup/cpu,cpuacct of 
type cgroup with options cpu,cpuacct.
[   17.857308] systemd[1]: Mounting cgroup to /sys/fs/cgroup/memory of type 
cgroup with options memory.
[   17.857505] systemd[1]: Mounting cgroup to /sys/fs/cgroup/devices of type 
cgroup with options devices.
[   17.857694] systemd[1]: Mounting cgroup to /sys/fs/cgroup/net_cls of type 
cgroup with options net_cls.
[   17.857882] systemd[1]: Mounting cgroup to /sys/fs/cgroup/cpuset of type 
cgroup with options cpuset.
[   17.858073] systemd[1]: Mounting cgroup to /sys/fs/cgroup/freezer of type 
cgroup with options freezer.
[   17.858258] systemd[1]: Mounting cgroup to /sys/fs/cgroup/blkio of type 
cgroup with options blkio.
[   17.858479] systemd[1]: systemd 218 running in system mode. (+PAM -AUDIT 
-SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS 
+ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN)
[   17.860362] systemd[1]: Detected architecture 'x86-64'.
[   17.879066] systemd[1]: Using cgroup controller name=systemd. File system 
hierarchy is at /sys/fs/cgroup/systemd.
[   17.879273] systemd[1]: Installed release agent.
[   17.879434] systemd[1]: Set up TFD_TIMER_CANCEL_ON_SET timerfd.
[   17.882492] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/systemd-debug-generator as 161.
[   17.882782] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/systemd-gpt-auto-generator as 162.
[   17.883095] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/systemd-getty-generator as 163.
[   17.883403] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/systemd-system-update-generator as 164.
[   17.883685] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/gentoo-local-generator as 165.
[   17.883969] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/systemd-efi-boot-generator as 166.
[   17.884273] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/systemd-fstab-generator as 167.
[   17.884565] systemd[160]: Spawned 
/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator as 168.
[   17.923410] systemd-efi-boot-generator[166]: Not an EFI boot, exiting.
[   17.923445] systemd-fstab-generator[167]: Parsing /etc/fstab
[   17.925772] systemd-fstab-generator[167]: Found entry 
what=134.96.30.183:/exports/raid/client/distribution/gentoo-amd64 where=/ 
type=nfs nofail=no noauto=no
[   17.926259] systemd-gpt-auto-generator[162]: Not a EFI boot, not creating 
root mount.
[   17.987813] systemd-gpt-auto-generator[162]: Root file system not on a 
(single) block device.
[   17.987848] systemd-fstab-generator[167]: Found entry what=home-srv:/home 
where=/home type=nfs nofail=yes noauto=no
[   17.988250] systemd[160]: 
/usr/lib/systemd/system-generators/systemd-gpt-auto-generator succeeded.
[   17.988422] systemd[160]: 
/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator succeeded.
[   17.988582] systemd[160]: 
/usr/lib/systemd/system-generators/systemd-debug-generator succeeded.
[   17.988745] systemd[160]: 
/usr/lib/systemd/system-generators/systemd-getty-generator succeeded.
[   17.988900] systemd[160]: 
/usr/lib/systemd/system-generators/systemd-system-update-generator succeeded.
[   18.090371] systemd[160]: 
/usr/lib/systemd/system-generators/gentoo-local-generator succeeded.
[   18.090528] systemd[160]: 
/usr/lib/systemd/system-generators/systemd-fstab-generator succeeded.
[   18.090680] systemd[160]: 
/usr/lib/systemd/system-generators/systemd-efi-boot-generator succeeded.
[

Re: [systemd-devel] Something is removing links from my *.wants/ directory

On Sat, 13.12.14 07:36, Adam Papai (w...@wooh.hu) wrote:

 Yeah, something similar is happening. If I edit the container.target and
 add the Wants= instead of creating the .wants directory it works well.
 
 I think the preset-all is syncing the config with the .wants directory as
 well and removes all links which are not defined in the config. So editing
 the unit file solved my issue.

You could alternatively pre-gernate a machine ID in /etc/machine-id
using systemd-machine-id-setup. If the file is missing systemd will
assume an unpopulated /etc, and run preset-all as first step.

I figure we should also change systemd though to ensure that
preset-all in that case is purely additive, and does not delete any
units. Added this to the TODO list for now.

Lennart

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

Re: [systemd-devel] VLAN's not coming up systemd-networkd.service loaded failed + systemd-networkd seg fault

On Thu, 20.11.14 15:28, Brendan Horan (brendanho...@basstech.net) wrote:

 No one has any clue?
 Or do I need to provide more information? (if so what?) 

Hmm, somehow this thread got lost. Is this still an issue with current
git? If so could you repost, and we'll have a look at it.

Sorry for not responding more timely and for resurrecting this months
old thread!

Lennart

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

[systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional

2015-02-03 Thread Jay Faulkner

Hi all,

As I posted last week, a change merged a while ago to systemd-nspawn adding 
seccomp protections with no ability to enable/disable broke the Ironic Python 
Agent ramdisk which utilizes CoreOS and systemd. The attached patch makes the 
behavior optional, with it defaulting to disabled. I did this for two reasons; 
the first being that my (and other consumers of OpenStack Ironic) use case was 
broken, as would anyone else using spawn in this manner. Additionally, seccomp 
filters can be configured specifically as desired in the unit file. 

I appreciate your time and effort in getting this patch merged, so I’ll be able 
to upgrade and consume a newer systemd.

Thanks,
Jay Faulkner





systemd-nspawn-seccomp-default-disable.patch
Description: systemd-nspawn-seccomp-default-disable.patch
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v218

On Fri, 12.12.14 14:25, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 Lennart Poettering wrote on 11/12/14 00:16:
  * All systemd programs that read standalone configuration
files in /etc now also support a corresponding series of
.conf.d configuration directories in /etc/, /run/,
/usr/local/lib/, /usr/lib/, and (if configured with
--enable-split-usr) /lib/.  In particular, the following
configuration files now have corresponding configuration
directories: system.conf user.conf, logind.conf,
journald.conf, sleep.conf, bootchart.conf, coredump.conf,
resolved.conf, timesyncd.conf, journal-remote.conf, and
journal-upload.conf.  Note that distributions should use the
configuration directories in /usr/lib/; the directories in
/etc/ are reserved for the system administrator.
 
 Hmmm, at what point is /usr/local/lib/systemd/journald.conf.d/foo.conf read?
 
 Does the journal start only after all local filesystems are mounted, I
 don't see anything that ensures this in the .service or .socket files
 for it (same applies to other tools, but journal is probably most at
 risk because it's started early with DefaultDependencies=no)
 
 It feels very, very odd that /usr/local is being parsed at all here when
 the --prefix arg does not include it. I mean this kinda conflicts with
 users doing their own compiles with --prefix=/usr/local and installing
 stuff there... If the were experimenting, but ultimately didn't want to
 use it, it seems odd to me that the actual packaged version of system
 would read these files.
 
 What's the argument for including /usr/local in all this stuff? Feels
 wrong to me.

Well, /usr/local has very unclear semantics. Installing something into
/usr/local if the stuff is never included in any search paths makes it
pretty useless.

The way I understand /usr/local, it is the place where the admin
himself places his own scripts and stuff, as extensions for the host
OS. Where /opt is the stuff for 3rd party apps (app vendors), and /usr
is for 2nd party stuff (OS vendor), /usr/local is for 1st party stuff
(admin).

The whole thing is really not thought to the end though. Some folks
have /usr/local on NFS, which we cannot handle, since we'll look into
it already before NFS is mounted for some things, and never check it
again...

Note that even though this is not thought to the end, the current
behaviour is perfectly in line with what the XDG basedir spec
suggests, which says that /usr/local should be included in the search
paths for things...

So far we always included it. I can see reasons to keep it that way, I
can see reasons way not including might also be a good
choice. Currently I don't see strong enough reasons to make the change
though.

Lennart

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

Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional

2015-02-03 Thread Brandon Philips

For context this puts a toggle on this feature added to nspawn:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=28650077f36466d9c5ee27ef2006fae3171a2430

I encouraged Jay to make it an opt-in flag so as to not break other
people who had working setups when using nspawn as a minimal ns
wrapper.

Brandon



On Tue, Feb 3, 2015 at 3:22 PM, Jay Faulkner j...@jvf.cc wrote:
 Hi all,

 As I posted last week, a change merged a while ago to systemd-nspawn adding 
 seccomp protections with no ability to enable/disable broke the Ironic Python 
 Agent ramdisk which utilizes CoreOS and systemd. The attached patch makes the 
 behavior optional, with it defaulting to disabled. I did this for two 
 reasons; the first being that my (and other consumers of OpenStack Ironic) 
 use case was broken, as would anyone else using spawn in this manner. 
 Additionally, seccomp filters can be configured specifically as desired in 
 the unit file.

 I appreciate your time and effort in getting this patch merged, so I’ll be 
 able to upgrade and consume a newer systemd.

 Thanks,
 Jay Faulkner




 ___
 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] slow systemd-networkd DHCP client on wlan0 with systemd v217

1;3802;0cOn Tue, 03.02.15 14:38, Charles Devereaux (syst...@guylhem.net) wrote:

 On Tue, Feb 3, 2015 at 2:29 PM, Lennart Poettering lenn...@poettering.net
 wrote:
 
  I am pretty sure signals are not a particularly good interface for
  this. We should add a proper bus API for this one day, but this kinda
  has to wait until kdbus is a done deal, since networkd runs in early
  boot, and dbus-daemon is not available in early boot.
 
 Which would be a good usecase for signals (until kdbus happens, which might
 take some time)

Signals are asynchronous, which makes them a lot less useful to use,
since you cannot wait resonably for completion the operation you request.

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] slow systemd-networkd DHCP client on wlan0 with systemd v217

2015-02-03 Thread Charles Devereaux

True, but it's better than nothing.

Well, I guess systemd-networkd doing basic things will have to wait on
kdbus :-)



On Tue, Feb 3, 2015 at 3:32 PM, Lennart Poettering lenn...@poettering.net
wrote:

 1;3802;0cOn Tue, 03.02.15 14:38, Charles Devereaux (syst...@guylhem.net)
 wrote:

  On Tue, Feb 3, 2015 at 2:29 PM, Lennart Poettering 
 lenn...@poettering.net
  wrote:
 
   I am pretty sure signals are not a particularly good interface for
   this. We should add a proper bus API for this one day, but this kinda
   has to wait until kdbus is a done deal, since networkd runs in early
   boot, and dbus-daemon is not available in early boot.
 
  Which would be a good usecase for signals (until kdbus happens, which
 might
  take some time)

 Signals are asynchronous, which makes them a lot less useful to use,
 since you cannot wait resonably for completion the operation you request.

 Lennart

 --
 Lennart Poettering, Red Hat

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

[systemd-devel] test-capabilities fail and systemd-timesyncd broken

2015-02-03 Thread Daniel Buch

Hi,

This commit 51ddf61540976fc7b09ce5 solved systemd-resolved, but broke
systemd-timesyncd. Atleast on my system.

dbuch@dbuch-laptop ~ % lscpu | grep -i byte
Byte Order:Little Endian

dbuch@dbuch-laptop ~ % SYSTEMD_LOGLEVEL=debug sudo
/usr/lib/systemd/systemd-timesyncd
Failed to enable capabilities bits: Invalid argument

I suspect the usage of log2u64() is wrong? Im not able to gork this, but
hope this helps :)

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

Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down

2015-02-03 21:52 GMT+01:00 Lennart Poettering lenn...@poettering.net:

 But note that this way you alter *all* queued jobs that way,
 regardless if they are created with the assumptions of sysv behaviour
 or if they were created in code that understands systemd's semantics,
 and actually cares for the correct ordering..

The patch does not alter any ordering, it simply throws away
reload/restart requests, which would be pointless anyway.

 I'd strongly recommend finding local solutions to the problems at hand
 here, rather than changing behaviour for all other non-sysv code as
 well...

Maybe this is an misunderstanding, but this issue is not sysv specific at all.


-- 
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] Container, private network and socket activation

On Tue, 03.02.15 20:45, Mikhail Morfikov (mmorfi...@gmail.com) wrote:

  Also note that using socket activation for cotnainers means that
  systemd instance inside the container also needs to have configuration
  for the socket, to pass it on to the service that ultimately shall
  answer for it. Are you sure that apache2 has support for that, and
  that you set it up?
 
 Actually, I just want to start the container when someone else tries to
 connect to the port 80 of the host, just using the container's IP
 address. So, for instance, my host has IP 192.168.1.150, the container
 has IP 192.168.10.10 , and I want to type the second address in a web
 browser so the system in the container could boot and start apache.

Hmm, to implement something like this I think the best option would be
to set up the interface to later pass to the container first on the
host, then listen on the container's IP address on the host. When a
connection comes in the container would have to be started via socket
activation, and would then have to take over the container interface
(with --network-interface=), so that all further connections are
delivered directly to the container and the host is not involved
anymore. 

This way you'd still have two seperate network namespaces, but the
interface would change namespace during activation of the container,
so that first the host owns it and processes it and then the
container.

Of course, either way you'd need socket activation support in your
Apache. And I don't think Apache provides that right now out of the
box...

Also note that ther's a slight security risk here: the socket that is
used for activation is from the hosts's namespace. Using the old BSD
netdev ioctls like SIOCGIFCONF will reveal the host's network setup,
not the container's setup.

 Then I could browse the page that is hosted by the apache server inside
 of the container. I'm not sure if that's even possible, but apache
 inside of the container starts at boot automatically, so I think there's
 no need for setting anything in the container -- please correct me if
 I'm wrong.

Socket activation is somethings daemons need to support
explicitly. Many do these days, but I don't think Apache is one of
them.

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] Avoid reloading services when shutting down

On Tue, 03.02.15 20:36, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Lennart Poettering [2015-02-03 18:10 +0100]:
  I am very strongly against adding hacky work-arounds like this to PID
 
 Yeah, indeed. This is why I asked for a more elegant approach, and
 indeed the --no-block or --job-mode=ignore-dependencies sound like
 slightly better approaches to this. I'll test these more thoroughly
 tomorrow, thanks for pointing out!
 
  1. The deadlocks are deadlocks, and implying --no-block if we are in
  shutdown mode is a pretty drastic hack I think that special cases one
  peculiar case way too much.
 
 Right, the problem is of course more generic. Any set of jobs (i. e. a
 transaction) which causes (maybe through some indirection) one of its
 job members to get restarted/reloaded will suffer from this deadlock
 problem, AFAIUI. Booting and shutdown are therefore mostly affected by
 this as pretty much every other time there the pending transactions
 are only very small.

It's really about synchronous waiting on jobs. If you synchronously
wait for completion of jobs that are ordered against the job your are
part of yourself, then things will deadlock. This can happen in many
contexts. You can fix this by:

 a) changing from synchronous to asynchronous operation

 or 

 b) removing the ordering (either individually for the job, or
generically forever in the unit)

Now, regardless which option you choose it's always a good idea to
keep this change as local as possible. Altering the state engine for
all operations is the worst solution...

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] Avoid reloading services when shutting down

On Tue, 03.02.15 20:50, Michael Biebl (mbi...@gmail.com) wrote:

  Another option might be to pass --job-mode=ignore-dependencies instead
  of --no-block, which was created for usecases like this, even though
  it is frickin' ugly...
 
  For reload that should be fairly okay, as reload will quickly fail if
  the unit isn't actually running, and if it is running its dependencies
  already ought to be satisfied.
 
  I'll look into both, thanks for the hints!
 
 Keep in mind though, that you'll need to not only update service,
 but also invoke-rc.d and the lsb-hook, which is used when someone
 calls /etc/init.d/foo directly.
 
 It's also magnitudes less efficient to spawn external binaries to get
 the system state then doing this check from within systemd itself.
 
 So I'm not really convinced that shifting the responsibility here to
 the scripts themselves is the better approach.

But note that this way you alter *all* queued jobs that way,
regardless if they are created with the assumptions of sysv behaviour
or if they were created in code that understands systemd's semantics,
and actually cares for the correct ordering..

I'd strongly recommend finding local solutions to the problems at hand
here, rather than changing behaviour for all other non-sysv code as
well...

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] Avoid reloading services when shutting down

On Tue, 03.02.15 21:58, Michael Biebl (mbi...@gmail.com) wrote:

 2015-02-03 21:52 GMT+01:00 Lennart Poettering lenn...@poettering.net:
 
  But note that this way you alter *all* queued jobs that way,
  regardless if they are created with the assumptions of sysv behaviour
  or if they were created in code that understands systemd's semantics,
  and actually cares for the correct ordering..
 
 The patch does not alter any ordering, it simply throws away
 reload/restart requests, which would be pointless anyway.

Well, OK, cares for execution of the jobs, then.

  I'd strongly recommend finding local solutions to the problems at hand
  here, rather than changing behaviour for all other non-sysv code as
  well...
 
 Maybe this is an misunderstanding, but this issue is not sysv specific at all.

I don't see how this would apply to non-sysv code. I mean, code that
is written with systemd semantics in mind should be able to issue a
service reload during any time it wants to, if it keeps the ordering
issues in mind. For example, if I have a service that has
DefaultDependencies=no (and hence ordered against nothing at all by
default), and I want to issue systemctl reload on it, knowing that
this cannot really deadlock, since there are no deps that could cause
deadlocks, then i should be able to do so. With your patch you turn
these reloads into NOPs...

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] Second (erroneous) check of rootfs?

2015-02-03 Thread Harald Hoyer

On 03.02.2015 00:44, Lennart Poettering wrote:
 On Tue, 03.02.15 00:27, Lennart Poettering (lenn...@poettering.net) wrote:
 
 On Thu, 08.01.15 16:34, Harald Hoyer (harald.ho...@gmail.com) wrote:

 IMHO

 systemd-fsck-root.service should be removed entirely and generated by the
 fstab-generator in the real root like all the other mount points.

 Well, we also need it if there's no /etc/fstab...


 OR

 fstab-generator should create systemd-fsck-root.service for the /sysroot
 mountpoint in the initrd, which then will be serialized.

 That sounds like a good idea.
 
 I take that back.
 
 By which I mean that after reading the thread again I think that this
 is probably the way to go:
 
 The fstab generator should enqeue an s-f@.s for the root device as
 usual, when it runs in an initrd. However, it should also create a
 mask file for s-f-r.s in /run, so that it is not executed after the
 transition.
 
 This should be a one-line fix pretty much, and we don't need any flag
 file.
 
 Does that make sense?
 
 Would be happy to take a tested patch for this!
 
 Lennart
 

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

Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

On Tue, 03.02.15 09:05, Rauta, Alin (alin.ra...@intel.com) wrote:

 Yes, since the concept of UFD group is not exposed.

Does this mean we have agreement that the simply BindCarrier= option I
proposed would be sufficient for your usecases? That would be great!

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] User sessions, session buses, user buses

2015-02-03 Thread Stef Bon

2015-01-30 9:30 GMT+01:00 Simon McVittie simon.mcvit...@collabora.co.uk:
 In principle, a PAM module or something could ensure that we have a
 dbus-daemon per login session, even tty/ssh/cron login sessions
 (which all go through PAM). In practice, nobody has ever cared enough to
 implement this, so we're left with D-Bus autolaunch, which can't
 actually work for tty sessions and had bad side-effects from its
 attempts to do so, so I disabled it 3 years ago in favour of
 recommending that users requiring a D-Bus session should start their own
 and manage its lifetime themselves e.g. with dbus-run-session(1).


Hi all,

I've never understood why the session bus is started through dbus-launch.
Leave it to the login manager (not PAM), or provide the socket and
activate the session bus only when
some app is connecting to it, which can be a graphical session, but
may be also a console.

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

Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional

On Tue, 03.02.15 23:22, Jay Faulkner (j...@jvf.cc) wrote:

 Hi all,
 
 As I posted last week, a change merged a while ago to systemd-nspawn
 adding seccomp protections with no ability to enable/disable broke
 the Ironic Python Agent ramdisk which utilizes CoreOS and
 systemd. The attached patch makes the behavior optional, with it
 defaulting to disabled. I did this for two reasons; the first being
 that my (and other consumers of OpenStack Ironic) use case was
 broken, as would anyone else using spawn in this
 manner. Additionally, seccomp filters can be configured specifically
 as desired in the unit file.

This was about allowing kernel module loading from inside nspawn
containers?

I completely missed that we actually really have seccomp filters to
disallow that in place... We hence have two layers of security there
to turn off kernel module loading: seccomp and the missing
CAP_SYS_MODULE capability.

I am not particularly fond of the idea of adding a completely new
command line option for this though. Maybe we can find another way for
this.

For example, one option could be to split the seccomp syscall
blacklist in two: split out the kernel kmod related syscalls, and
only add them to the seccomp filter if arg_retain does not include
CAP_SYS_MODULE. This would then leave the module seccomp filters in
place by default, however, if you add the CAP_SYS_MODULE cap to the
container with --capability= then the seccomp filter is changed to
also allow the module loading syscalls.

The patch is corrupted, it includes Windows new lines. 

If you rework the patch as suggested above, and send it as uncorrupted
patch, I'd be happy to merge it.

Lennart

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

[systemd-devel] [PATCH] virt: add detect_vm_devicetree for powerpc arches

2015-02-03 Thread Chris J Arges

Check sysfs devicetree values in order to detect if we are running on a KVM
hypervisor on a powerpc architecture.
---
 src/shared/virt.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/shared/virt.c b/src/shared/virt.c
index f10baab..7c1381f 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -101,6 +101,22 @@ static int detect_vm_cpuid(const char **_id) {
 return 0;
 }
 
+static int detect_vm_devicetree(const char **_id) {
+#if defined(__powerpc__) || defined(__powerpc64__)
+_cleanup_free_ char *hvtype = NULL;
+int r;
+
+r = 
read_one_line_file(/sys/firmware/devicetree/base/hypervisor/compatible, 
hvtype);
+if (r = 0) {
+if (streq(hvtype, linux,kvm)) {
+*_id = kvm;
+return 1;
+}
+}
+#endif
+return 0;
+}
+
 static int detect_vm_dmi(const char **_id) {
 
 /* Both CPUID and DMI are x86 specific interfaces... */
@@ -204,6 +220,10 @@ int detect_vm(const char **id) {
 if (r != 0)
 goto finish;
 
+r = detect_vm_devicetree(_id);
+if (r != 0)
+goto finish;
+
 if (_id) {
 /* other */
 r = 1;
-- 
1.9.1

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

Re: [systemd-devel] [PATCH] virt: add detect_vm_devicetree for powerpc arches

On Tue, 03.02.15 17:56, Chris J Arges (chris.j.ar...@canonical.com) wrote:

 Check sysfs devicetree values in order to detect if we are running on a KVM
 hypervisor on a powerpc architecture.

Looks good! Applied!

Thanks!

Lennart

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

Re: [systemd-devel] [PATCH 2/4] systemctl: edit: improve error messages, report actual error for units which could not be loaded

2015-02-03 Thread Ivan Shapovalov

On 2015-02-03 at 23:05 +0100, Lennart Poettering wrote:
 On Fri, 19.12.14 17:08, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
 What happened to this patch series actually? I think only 1/4 was ever
 commited, what about the other ones? Ivan, any chance you can rebase
 the rest with Zbigniew's requested changes and post again?

Yeah, I've kinda forgotten about this series... Will do. Thanks for the
reminder!

-- 
Ivan Shapovalov / intelfx /


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

[systemd-devel] [PATCH] cg_path_get_user_unit(): Did not correctly parse user-unit templates.

2015-02-03 Thread Luke Shumaker

It ran either skip_session() or skip_user_manager(), then ran skip_slices()
iff skip_session() ran.  It needs to run skip_slices() in either case.

Included is a test case demonstrating why.
---
 src/shared/cgroup-util.c| 19 ---
 src/test/test-cgroup-util.c |  1 +
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 0d3cc53..1c5af69 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1251,17 +1251,14 @@ int cg_path_get_user_unit(const char *path, char 
**unit) {
 /* Skip slices, if there are any */
 e = skip_slices(path);
 
-/* Skip the session scope... */
-t = skip_session(e);
-if (t)
-/* ... and skip more slices if there's one */
-e = skip_slices(t);
-else {
-/* ... or require a user manager unit to be there */
-e = skip_user_manager(e);
-if (!e)
-return -ENOENT;
-}
+/* Skip the session scope or user manager... */
+(t = skip_session(e)) || (t = skip_user_manager(e));
+
+if (!t)
+return -ENOENT;
+
+/* ... and skip more slices if there are any */
+e = skip_slices(t);
 
 return cg_path_decode_unit(e, unit);
 }
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 58eb744..67eeeb5 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -93,6 +93,7 @@ static void test_path_get_user_unit(void) {
 check_p_g_u_u(/meh.service, -ENOENT, NULL);
 check_p_g_u_u(/session-3.scope/_cpu.service, 0, cpu.service);
 
check_p_g_u_u(/user.slice/user-1000.slice/user@1000.service/server.service, 
0, server.service);
+
check_p_g_u_u(/user.slice/user-1000.slice/user@1000.service/foobar.slice/foobar@pie.service,
 0, foobar@pie.service);
 
check_p_g_u_u(/user.slice/user-1000.slice/user@.service/server.service, 
-ENOENT, NULL);
 }
 
-- 
2.2.2

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

Re: [systemd-devel] [PATCH 3/4] systemctl: edit: further reword error messages

On Wed, Feb 04, 2015 at 03:35:47AM +0300, Ivan Shapovalov wrote:
 On 2015-01-05 at 17:08 +0100, Zbigniew Jędrzejewski-Szmek wrote:
  On Fri, Dec 19, 2014 at 05:08:09PM +0300, Ivan Shapovalov wrote:
   ---
src/systemctl/systemctl.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
   
   diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
   index 658793e..20c367c 100644
   --- a/src/systemctl/systemctl.c
   +++ b/src/systemctl/systemctl.c
   @@ -4776,7 +4776,7 @@ static int init_home_and_lookup_paths(char 
   **user_home, char **user_runtime, Loo

r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
if (r  0)
   -return log_error_errno(r, Failed to lookup unit lookup 
   paths: %m);
   +return log_error_errno(r, Failed to get unit lookup 
   paths: %m);
  Maybe query? get is ugly.
 
 OK.
 
  
return 0;
}
   @@ -5900,11 +5900,11 @@ static int create_edit_temp_file(const char 
   *new_path, const char *original_path

r = tempfn_random(new_path, t);
if (r  0)
   -return log_error_errno(r, Failed to determine temporary 
   filename for %s: %m, new_path);
   +return log_error_errno(r, Failed to determine temporary 
   filename for \%s\: %m, new_path);

r = mkdir_parents(new_path, 0755);
if (r  0) {
   -log_error_errno(r, Failed to create directories for %s: 
   %m, new_path);
   +log_error_errno(r, Failed to create directories for 
   \%s\: %m, new_path);
free(t);
return r;
}
   @@ -5913,12 +5913,12 @@ static int create_edit_temp_file(const char 
   *new_path, const char *original_path
if (r == -ENOENT) {
r = touch(t);
if (r  0) {
   -log_error_errno(r, Failed to create temporary 
   file %s: %m, t);
   +log_error_errno(r, Failed to create temporary 
   file \%s\: %m, t);
free(t);
return r;
}
} else if (r  0) {
   -log_error_errno(r, Failed to copy %s to %s: %m, 
   original_path, t);
   +log_error_errno(r, Failed to copy \%s\ to \%s\: 
   %m, original_path, t);
free(t);
return r;
}
   @@ -6026,7 +6026,7 @@ static int unit_file_create_copy(const char 
   *unit_name,
if (!path_equal(fragment_path, tmp_new_path)  
   access(tmp_new_path, F_OK) == 0) {
char response;

   -r = ask_char(response, yn, %s already exists, are 
   you sure to overwrite it with %s? [(y)es, (n)o] , tmp_new_path, 
   fragment_path);
   +r = ask_char(response, yn, \%s\ already exists, 
   are you sure to overwrite it with \%s\? [(y)es, (n)o] , tmp_new_path, 
   fragment_path);
  
  This is not gramatically correct. I think
  \%s\ already exists. Overwrite with \%s\?... would be better.
 
 OK.
 
  
  
if (r  0) {
free(tmp_new_path);
return r;
   @@ -6040,7 +6040,7 @@ static int unit_file_create_copy(const char 
   *unit_name,

r = create_edit_temp_file(tmp_new_path, fragment_path, 
   tmp_tmp_path);
if (r  0) {
   -log_error_errno(r, Failed to create temporary file for 
   %s: %m, tmp_new_path);
   +log_error_errno(r, Failed to create temporary file for 
   \%s\: %m, tmp_new_path);
free(tmp_new_path);
return r;
}
   @@ -6176,12 +6176,12 @@ static int edit(sd_bus *bus, char **args) {
assert(args);

if (!on_tty()) {
   -log_error(Cannot edit units if we are not on a tty);
   +log_error(Not on a tty, refusing.);
  Why? Replacing a nice specific error message with a generic one seems to
  be a step backwards.
 
 I've tried to follow the existing pattern of most error messages in
 systemd: Condition, action + -ing.
 
 I'll reword again to make messages more specific... unless you tell me
 to stop bikeshedding and leave it as is ;)
Yeah, I think that that those messages are OK.

   -log_warning(Edition of %s canceled: temporary 
   file empty, *original);
   +log_warning(Temporary file empty, not saving.);
  And here.
 
 Here? They are equally specific; editing cancelled == file not
 saved.
The original one gives a hint of what the overall effect for the action is.
With you replacemnt, things are less explicit.

systemctl edit is something that may be used by relatively newbie
administrators, so some hand-holding is more useful than in other parts
of systemd.

Zbyszek
___

Re: [systemd-devel] [PATCH] cg_path_get_user_unit(): Did not correctly parse user-unit templates.

2015-02-03 Thread Luke Shumaker

At Wed, 4 Feb 2015 01:52:36 +0100,
Lennart Poettering wrote:
  +/* Skip the session scope or user manager... */
  +(t = skip_session(e)) || (t = skip_user_manager(e));
 
 Hmpf, I really don't like this ()||() magic I must say.
 
 Any chance you can rework this to just use normal
 
 t = skip_session(e);
 if (!t)
 t = skip_user_manager(...)
 
 THis is really an excercise in making code easily readable, not an
 excercsie to show superior C skills ;-)

Sure.  I thought the || version was easier to read; that it showed the
intent better.  Though it may be that it's similar to a Ruby idiom,
and I've been working with some Ruby recently.

--
Happy hacking,
~ Luke Shumaker
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v218

On Fri, 12.12.14 15:57, Matthias Urlichs (matth...@urlichs.de) wrote:

 Hi,
 
 Colin Guthrie:
  What's the argument for including /usr/local in all this stuff? Feels
  wrong to me.
  
 +ME_TOO. /usr/local frequently has wider permissions than reasonable for
 something that can affect system startup.
 
 I can think of one argument in favor of this -- you can modify the system
 default that way, without touching /etc, so this would add local
 modifications to an image which you then use for system initialization.
 
 However, you can do the same thing by adding appropriate *.conf files to
 /usr/lib/systemd/**.

/usr is OS vendor territory. /usr/local is admin territory. The admin
should not modify /usr, ever.

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] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 This looks like fallout of moving to generators for sysv units. Before
 systemd added dependencies on runlevelX.target directly to units built
 from initscripts. This forced runlevelX.target resolution and
 everything was OK. Now core systemd never references these targets
 directly.
 
 This is a genuine bug which will bite people. But it looks like worked
 just by accident before anyway :( So we need possibility to define
 aliases for existing units without exhaustive search across all unit
 definitions ... may be unit.alias.d?

This is a real shortcoming of the current logic in systemd, indeed.

So, one possible way out of this might be add a .wants/ dep from
multi-user.target.wants/ to runlevel3.target, if runlevel3.target is
linked to that. THis would cause runlevel3.target to be loaded, which
would then detect the symlink and merge it into
multi-user.target. After loading it would try to create the .wants
link, but recognize that it is now trying to create a .wants link on
itself, and suppress it.

These extra .wants symlinks could even be generated dynamically from
sysv-generator, so that people can easily override the runlevel
mappings by placing a symlink in /etc, without having to manually also
add the .wants/ link at the same time...

It's a bit ugly, and feels a bit hackish, but should work. 

Another option would be to actually add expose the internal dependency
type References to the outside. It's only purpose is to act as
reference for the GC logic, thus ensuring that its target is
loaded. 

I am kinda leaning towards the sysv-generator option. 

Happy to take a patch if anybody wants to hack 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] [PATCH 3/4] systemctl: edit: further reword error messages

2015-02-03 Thread Ivan Shapovalov

On 2015-01-05 at 17:08 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Dec 19, 2014 at 05:08:09PM +0300, Ivan Shapovalov wrote:
  ---
   src/systemctl/systemctl.c | 22 +++---
   1 file changed, 11 insertions(+), 11 deletions(-)
  
  diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
  index 658793e..20c367c 100644
  --- a/src/systemctl/systemctl.c
  +++ b/src/systemctl/systemctl.c
  @@ -4776,7 +4776,7 @@ static int init_home_and_lookup_paths(char 
  **user_home, char **user_runtime, Loo
   
   r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
   if (r  0)
  -return log_error_errno(r, Failed to lookup unit lookup 
  paths: %m);
  +return log_error_errno(r, Failed to get unit lookup 
  paths: %m);
 Maybe query? get is ugly.

OK.

 
   return 0;
   }
  @@ -5900,11 +5900,11 @@ static int create_edit_temp_file(const char 
  *new_path, const char *original_path
   
   r = tempfn_random(new_path, t);
   if (r  0)
  -return log_error_errno(r, Failed to determine temporary 
  filename for %s: %m, new_path);
  +return log_error_errno(r, Failed to determine temporary 
  filename for \%s\: %m, new_path);
   
   r = mkdir_parents(new_path, 0755);
   if (r  0) {
  -log_error_errno(r, Failed to create directories for %s: 
  %m, new_path);
  +log_error_errno(r, Failed to create directories for 
  \%s\: %m, new_path);
   free(t);
   return r;
   }
  @@ -5913,12 +5913,12 @@ static int create_edit_temp_file(const char 
  *new_path, const char *original_path
   if (r == -ENOENT) {
   r = touch(t);
   if (r  0) {
  -log_error_errno(r, Failed to create temporary 
  file %s: %m, t);
  +log_error_errno(r, Failed to create temporary 
  file \%s\: %m, t);
   free(t);
   return r;
   }
   } else if (r  0) {
  -log_error_errno(r, Failed to copy %s to %s: %m, 
  original_path, t);
  +log_error_errno(r, Failed to copy \%s\ to \%s\: %m, 
  original_path, t);
   free(t);
   return r;
   }
  @@ -6026,7 +6026,7 @@ static int unit_file_create_copy(const char 
  *unit_name,
   if (!path_equal(fragment_path, tmp_new_path)  
  access(tmp_new_path, F_OK) == 0) {
   char response;
   
  -r = ask_char(response, yn, %s already exists, are you 
  sure to overwrite it with %s? [(y)es, (n)o] , tmp_new_path, fragment_path);
  +r = ask_char(response, yn, \%s\ already exists, are 
  you sure to overwrite it with \%s\? [(y)es, (n)o] , tmp_new_path, 
  fragment_path);
 
 This is not gramatically correct. I think
 \%s\ already exists. Overwrite with \%s\?... would be better.

OK.

 
 
   if (r  0) {
   free(tmp_new_path);
   return r;
  @@ -6040,7 +6040,7 @@ static int unit_file_create_copy(const char 
  *unit_name,
   
   r = create_edit_temp_file(tmp_new_path, fragment_path, 
  tmp_tmp_path);
   if (r  0) {
  -log_error_errno(r, Failed to create temporary file for 
  %s: %m, tmp_new_path);
  +log_error_errno(r, Failed to create temporary file for 
  \%s\: %m, tmp_new_path);
   free(tmp_new_path);
   return r;
   }
  @@ -6176,12 +6176,12 @@ static int edit(sd_bus *bus, char **args) {
   assert(args);
   
   if (!on_tty()) {
  -log_error(Cannot edit units if we are not on a tty);
  +log_error(Not on a tty, refusing.);
 Why? Replacing a nice specific error message with a generic one seems to
 be a step backwards.

I've tried to follow the existing pattern of most error messages in
systemd: Condition, action + -ing.

I'll reword again to make messages more specific... unless you tell me
to stop bikeshedding and leave it as is ;)

 
   return -EINVAL;
   }
   
   if (arg_transport != BUS_TRANSPORT_LOCAL) {
  -log_error(Cannot remotely edit units);
  +log_error(Remote operation requested, refusing.);
 And the same here.
 
   return -EINVAL;
   }
   
  @@ -6205,12 +6205,12 @@ static int edit(sd_bus *bus, char **args) {
* It's useful if the user wants to cancel its modification
*/
   if (null_or_empty_path(*tmp)) {
  -log_warning(Edition of %s canceled: temporary 
  file empty, *original);
  +log_warning(Temporary file empty, not saving.);
 And here.

Here? They are equally specific; editing cancelled == file not
saved.

-- 
Ivan Shapovalov / intelfx /

Re: [systemd-devel] forever loop during garbage collection

On Wed, 10.12.14 15:22, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

Sorry for the late reply.

 On Mon, Dec 8, 2014 at 8:09 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Sun, 30.11.14 14:38, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  Hi,
 
  We are experiencing an unbreakable loop in manager_dispatch_gc_queue.
  Problem happens when systemd runs in sysV compatibility mode (Porky
  enables this).
 
  Seems like manager_dispatch_gc_queue's while loop gets stuck and seems
  like unit_gc_sweep cannot make a decision about the unit. As a result,
  it marks the unit with offset_unsure and adds the unit back to gc
  queue.
 
  If I am reading the code correctly recursive unit_gc_sweep will never
  be able to remove the unit from the gc queue if it is referenced by
  another unit and if another unit is referenced by the unit.
 
  A is referenced by B
  B is referenced by A
 
  So in this case first A will be processed by the GC sweep, it will
  follow the link to B while setting the state to IN_PATH and invoke the
  GC sweep on that. B will then be set to IN_PATH too. GC sweep now
  follows its link back, and up at A again, but this time return quickly
  because its state is set to IN_PATH. Due to this, it will then set B's
  state to UNSURE, and return to A, which in effect will now be set to
  UNSURE too. Now, we return into GC queue dispatch call, which will
  notice that it is UNSURE and uprgade that to BAD, and kill it because
  there's nothin in the unit's dependency network that is clearly a
  GOOD, and hence should be removed.
 
  The essence of cycle breaking here is really in
  manager_dispatch_gc_queue() which uprgades UNSURE to BAD in the end. I
  am not seeing how this could end up in an endless loop hence.
 
 I have debugged it more and as you have said there is no bug in code
 but it takes so long to go out of unit_gc_sweep I thought there is a
 forever loop.
 
 Attached is my patch on 216 and
 https://drive.google.com/file/d/0B_uiALgWpGXtZ0VidURxSnVhcDA/view?usp=sharing
 is a part of the log after patch.
 
 It has been 3 hours since I issued systemctl isolate and according
 to the logs I can see that garbage collection logic is making it's way
 back up. I guess it will eventually resolve itself but after so many
 hours.

Hmm, so, you mean the code works correctly but scales really badly?
How many units do you have?

 
 (Search for - - and it is happening every 300.000 lines)
 
 Problem seemed to be introduced on 95ed329 - Move handling of sysv
 initscripts to a generator.

Hmm, how precisely do the deps look like the generator creates for
you?

Any chance you can run
/usr/lib/systemd/system-generators/systemd-sysv-generator /tmp/foo
/tmp/foo /tmp/foo, and check what deps it precisely generates in
/tmp/foo?

I have never seen that the GC scales this badly...

 This is totally due to how sysV generator is linking services but I
 think slowness on GC can happen on a complex system with many units
 linked with each other.
 
 Thoughts?

I am puzzled, quite frankly...

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] quiet on kernel command line also prevents logging to journal

On Sun, 14.12.14 18:28, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 Before commit d7b15e0a0161e8fd823bffd61a4799364871582f quiet would
 suppress console messages but still do normal logging. Now quiet also
 clamps log level to NOTICE meaning that all messages about
 starting/stopping services are no more logged.

True.

 Is this change intentional? This makes it rather hard to debug any
 problem related to service startup order.

Hmm, well, the change was intentional, but the effect of it was not
clear to me ;-)

You are right though. I have now changed this part again:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=5e07a79e84ab8b045b9df1a2719f14fc84471a1d

Thanks,

Lennart

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

Re: [systemd-devel] [PATCH] cg_path_get_user_unit(): Did not correctly parse user-unit templates.