Re: [systemd-devel] [PATCH v2] Improving systemd-nspawn@.service (container dir/nonpersistant journal)

2014-11-21 Thread Martin Pitt
Hello Lennart,

Lennart Poettering [2014-11-21  0:36 +0100]:
 So far we prefixed all variables parsed from command line arguments
 with arg_, please follow the same scheme for this.

Ah, sure. Done.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From b743c4546148f61c855ea773e71a660c5dc9aa58 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Thu, 20 Nov 2014 14:30:52 +0100
Subject: [PATCH] nspawn: Add try-{host,guest} journal link modes

--link-journal={host,guest} fail if the host does not have persistent
journalling enabled and /var/log/journal/ does not exist. Even worse, as there
is no stdout/err any more, there is no error message to point that out.

Introduce two new modes try-host and try-guest which don't fail in this
case, and instead just silently skip the guest journal setup.

Change -j to mean try-guest instead of guest, and fix the wrong --help
output for it (it said host before).

Change systemd-nsp...@.service.in to use try-guest so that this unit works
with both persistent and non-persistent journals on the host without failing.

https://bugs.debian.org/770275
---
 man/systemd-nspawn.xml   | 11 ---
 src/nspawn/nspawn.c  | 37 +
 units/systemd-nsp...@.service.in |  2 +-
 3 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index b3a2d32..75db65e 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -439,7 +439,9 @@
 versa). Takes one of
 literalno/literal,
 literalhost/literal,
+literaltry-host/literal,
 literalguest/literal,
+literaltry-guest/literal,
 literalauto/literal. If
 literalno/literal, the journal is
 not linked. If literalhost/literal,
@@ -453,8 +455,11 @@
 guest file system (beneath
 filename/var/log/journal/replaceablemachine-id/replaceable/filename)
 and the subdirectory is symlinked into the host
-at the same location. If
-literalauto/literal (the default),
+at the same location. literaltry-host/literal
+and literaltry-guest/literal do the same
+but do not fail if the host does not have
+persistant journalling enabled.
+If literalauto/literal (the default),
 and the right subdirectory of
 filename/var/log/journal/filename
 exists, it will be bind mounted
@@ -473,7 +478,7 @@
 termoption-j/option/term
 
 listitemparaEquivalent to
-option--link-journal=guest/option./para/listitem
+option--link-journal=try-guest/option./para/listitem
 /varlistentry
 
 varlistentry
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index c2311b3..b4dcf39 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -124,6 +124,7 @@ static bool arg_private_network = false;
 static bool arg_read_only = false;
 static bool arg_boot = false;
 static LinkJournal arg_link_journal = LINK_AUTO;
+static bool arg_link_journal_try = false;
 static uint64_t arg_retain =
 (1ULL  CAP_CHOWN) |
 (1ULL  CAP_DAC_OVERRIDE) |
@@ -202,8 +203,9 @@ static void help(void) {
 --capability=CAP   In addition to the default, retain specified\n
capability\n
 --drop-capability=CAP  Drop the specified capability from the default set\n
---link-journal=MODELink up guest journal, one of no, auto, guest, host\n
- -jEquivalent to --link-journal=host\n
+--link-journal=MODELink up guest journal, one of no, auto, guest, host,\n
+   try-guest, try-host\n
+ -jEquivalent to --link-journal=try-guest\n
 --read-onlyMount the root directory read-only\n
 --bind=PATH[:PATH] Bind mount a file or directory from the host into\n
the container\n
@@ -428,6 +430,7 @@ static int parse_argv(int argc, char *argv[]) {
 
 case 'j':
 

Re: [systemd-devel] [PATCH 2/4] util: add functions getting proc status, maps, limits, cgroup

2014-11-21 Thread Jakub Filak
On Thu, 2014-11-20 at 14:36 +0100, Lennart Poettering wrote:
 On Wed, 19.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:
 
  ---
   src/shared/util.c| 13 +
   src/shared/util.h|  4 
   src/test/test-util.c | 17 +
   3 files changed, 34 insertions(+)
  
  diff --git a/src/shared/util.c b/src/shared/util.c
  index 0166052..d62d90c 100644
  --- a/src/shared/util.c
  +++ b/src/shared/util.c
  @@ -892,6 +892,19 @@ int get_process_root(pid_t pid, char **root) {
   return get_process_link_contents(p, root);
   }
   
  +#define DEFINE_FN_GET_PROCESS_FULL_FILE(name) \
  +int get_process_##name(pid_t pid, char **name) { \
  +const char *p; \
  +assert(pid = 0); \
  +p = procfs_file_alloca(pid, #name); \
  +return read_full_file(p, name, /*size*/NULL); \
  +}
  +
  +DEFINE_FN_GET_PROCESS_FULL_FILE(status)
  +DEFINE_FN_GET_PROCESS_FULL_FILE(maps)
  +DEFINE_FN_GET_PROCESS_FULL_FILE(limits)
  +DEFINE_FN_GET_PROCESS_FULL_FILE(cgroup)
  +
 
 Please use functions instead of macros wherever that works. 
 
 Maybe it is sufficient to just provide a single function for all four
 cases that takes an extra argument for the file name to read?
 
 Maybe:
 
 int get_process_proc_file(pid_t pid, const char *filename, char **ret)
 
 Or so? Given that the files in question are generally just read and
 passed on as is without processing them any further I think it is Ok
 to just provide a single bulk call that covers all four cases
 instead of four individual ones.
 
 Hope that makes sense?
 

It definitely make sense. I actually wanted to introduce
'get_process_proc_file()' function, but I didn't do that because
'procfs_file_alloca' is a macro and its last argument must be a string
literal, so I couldn't use the following construction:

p = procfs_file_alloca(pid, filename);

I forgot to mention this fact in the commit message.

New version will arrive soon.

Thanks for the review!


Jakub

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


Re: [systemd-devel] plans/roadmap for mdns support in resolved

2014-11-21 Thread Vasiliy Tolstov
2014-11-21 3:29 GMT+03:00 Lennart Poettering lenn...@poettering.net:
 LLMNR/mDNS are really about zeroconf, i.e. something you don't
 really have to configure to work... Hence each time we add an option
 to configure it we kinda work against the whole concept...

Additional option does not needs to be configure by default. For
example by default
resolved use all interfaces to resolve name via all interfaces based
on per-link addresses.
And publish all addresses from multicast interfaces to hostname.
But if user wants to say - publish address from specific interface,
and listen for multicast on specific interface,
all works like i want =).


 Can't you just add the address to all of your interfaces, and give
 them a low priority there, so that they aren't used as source address
 there?


I don't know about this and i think that its more ugly =(

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] /usr vs /etc for default distro units enablement

2014-11-21 Thread Colin Guthrie
Hello again!

Didier Roche wrote on 18/11/14 15:40:
 Le 18/11/2014 15:59, Colin Guthrie a écrit :
 Hiya,
 Hey,
 Didier Roche wrote on 18/11/14 13:58:
 This would be maybe a nice way for the admin to know what's coming from
 a distribution default or not. However, let's say I want to ensure that
 ssh will always be available on my server, I would (even if it's in my
 server preset) then systemctl enable openssh, no matter whatever future
 preset updates does (like disable it in the next batch upgrade).
 For the avoidance of doubt, I believe that running systemctl preset
 should only ever happen on *first* install, never on upgrade or such
 like.

 This also avoids any problems here.

 (Of course if /etc is nuked, then reapplying the defaults from *.preset
 should be done!)
 
 See my Michael's answer (and my previous one) on the fact that maybe the
 preset files would be part of multiple packages (to disable certain
 units), and some being only part of packages not installed by default.
 Michael's case as well of a unit changing its target on a package
 upgrade (as a packaging fix, maybe) is valid as well.

I think the distro-wide preset usage would be in a very core package
that is likely installed very early on (perhaps even the package is
required by the one that ships systemctl and thus has to be installed
first).

If you end up shipping random .preset files with the actual packages
containing the units they affect (which isn't recommend as previously
noted, but perhaps you still want to do it that way for some special
cases) then this too will be fine.

I can see some complications here but nothing that isn't manageable.


 With a shared distro/admin /etc, we have no way to take that fact into
 account and the next one would follow distro policy, right?
 Yeah, but that's assuming there *is* a next one. Once things are
 installed, the user should *not* be surprised by any action being taken
 without their consent on upgrade.

 FWIW, it's probably worth considering how you'd handle not changing
 users current preferences with regards to enabling/disabling things on
 upgrade. I can see this being quite hard for you roll out with your
 current suggestions, but you may have this covered already.
 
 Actually, this reminds me some issues we had with gconf in the past in
 changing distribution's default and deciphering what was users current
 preference or what was distro default behavior.
 Gnome-panel was copying its whole distro defaults in ~/.gconf.
 Adding/removing some default layouts and settings from the panel was
 then unnecessary difficult. Some changes was part of new default
 behaviors we wanted that the user never interacted with and was desired
 to be changed (because of some applets getting low maintenance,
 incompatible with newer technology or duplicates…)
 As everything was at the same place, it was difficult to know if the
 current value was set because of the previous default, or if the user
 explicitly tweaked and then selected it.
 
 I see the same issue with the shared /etc: is this unit enabled for that
 target because of one the preset config, or did the admin run systemctl
 enable unit explicitly and want to keep it? I think it's ok to change
 distro defaults on upgrade (will be potentially in major version upgrade
 of course), not user (admin here) preferences, of course.

I would personally disagree with this statement that it's OK to change
the distro defaults on upgrade. As an admin, whether I observe some
behaviour but do not actively reinforce it (e.g. I see that installing
httpd enables it by default and thus my server is working fine, so I
don't need to do systemctl enable httpd manually) I now rely on the
distro default. If that was to be changed on upgrade (whether package or
whole distro), I'd personally be really annoyed!

With the goal of being able to reset things (i.e. trashing /etc) if
desired, the admin has a pretty good choice to start again with a clean
slate after a distro upgrade if they so wish. Otherwise I'd very much
expect my system to retain as much state as possible (whether that may
have come from a preset or an active choice is, IMO, irrelevant - it's
how the system was ultimately configured and what the admin now relies
on) over the distro upgrade process.

 But we do have
 no way to know for sure which is which in the current system.

Yeah, I accept this is a limitation of the current system. I guess I'm
just making the argument that, IMO, this detail doesn't matter as I
don't see the need to use this information for anything automated anyway.


 Also, after running systemctl enable opensshn, systemctl status openssh
 will still say enabled (preset) even if the admin wanted to stick it
 for good as it's part of the preset.
 Not sure what you mean by stick it for good here, but my previous
 suggestion was to say enabled [preset: enabled] or enabled [preset:
 disabled] accordingly which might be clearer (if a bit longer).
 
 Same than in previous case:
 I 

Re: [systemd-devel] newer systemd for rhel7/centos7

2014-11-21 Thread Lukáš Nykrýn
Rahul Sundaram píše v Čt 20. 11. 2014 v 20:20 -0500:
 Hi
 
 On Thu, Nov 20, 2014 at 11:24 AM, Lukáš Nykrýn wrote:
 Hi,
 
 rhel7 / centos7 is shipped with heavily patched systemd 208,
 which does
 not contain new interesting features and for us it is a
 backporting
 nightmare.
 
 I have prepared an experimental repo with newer version of
 systemd for
 epel7.
 
 
 I don't mind doing that if the goal here is eventually rebase in
 RHEL/CentOS.  If not, I won't be investing time on it
 
Unfortunately this is not completely up to me. But personally I would
like to see it in rhel/centos soon.

Lukas 
 
 Rahul
 
 ___
 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] newer systemd for rhel7/centos7

2014-11-21 Thread Andrei Borzenkov
On Thu, Nov 20, 2014 at 9:10 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:

 On 11/20/2014 04:24 PM, Lukáš Nykrýn wrote:

 Hi,

 rhel7 / centos7 is shipped with heavily patched systemd 208, which does
 not contain new interesting features and for us it is a backporting
 nightmare.

 I have prepared an experimental repo with newer version of systemd for
 epel7. Currently it is based on 217 from Fedora rawhide and final goal
 should be 218.

 If you are interested, here is a COPR build. Feedback and bug reports
 are as always highly appreciated.

 https://copr.fedoraproject.org/coprs/lnykryn/systemd/

 Lukas


 Wont you break your RHEL support if you run this?


Is not EPEL applicable to CentOS as well?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH v2] Improving systemd-nspawn@.service (container dir/nonpersistant journal)

2014-11-21 Thread Lennart Poettering
On Fri, 21.11.14 09:49, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello Lennart,
 
 Lennart Poettering [2014-11-21  0:36 +0100]:
  So far we prefixed all variables parsed from command line arguments
  with arg_, please follow the same scheme for this.
 
 Ah, sure. Done.

Thanks! Applied!

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] selinux-access: fix broken ternary operator

2014-11-21 Thread Lukas Nykryn
it seems to be a typo introduced by ebcf1f97de4f6b1580ae55eb56b1a3939fe6b602
-_r = selinux_access_check(_b, _m, _u-source_path 
?:_u-fragment_path, (permission), _error); \
+({ Unit *_unit = (unit); selinux_generic_access_check(bus,message, 
_unit-fragment_path ?: _unit-fragment_path, permission,error); })
---
 src/core/selinux-access.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/selinux-access.h b/src/core/selinux-access.h
index bccf0d2..dd1e8bb 100644
--- a/src/core/selinux-access.h
+++ b/src/core/selinux-access.h
@@ -40,7 +40,7 @@ int mac_selinux_unit_access_check_strv(char **units, 
sd_bus_message *message, Ma
 #define mac_selinux_unit_access_check(unit, message, permission, error) \
 ({  \
 Unit *_unit = (unit);   \
-mac_selinux_generic_access_check((message), 
_unit-fragment_path ?: _unit-fragment_path, (permission), (error)); \
+mac_selinux_generic_access_check((message), _unit-source_path 
?: _unit-fragment_path, (permission), (error)); \
 })
 
 #else
-- 
1.8.3.1

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


[systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd

2014-11-21 Thread Łukasz Stelmach
On a system configured without networkd and sysusers there still needs
to be the unnecessary systemd-network user, otherwise systemd-tmpfiles
fails to start.

Move information associated with networkd in tmpfiles.d and sysusers.d
to separate files. Do not install it if netwrorkd is not enabled.
---
Alternatively the files may be prepared to be processed with M4, which may
be useful to conditionaly include lines for other optional services.

 Makefile.am  | 10 ++
 sysusers.d/systemd-networkd.conf |  8 
 sysusers.d/systemd.conf  |  1 -
 tmpfiles.d/systemd-networkd.conf | 12 
 tmpfiles.d/systemd.conf  |  3 ---
 5 files changed, 30 insertions(+), 4 deletions(-)
 create mode 100644 sysusers.d/systemd-networkd.conf
 create mode 100644 tmpfiles.d/systemd-networkd.conf

diff --git a/Makefile.am b/Makefile.am
index 3f9f3fa..8f0f290 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5164,6 +5164,16 @@ networkctl_LDADD = \
libsystemd-shared.la \
libsystemd-network.la
 
+if ENABLE_TMPFILES
+dist_tmpfiles_DATA += \
+   tmpfiles.d/systemd-networkd.conf
+endif
+
+if ENABLE_SYSUSERS
+dist_sysusers_DATA += \
+   sysusers.d/systemd-networkd.conf
+endif
+
 test_network_SOURCES = \
src/network/test-network.c
 
diff --git a/sysusers.d/systemd-networkd.conf b/sysusers.d/systemd-networkd.conf
new file mode 100644
index 000..208148d
--- /dev/null
+++ b/sysusers.d/systemd-networkd.conf
@@ -0,0 +1,8 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+u systemd-network   - systemd Network Management
diff --git a/sysusers.d/systemd.conf b/sysusers.d/systemd.conf
index 95437b8..3da0901 100644
--- a/sysusers.d/systemd.conf
+++ b/sysusers.d/systemd.conf
@@ -7,6 +7,5 @@
 
 g systemd-journal   - -
 u systemd-bus-proxy - systemd Bus Proxy
-u systemd-network   - systemd Network Management
 u systemd-resolve   - systemd Resolver
 u systemd-timesync  - systemd Time Synchronization
diff --git a/tmpfiles.d/systemd-networkd.conf b/tmpfiles.d/systemd-networkd.conf
new file mode 100644
index 000..2419755
--- /dev/null
+++ b/tmpfiles.d/systemd-networkd.conf
@@ -0,0 +1,12 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+# See tmpfiles.d(5) for details
+
+d /run/systemd/netif 0755 systemd-network systemd-network -
+d /run/systemd/netif/links 0755 systemd-network systemd-network -
+d /run/systemd/netif/leases 0755 systemd-network systemd-network -
diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf
index 9ca5ad2..57fc261 100644
--- a/tmpfiles.d/systemd.conf
+++ b/tmpfiles.d/systemd.conf
@@ -16,9 +16,6 @@ d /run/systemd/sessions 0755 root root -
 d /run/systemd/users 0755 root root -
 d /run/systemd/machines 0755 root root -
 d /run/systemd/shutdown 0755 root root -
-d /run/systemd/netif 0755 systemd-network systemd-network -
-d /run/systemd/netif/links 0755 systemd-network systemd-network -
-d /run/systemd/netif/leases 0755 systemd-network systemd-network -
 
 d /run/log 0755 root root -
 
-- 
1.9.1

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


[systemd-devel] [PATCH] rpcbind: systemd socket activation

2014-11-21 Thread Steve Dickson
This is a re-post of Tom's patch he posted a while back.
I made the following changes.

* Reorganized the changes so the diff is more readable
  by using a goto instead of indenting 268 lines.

* Removed the systemd scripts because they just didn't
  work and won't going to work. I did spend some time 
  on them but debugging was not worth the time since 
  the current ones worked. I'm more than willing to 
  revisit this down the line.

Finally I would like to thank Tom for all of his help! 
It was much appreciated!

Tom Gundersen (1):
  rpcbind: add support for systemd socket activation

 Makefile.am   |  6 +
 configure.ac  | 10 
 src/rpcbind.c | 81 ++-
 3 files changed, 91 insertions(+), 6 deletions(-)

-- 
2.1.0

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


Re: [systemd-devel] newer systemd for rhel7/centos7

2014-11-21 Thread Rahul Sundaram
Hi

On Fri, Nov 21, 2014 at 6:36 AM, Andrei Borzenkov  wrote:

 On Thu, Nov 20, 2014 at 9:10 PM, Jóhann B. Guðmundsson
   wrote:
 
  Wont you break your RHEL support if you run this?
 

 Is not EPEL applicable to CentOS as well?


It is a misconception that installing a package by itself would break any
support contracts in the first place and one that has been corrected
multiple times.  In addition to that,  EPEL is applicable to rebuilds of
RHEL including but not limited to CentOS and Scientific Linux.   It is also
easy enough to spin a new instance of RHEL without activating the
subscription for the purpose of testing as well.

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


Re: [systemd-devel] [RFC 1/4] use libmount to enumerate /proc/self/mountinfo

2014-11-21 Thread Chris Leech
On Sat, Nov 15, 2014 at 02:09:26PM +0100, Tom Gundersen wrote:
 Usually we don't do this kind of fallback, but rather disable the relevant
 functionality if the lib is not available.
 
 In this case I guess it means making support for .mount units optional. I
 could imagine someone doing that in very specialised use cases, but maybe
 it makes more sense to make the library a hard dependency for now...

OK, I was following the optional lead from libblkid and I guess thinking
about non util-linux/libmount mount implementations (busybox?).

But I see that util-linux is listed as a hard dependency anyway, so I'll
remove the fallback code and send updated patches.

- Chris

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


Re: [systemd-devel] [RFC 4/4] add remote-fs dependencies if needed after change

2014-11-21 Thread Chris Leech
On Sun, Nov 09, 2014 at 08:32:05AM +0300, Andrei Borzenkov wrote:
 В Thu,  6 Nov 2014 21:11:03 -0800
 Chris Leech cle...@redhat.com пишет:
 
  This is an attempt to add it the remote-fs dependencies to a mount unit
  if the options change, like when the utab options are picked up after
  mountinfo has already been processed.  It just adds the remote-fs
  dependencies, leaving the local-fs ones in place.
  
  With this change I always get mount units with proper remote-fs
  dependencies when mounted with the _netdev option.
  
  It it not working for -o remount,_netdev.  But that looks like a
  libmount issue in that the ROOT field is not being set in utab on a
  remount, so if the initial mount did not require a utab entry then
  remount options never get merge in properly in mnt_table_parse_mtab
  ---
   src/core/mount.c | 13 +
   1 file changed, 13 insertions(+)
  
  diff --git a/src/core/mount.c b/src/core/mount.c
  index 7d77021..092a720 100644
  --- a/src/core/mount.c
  +++ b/src/core/mount.c
  @@ -1436,6 +1436,19 @@ static int mount_add_one(
   }
   }
   
  +if (m-running_as == SYSTEMD_SYSTEM) {
  +const char* target;
  +
  +target = mount_needs_network(options, fstype) ?  
  SPECIAL_REMOTE_FS_TARGET : NULL;
  +/* _netdev option may have shown up late, or on a
  + * remount. Add remote-fs dependencies, even though
  + * local-fs ones may already be there */
  +if (target) {
  +unit_add_dependency_by_name(u, 
  UNIT_BEFORE, target, NULL, true);
  +load_extras = true;
  +}
  +}
 
 Should not it also add After on network.target to ensure it is
 unmounted before network is down on shutdown? May be simply calling
 mount_add_default_dependencies() would be appropriate here.

Setting load_extras to true causes mount_add_extras to be called further
down in this function, which calls mount_add_default_dependencies.

So in testing I did see the After get added as well.  But if there's a
better way to clean up the mount unit adding code I'm all for it.

- Chris

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


Re: [systemd-devel] [BUG] too many rfkill services

2014-11-21 Thread Andrei Borzenkov
В Fri, 21 Nov 2014 01:26:36 +0100
Lennart Poettering lenn...@poettering.net пишет:

 On Thu, 20.11.14 19:56, Lukasz Stelmach (stl...@poczta.fm) wrote:
 
  I talked to the kernel guys at my office and they told me that it is
  quite usual (at least for USB devices, and my wlan and bt are USB)
  that devices are stopped and unregistered in the kernel before
  a system is suspended end reported as completely new ones
  with increased numbers after machine resumes.
 
 So, I have now added some code that adds BindsTo= for the device unit
 to the service.

It does not seem to work.

bor@opensuse:~ systemctl status systemd-rfkill@rfkill0.service
systemd-rfkill@rfkill0.service - Load/Save RF Kill Switch Status of rfkill0
   Loaded: loaded (/usr/lib/systemd/system/systemd-rfkill@.service; static)
  Drop-In: /etc/systemd/system/systemd-rfkill@.service.d
   └─bind.conf
   Active: active (exited) since Пт 2014-11-21 06:52:40 MSK; 15h ago
 Docs: man:systemd-rfkill@.service(8)
  Process: 636 ExecStart=/usr/lib/systemd/systemd-rfkill load %I (code=exited, 
status=0/SUCCESS)
 Main PID: 636 (code=exited, status=0/SUCCESS)
   CGroup: 
/system.slice/system-systemd\x2drfkill.slice/systemd-rfkill@rfkill0.service

bor@opensuse:~ systemctl --no-pager show -p BindsTo 
systemd-rfkill@rfkill0.service
BindsTo=sys-subsystem-rfkill-devices-rfkill0.device
bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill0.device
sys-subsystem-rfkill-devices-rfkill0.device
   Loaded: loaded
   Active: inactive (dead)

bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill1.device
sys-subsystem-rfkill-devices-rfkill1.device
   Loaded: loaded
   Active: inactive (dead)

bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill2.device
sys-subsystem-rfkill-devices-rfkill2.device
   Loaded: loaded
   Active: inactive (dead)

bor@opensuse:~ systemctl --full | grep rfkill
sys-devices-pci:00-:00:1a.0-usb3-3\x2d2-3\x2d2.1-3\x2d2.1:1.0-bluetooth-hci0-rfkill2.device
 loaded active plugged   
/sys/devices/pci:00/:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2
sys-devices-pci:00-:00:1c.1-:0c:00.0-ieee80211-phy0-rfkill1.device  
loaded active plugged   
/sys/devices/pci:00/:00:1c.1/:0c:00.0/ieee80211/phy0/rfkill1
systemd-rfkill@rfkill0.service  
loaded active exitedLoad/Save RF Kill Switch Status of 
rfkill0
systemd-rfkill@rfkill1.service  
loaded active exitedLoad/Save RF Kill Switch Status of 
rfkill1
systemd-rfkill@rfkill2.service  
loaded active exitedLoad/Save RF Kill Switch Status of 
rfkill2
system-systemd\x2drfkill.slice  
loaded active activesystem-systemd\x2drfkill.slice
bor@opensuse:~ LC_ALL=C ll /sys/class/rfkill/
total 0
lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill1 - 
../../devices/pci:00/:00:1c.1/:0c:00.0/ieee80211/phy0/rfkill1
lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill2 - 
../../devices/pci:00/:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2


 This won't fix much though, as the service is likely
 to fail in ExecStop= because it cannot find the device anymore.
 

Should not it be garbage collected at some point (assuming it is
properly stopped that is)?

 For cases like this the tool is entirely useless I figure, since it
 can only save the rfkill state at shutdown now, but not on
 unplug. This means each time the device appears as hotplug we restore
 the state that was set during boot, but not the state from right
 before we went to suspend.
 
 I figure the only proper fix for this is to make some daemon take
 responsibility, listen to events and store things to disk each time
 the setting changes... Not too enthusiastic about adding that
 though...
 
 Lennart
 

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


Re: [systemd-devel] [PATCH 4/4] coredump: collect all /proc data useful for bug reporting

2014-11-21 Thread Lennart Poettering
On Wed, 19.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:

 +/* Joins /proc/[pid]/fd/ and /proc/[pid]/fdinfo/ into the following lines:
 + *
 + * 0:/dev/pts/23
 + * pos:0
 + * flags:  012
 + * 1:/dev/pts/23
 + * pos:0
 + * flags:  012
 + * 2:/dev/pts/23

Hmm, I'd prefer a format here that is more easily reversible. For
example, adding an extra newline between the fdinfo items would be a
good start.

 + *
 + */
 +static int compose_open_fds(pid_t pid, char **open_fds) {
 +const char *fd_name = NULL, *fdinfo_name = NULL;

const? why?

 +char *outcome = NULL;
 +size_t len = 0, allocated = 0;
 +char line[LINE_MAX];
 +unsigned fd = 0;
 +int r = 0;
 +
 +assert(pid = 0);
 +
 +fd_name = alloca(strlen(/proc//fd/) + DECIMAL_STR_MAX(pid_t) + 
 DECIMAL_STR_MAX(unsigned) + 1);

^^^

unsigned? an fd is an int!  

 +fdinfo_name = alloca(strlen(/proc//fdinfo/) + 
 DECIMAL_STR_MAX(pid_t) + DECIMAL_STR_MAX(unsigned) + 1);

same here.

The sizes you allocate here are fixed. I'd really prefer if you'd
allocate these as normal arrays instead of alloca(). alloca() is a
useful tool, but we should use it only when normal arrays aren't good
denough, but not otherwise.

Also note that alloca() cannot be mixed with function calls in the
same line. strlen() is a function call (though one that today's gcc
actually is smart enough to optimize away at compile time if you
invoke it on a literal string). 

Hence, please use this instead:

char fd_name[sizeof(/proc/)-1 + DECIMAL_STR_MAX(pid_t) + sizeof(/fd/)-1 + 
DECIMAL_STR_MAX(int) + 1];

 +
 +while (fd = 9) {

Oh no, this is not OK!

We shouldn't iterate though all thinkable fds, that's bad code. Please
iterate through /proc/$PID/fd/ and just operate on fds that are
actually there.

 +_cleanup_free_ char *name = NULL;
 +_cleanup_fclose_ FILE *fdinfo = NULL;
 +
 +sprintf((char *)fd_name, /proc/PID_FMT/fd/%u, pid, fd);

Hmm, first you declare the string as const, then you cast this away?
This is usually a good indication that something is really wrong...

 +r = readlink_malloc(fd_name, name);
 +if (r  0) {
 +if (r == -ENOENT) {
 +*open_fds = outcome;
 +r = 0;
 +}
 +else
 +free(outcome);
 +
 +break;
 +}
 +
 +if (!GREEDY_REALLOC(outcome, allocated, len + strlen(name) + 
 DECIMAL_STR_MAX(unsigned) + 3))
 +return -ENOMEM;
 +
 +len += sprintf(outcome + len, %u:%s\n, fd, name);
 +++fd;
 +
 +sprintf((char *)fdinfo_name, /proc/PID_FMT/fdinfo/%u, 
 pid, fd);
 +fdinfo = fopen(fdinfo_name, r);
 +if (fdinfo == NULL)
 +continue;
 +
 +while(fgets(line, sizeof(line), fdinfo) != NULL) {
 +if (!GREEDY_REALLOC(outcome, allocated, len + 
 strlen(line) + 2))
 +return -ENOMEM;
 +
 +len += sprintf(outcome + len, %s, line);
 +if (strchr(line, '\n') == NULL) {
 +outcome[len++] = '\n';
 +outcome[len] = '\0';
 +}

 +}

I think using libc's open_memstream() and then simply writing to it
would be a *ton* prettier than this.

Lennart

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


[systemd-devel] systemctl list-dependencies: consider BindsTo as well?

2014-11-21 Thread Peter Mattern

Hello.

Right now systemctl's command list-dependencies is considering 
parameters Wants and Requires only.


But given that command's purpose I was wondering whether it wouldn't 
make sense to have it consider BindsTo as well.


Regards,

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


Re: [systemd-devel] [PATCH] selinux-access: fix broken ternary operator

2014-11-21 Thread Lennart Poettering
On Fri, 21.11.14 17:02, Lukas Nykryn (lnyk...@redhat.com) wrote:

 it seems to be a typo introduced by ebcf1f97de4f6b1580ae55eb56b1a3939fe6b602
 -_r = selinux_access_check(_b, _m, _u-source_path 
 ?:_u-fragment_path, (permission), _error); \
 +({ Unit *_unit = (unit); selinux_generic_access_check(bus,message, 
 _unit-fragment_path ?: _unit-fragment_path, permission,error); })

Looks good! Applied!

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] networkd: disable tmpfiles and sysusers bits associated with networkd

2014-11-21 Thread Lennart Poettering
On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote:

 On a system configured without networkd and sysusers there still needs
 to be the unnecessary systemd-network user, otherwise systemd-tmpfiles
 fails to start.
 
 Move information associated with networkd in tmpfiles.d and sysusers.d
 to separate files. Do not install it if netwrorkd is not enabled.

In principle looks OK, but I'd prefer if we would write this out with
m4 (see etc.conf.m4) and keep it in the current files, rather than
split this up in numerous files.

Especially in the case of /run/systemd/netif this actually matters: if
we split that out into its own tmpfiles snippet, then packagers would
most likely put that in its own RPM/DEB if they split out those
daemons. But this is not advisable in this case, as sd-network (which
will eventually be a public API of libsystems) needs the directory to
be around to install an inotify watch. If the directory doesn't exist,
and the API is used it will fail entirely, which is suboptimal, given
that networkd might be installed later on, and things should then just
start to work.

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] nspawn: ignore EEXIST when mounting tmpfs

2014-11-21 Thread Richard Schütz
commit 79d80fc1466512d0ca211f4bfcd9de5f2f816a5a introduced a regression that
prevents mounting a tmpfs if the mount point already exits in the container's
root file system. This commit fixes the problem by ignoring EEXIST.
---
 src/nspawn/nspawn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index b4dcf39..10a520c 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -828,7 +828,7 @@ static int mount_tmpfs(const char *dest) {
 return log_oom();
 
 r = mkdir_label(where, 0755);
-if (r  0) {
+if (r  0  errno != EEXIST) {
 log_error(creating mount point for tmpfs %s failed: 
%s, where, strerror(-r));
 
 return r;
-- 
2.1.3

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