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 
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
 no,
 host,
+try-host,
 guest,
+try-guest,
 auto. If
 no, the journal is
 not linked. If host,
@@ -453,8 +455,11 @@
 guest file system (beneath
 /var/log/journal/machine-id)
 and the subdirectory is symlinked into the host
-at the same location. If
-auto (the default),
+at the same location. try-host
+and try-guest do the same
+but do not fail if the host does not have
+persistant journalling enabled.
+If auto (the default),
 and the right subdirectory of
 /var/log/journal
 exists, it will be bind mounted
@@ -473,7 +478,7 @@
 -j
 
 Equivalent to
---link-journal=guest.
+--link-journal=try-guest.
 
 
 
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':
 arg_link_journal = LINK_GUEST;
+arg_link_journal_try = true;
 break;
 
 case ARG_LINK_JOURNAL:
@@ -439,7 +442,13 @@ static int parse_argv(int argc, char *argv[]) {
 arg_link_journal = LINK_GUEST;
 else if (streq(opt

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 :
> 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 " 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 [p

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"
 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


[systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

2014-11-21 Thread Steve Dickson
From: Tom Gundersen 

Making rpcbind sockect activated will greatly simplify
its integration in systemd systems. In essence, other services
may now assume that rpcbind is always available, even during very
early boot. This means that we no longer need to worry about any
ordering dependencies.

This is based on a patch originally posted by Lennart Poettering:
.

That patch was not merged due to the lack of a shared library and
as systemd was seen to be too Fedora specific.

Systemd now provides a shared library, and it is (or very soon will
be) the default init system on all the major Linux distributions.

This version of the patch has three changes from the original:

 * It uses the shared library.
 * It comes with unit files.
 * It is rebased on top of master.

Please review the patch with "git show -b" or otherwise ignoring the
whitespace changes, or it will be extremely difficult to read.

v4: reorganized the changes to make the diff easier to read
remove systemd scripts.

v3: rebase
fix typos
listen on /run/rpcbind.sock, rather than /var/run/rpcbind.sock (the
latter is a symlink to the former, but this means the socket can be
created before /var is mounted)
NB: this version has been compile-tested only as I no longer use
rpcbind myself
v2: correctly enable systemd code at compile time
handle the case where not all the required sockets were supplied
listen on udp/tcp port 111 in addition to /var/run/rpcbind.sock
do not daemonize

Original-patch-by: Lennart Poettering 
Cc: Steve Dickson 
Cc: systemd-devel@lists.freedesktop.org
Acked-by: Cristian Rodríguez
Signed-off-by: Tom Gundersen 
Signed-off-by: Steve Dickson 
---
 Makefile.am   |  6 +
 configure.ac  | 10 
 src/rpcbind.c | 81 ++-
 3 files changed, 91 insertions(+), 6 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 8715082..c99566d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -41,6 +41,12 @@ rpcbind_SOURCES = \
src/warmstart.c
 rpcbind_LDADD = $(TIRPC_LIBS)
 
+if SYSTEMD
+AM_CPPFLAGS += $(SYSTEMD_CFLAGS) -DSYSTEMD
+
+rpcbind_LDADD += $(SYSTEMD_LIBS)
+endif
+
 rpcinfo_SOURCES =   src/rpcinfo.c
 rpcinfo_LDADD   =   $(TIRPC_LIBS)
 
diff --git a/configure.ac b/configure.ac
index 5a88cc7..fdad639 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,6 +36,16 @@ AC_SUBST([nss_modules], [$with_nss_modules])
 
 PKG_CHECK_MODULES([TIRPC], [libtirpc])
 
+PKG_PROG_PKG_CONFIG
+AC_ARG_WITH([systemdsystemunitdir],
+  AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd 
service files]),
+  [], [with_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir 
systemd)])
+  if test "x$with_systemdsystemunitdir" != xno; then
+AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])
+PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon])
+  fi
+AM_CONDITIONAL(SYSTEMD, [test -n "$with_systemdsystemunitdir" -a 
"x$with_systemdsystemunitdir" != xno ])
+
 AS_IF([test x$enable_libwrap = xyes], [
AC_CHECK_LIB([wrap], [hosts_access], ,
AC_MSG_ERROR([libwrap support requested but unable to find 
libwrap]))
diff --git a/src/rpcbind.c b/src/rpcbind.c
index e3462e3..f7c71ee 100644
--- a/src/rpcbind.c
+++ b/src/rpcbind.c
@@ -56,6 +56,9 @@
 #include 
 #endif
 #include 
+#ifdef SYSTEMD
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -296,6 +299,7 @@ init_transport(struct netconfig *nconf)
u_int32_t host_addr[4];  /* IPv4 or IPv6 */
struct sockaddr_un sun;
mode_t oldmask;
+   int n;
 res = NULL;
 
if ((nconf->nc_semantics != NC_TPI_CLTS) &&
@@ -314,6 +318,76 @@ init_transport(struct netconfig *nconf)
fprintf(stderr, "[%d] - %s\n", i, *s);
}
 #endif
+   if (!__rpc_nconf2sockinfo(nconf, &si)) {
+   syslog(LOG_ERR, "cannot get information for %s",
+   nconf->nc_netid);
+   return (1);
+   }
+
+#ifdef SYSTEMD
+   n = sd_listen_fds(0);
+   if (n < 0) {
+   syslog(LOG_ERR, "failed to acquire systemd sockets: %s", 
strerror(-n));
+   return 1;
+   }
+
+   /* Try to find if one of the systemd sockets we were given match
+* our netconfig structure. */
+
+   for (fd = SD_LISTEN_FDS_START; fd < SD_LISTEN_FDS_START + n; fd++) {
+   struct __rpc_sockinfo si_other;
+   union {
+   struct sockaddr sa;
+   struct sockaddr_un un;
+   struct sockaddr_in in4;
+   struct sockaddr_in6 in6;
+   struct sockaddr_storage storage;
+   } sa;
+   socklen_t addrlen = sizeof(sa);
+
+   if (!__rpc_fd2sockinfo(fd, &si_other)) {
+   syslog(LOG_ERR, "cannot get information for fd %i", fd);
+   return 

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  пишет:
> 
> > 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  пишет:

> 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