[systemd-devel] [PATCH v2 1/2] util: add function getting proc environ

[Jakub Filak]

On the contrary of env, the added function returns all characters
cescaped, because it improves reproducibility.
---
 src/shared/util.c| 154 ---
 src/shared/util.h|   1 +
 src/test/test-util.c |   5 ++
 3 files changed, 103 insertions(+), 57 deletions(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index 0166052..94e8ed6 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -174,6 +174,69 @@ char* first_word(const char *s, const char *word) {
 return (char*) p;
 }
 
+static size_t cescape_char(char c, char *buf) {
+char * buf_old = buf;
+
+switch (c) {
+
+case '\a':
+*(buf++) = '\\';
+*(buf++) = 'a';
+break;
+case '\b':
+*(buf++) = '\\';
+*(buf++) = 'b';
+break;
+case '\f':
+*(buf++) = '\\';
+*(buf++) = 'f';
+break;
+case '\n':
+*(buf++) = '\\';
+*(buf++) = 'n';
+break;
+case '\r':
+*(buf++) = '\\';
+*(buf++) = 'r';
+break;
+case '\t':
+*(buf++) = '\\';
+*(buf++) = 't';
+break;
+case '\v':
+*(buf++) = '\\';
+*(buf++) = 'v';
+break;
+case '\\':
+*(buf++) = '\\';
+*(buf++) = '\\';
+break;
+case '"':
+*(buf++) = '\\';
+*(buf++) = '"';
+break;
+case '\'':
+*(buf++) = '\\';
+*(buf++) = '\'';
+break;
+
+default:
+/* For special chars we prefer octal over
+ * hexadecimal encoding, simply because glib's
+ * g_strescape() does the same */
+if ((c < ' ') || (c >= 127)) {
+*(buf++) = '\\';
+*(buf++) = octchar((unsigned char) c >> 6);
+*(buf++) = octchar((unsigned char) c >> 3);
+*(buf++) = octchar((unsigned char) c);
+} else
+*(buf++) = c;
+break;
+}
+
+return buf - buf_old;
+}
+
 int close_nointr(int fd) {
 assert(fd >= 0);
 
@@ -892,6 +955,39 @@ int get_process_root(pid_t pid, char **root) {
 return get_process_link_contents(p, root);
 }
 
+int get_process_environ(pid_t pid, char **environ) {
+_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *outcome = NULL;
+int c;
+const char *p;
+size_t allocated = 0, sz = 0;
+
+assert(pid >= 0);
+assert(environ);
+
+p = procfs_file_alloca(pid, "environ");
+
+f = fopen(p, "re");
+if (!f)
+return -errno;
+
+while ((c = fgetc(f)) != EOF) {
+if (!GREEDY_REALLOC(outcome, allocated, sz + 5))
+return -ENOMEM;
+
+if (c == '\0')
+outcome[sz++] = '\n';
+else
+sz += cescape_char(c, outcome + sz);
+}
+
+outcome[sz] = '\0';
+*environ = outcome;
+outcome = NULL;
+
+return 0;
+}
+
 char *strnappend(const char *s, const char *suffix, size_t b) {
 size_t a;
 char *r;
@@ -1271,63 +1367,7 @@ char *cescape(const char *s) {
 return NULL;
 
 for (f = s, t = r; *f; f++)
-
-switch (*f) {
-
-case '\a':
-*(t++) = '\\';
-*(t++) = 'a';
-break;
-case '\b':
-*(t++) = '\\';
-*(t++) = 'b';
-break;
-case '\f':
-*(t++) = '\\';
-*(t++) = 'f';
-break;
-case '\n':
-*(t++) = '\\';
-*(t++) = 'n';
-break;
-case '\r':
-*(t++) = '\\';
-*(t++) = 'r';
-break;
-case '\t':
-*(t++) = '\\';
-*(t++) = 't';
-break;
-case '\v':
-*(t++) = '\\';
-  

[systemd-devel] [PATCH v2 0/2] coredump: add journal fields useful for bug reporting

[Jakub Filak]

'util: add functions getting proc status, maps, limits, cgroup'

  I dropped this patch, because we just need to read full proc file and
  'get_process_proc_file()' function is not implementable without adding a
  wrapper function to procfs_file_alloca() macro.

'util: add function getting proc environ'

  get_process_environ() function does not use unnecessary buffer, allocates 5
  more bytes in each loop cycle and writes escaped bytes directly to the
  result memory.

'coredump: collect all /proc data useful for bug reporting'

  compose_open_fds() function uses open_memstream() and tries to open only
  existing files in /proc/[pid]/fd/

  limits, status, maps and cgroups files are obtained by calling read_full_file
  with path returned by procfs_file_alloca().

I tested these patches on Fedora Rawhide.

Jakub Filak (2):
  util: add function getting proc environ
  coredump: collect all /proc data useful for bug reporting

 src/journal/coredump.c | 156 -
 src/shared/util.c  | 154 ++--
 src/shared/util.h  |   1 +
 src/test/test-util.c   |   5 ++
 4 files changed, 257 insertions(+), 59 deletions(-)

-- 
1.8.3.1

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

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

[Jakub Filak]

/proc/[pid]:
- status
- maps
- limits
- cgroup
- cwd
- root
- environ
- fd/ & fdinfo/ joined in open_fds
---
 src/journal/coredump.c | 156 -
 1 file changed, 154 insertions(+), 2 deletions(-)

diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index 26a2010..58012d6 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -36,6 +36,7 @@
 
 #include "log.h"
 #include "util.h"
+#include "fileio.h"
 #include "strv.h"
 #include "macro.h"
 #include "mkdir.h"
@@ -461,24 +462,107 @@ static int allocate_journal_field(int fd, size_t size, 
char **ret, size_t *ret_s
 return 0;
 }
 
+/* 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
+ * pos:0
+ * flags:  012
+ * EOF
+ */
+static int compose_open_fds(pid_t pid, char **open_fds) {
+_cleanup_fclose_ FILE *stream = NULL;
+_cleanup_free_ char *outcome = NULL;
+char path[PATH_MAX], line[LINE_MAX];
+size_t ignored_size;
+const char *fddelim = "";
+struct dirent *dent = NULL;
+_cleanup_closedir_ DIR *proc_fd_dir = NULL;
+int r = 0;
+
+assert(pid >= 0);
+assert(open_fds != NULL);
+
+sprintf(path, "/proc/"PID_FMT"/fd", pid);
+proc_fd_dir = opendir(path);
+
+if (proc_fd_dir == NULL)
+return -ENOENT;
+
+stream = open_memstream(&outcome, &ignored_size);
+
+for (dent = readdir(proc_fd_dir); dent != NULL; dent = 
readdir(proc_fd_dir)) {
+_cleanup_free_ char *fdname = NULL;
+_cleanup_fclose_ FILE *fdinfo = NULL;
+
+if (dent->d_name[0] == '.' || strcmp(dent->d_name, "..") == 0)
+continue;
+
+/* Too long path is unlikely a path to valid file descriptor 
in /proc/[pid]/fd */
+/* Skip it. */
+r = snprintf(path, sizeof(path), "/proc/"PID_FMT"/fd/%s", pid, 
dent->d_name);
+if (r >= (int)sizeof(path))
+continue;
+
+r = readlink_malloc(path, &fdname);
+if (r < 0)
+return r;
+
+fprintf(stream, "%s%s:%s\n", fddelim, dent->d_name, fdname);
+fddelim = "\n";
+
+/* Use the directory entry from /proc/[pid]/fd with 
/proc/[pid]/fdinfo */
+
+/* Too long path is unlikely a path to valid file descriptor 
info in /proc/[pid]/fdinfo */
+/* Skip it. */
+r = snprintf(path, sizeof(path), "/proc/"PID_FMT"/fdinfo/%s", 
pid, dent->d_name);
+if (r >= (int)sizeof(path))
+continue;
+
+fdinfo = fopen(path, "re");
+if (fdinfo == NULL)
+continue;
+
+while(fgets(line, sizeof(line), fdinfo) != NULL)
+fprintf(stream, "%s%s", strchr(line, '\n') == NULL ? 
"\n" : "", line);
+}
+
+fclose(stream);
+stream = NULL;
+
+*open_fds = outcome;
+outcome = NULL;
+
+return 0;
+}
+
 int main(int argc, char* argv[]) {
 
 _cleanup_free_ char *core_pid = NULL, *core_uid = NULL, *core_gid = 
NULL, *core_signal = NULL,
 *core_timestamp = NULL, *core_comm = NULL, *core_exe = NULL, 
*core_unit = NULL,
 *core_session = NULL, *core_message = NULL, *core_cmdline = 
NULL, *coredump_data = NULL,
-*core_slice = NULL, *core_cgroup = NULL, *core_owner_uid = 
NULL,
+*core_slice = NULL, *core_cgroup = NULL, *core_owner_uid = 
NULL, *core_open_fds = NULL,
+*core_proc_status = NULL, *core_proc_maps = NULL, 
*core_proc_limits = NULL, *core_proc_cgroup = NULL,
+*core_cwd = NULL, *core_root = NULL, *core_environ = NULL,
 *exe = NULL, *comm = NULL, *filename = NULL;
 const char *info[_INFO_LEN];
 
 _cleanup_close_ int coredump_fd = -1;
 
-struct iovec iovec[18];
+struct iovec iovec[26];
 off_t coredump_size;
 int r, j = 0;
 uid_t uid, owner_uid;
 gid_t gid;
 pid_t pid;
 char *t;
+const char *p;
 
 /* Make sure we never enter a loop */
 prctl(PR_SET_DUMPABLE, 0);
@@ -638,6 +722,74 @@ int main(int argc, char* argv[]) {
 IOVEC_SET_STRING(iovec[j++], core_cgroup);
 }
 
+if (compose_open_fds(pid, &t) >= 0) {
+core_open_fds = strappend("COREDUMP_OPEN_FDS=", t);
+free(t);
+
+if (core_open_fds)
+IOVEC_SET_STRING(iovec[j++], core_open_fds);
+}
+
+p = procfs_file_alloca(pid, "status");
+if (read_full_file(p, &t, NULL) >= 0) {
+core_proc_stat

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

[Mantas Mikulėnas]

On Mon, Nov 24, 2014 at 5:57 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> And what does 'udevadm info /dev/sda7' and 'systemctl show dev-sda7.swap'
> and
> the same for dev-disk-by\x2dpartlabel-swap.swap?
>

Attached both.

-- 
Mantas Mikulėnas 


a.sd-show
Description: Binary data


a.udev-info
Description: Binary data


b.sd-show
Description: Binary data


b.udev-info
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Compatibility between D-Bus and kdbus

[Thiago Macieira]

Sorry for the delay in replying. I didn't have time until after KLF...

On Wednesday 01 October 2014 14:33:01 Simon McVittie wrote:
> System bus access-control policy
> 
[snip]
> If I remember correctly, the least bad solution anyone could think of
> was to introduce a new pseudo-bus-type alongside DBUS_BUS_SYSTEM (and
> its equivalent in other libraries like GDBus), perhaps called
> "DBUS_BUS_SYSTEM_UNTRUSTED" or something (better names welcome), with
> its own shared connection: connections to that bus type are not assumed
> to filter messages by their payload, and method-call recipients are
> expected to use Polkit or similar, or do their own simplistic
> access-controls like "must be uid 0" by calling GetConnectionUnixUser or
> GetConnectionCredentials on the sender's unique name.

I'm wondering if the same solution should be applied to the session bus. That 
would have the unfortunate effect that applications that aren't ported to know 
about kdbus will always fallback to proxy functionality. It would be 
unfortunate because the number of applications that need policy decisions on 
the session bust must be asymptotically close to zero.

An alternative solution would be for the "trusted" connection to check if 
there are any files in /etc/dbus-1/session.d. If there aren't, it can assume 
that trusted == untrusted.

PS: we should also find a name that conveys that you *want* the new bus type.

> I'm also very tempted to propose a syntax for an opt-in kdbus-like
> security model (which would take precedence over system.conf/system.d)
> via adding lines to .service files, so that individual services can have
> a sane security model on non-kdbus or non-Linux systems, and systemd's
> systemd-dbus1-generator could use those lines as input. If we get far
> enough with moving system services to that, maybe the transition can be
> easier.

I like this idea, with the proviso that Lennart pointed out: we need to first 
include the metadata in the dbus1 stream messages so the application can sort 
out the policy decisions like the kdbus implementation would.

> Session bus access-control policy
> =
> 
> In principle, people could configure the session bus to do the same
> elaborate access-control as the system bus. In practice, this is not a
> particularly useful thing to do, because there are many ways for
> processes running under the same uid to subvert each other, particularly
> if a LSM like SELinux or AppArmor is not used.
> 
> kdbus does not appear to make any attempt to protect a uid from itself:
> the uid that created a bus is considered to be privileged on that bus. I
> assume this means that the intention is that app sandboxing will use a
> separate Unix uid, like it does on Android?
> 
> Unless there's an outcry from people who like LSMs, I'm inclined to say
> that protecting same-uid session processes from each other is doomed to
> failure, and hence that it's OK for DBUS_BUS_SESSION to connect to kdbus
> without special precautions.

I don't understand this domain enough to be able to offer an opinion. I know 
that Tizen will want SMACK security applied even between processes of the same 
UID. I just don't know whether that maps to what Lennart said about "labels".

> Resource limits
> ===
[snip]
> In kdbus, each uid may create up to 16 buses. In dbus-daemon there is no
> limit. I do not anticipate this being a problem: the reference
> implementation of kdbus' user-space, in systemd, seems to be using a
> per-uid user bus instead of a session bus. Also, even if we continued to
> use a session bus per login, 16 sounds like a reasonable number.

Agreed. Most people I know that start more than one bus for the same user are 
doing it for nested sessions, usually for testing purposes or to keep separate 
implementations of equivalent services (early KDE Frameworks 5 releases 
recommended being separate from KDE 4, not so any more).

> In kdbus, each uid may connect to each bus up to 256 times. I think this
> is actually somewhat likely to be a practical problem: I currently have
> 46 connections to my session bus, so I'm only an order of magnitude away
> from the session breaking.
> 

Agreed again.

$ qdbus | grep -c \:
72

That's over 25% of the limit. Can this be made runtime-configurable?

> In kdbus, each connection may own up to 64 well-known names; the system
> dbus-daemon defaults to 512, and the session to 50 000. 64 is *probably*
> enough, but I could potentially see this becoming an issue for services
> that allocate one well-known name per $app_specific_thing, like
> Telepathy (one name per Connection).

Also be made configurable, but please raise the default to 256 or 512.

> In kdbus, each connection may have 256 bloom filter entries, which AIUI
> are slightly less expressive than match rules (one match rule maps to
> one or more match rules). The system dbus-daemon 

[systemd-devel] how to properly control the daemons or run advanced cmds

[Flavio Leitner]

Hello,

The Open vSwitch is comprised by two daemons. One is a database and
another is the switch itself.

Currently we have the openvswitch.service which start/stop/reload the
service (both daemons) just fine.

However, we need to support hot-upgrade which means to stop the
vswitch daemon first, run a few special commands, reload the db
daemon and only then start the vswitch daemon.

I know about creating shell helpers for non-standard commands, but
since that needs to mess up with the daemons in a particular order,
I think systemd won't like the above external actions at all.

Any suggestion on how to handle this with systemd properly?

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

[systemd-devel] [PATCH] networkd: route - allow routes without a gateway

[Gavin Li]

From: Gavin Li 

For IPv6, the kernel returns EINVAL if a route is added with the
RTA_GATEWAY attribute set to in6addr_any (::). A route without a
gateway is useful in some situations, such as layer 3 tunneling
(sit, gre, etc.).

This patch prevents the RTA_GATEWAY attribute from being added
when route.in_addr is ip6addr_any (::).
---
 src/network/networkd-route.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/src/network/networkd-route.c b/src/network/networkd-route.c
index 10d8cd9..82c9e00 100644
--- a/src/network/networkd-route.c
+++ b/src/network/networkd-route.c
@@ -118,13 +118,15 @@ int route_drop(Route *route, Link *link,
 return r;
 }
 
-if (route->family == AF_INET)
-r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY, 
&route->in_addr.in);
-else if (route->family == AF_INET6)
-r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY, 
&route->in_addr.in6);
-if (r < 0) {
-log_error("Could not append RTA_GATEWAY attribute: %s", 
strerror(-r));
-return r;
+if (!in_addr_is_null(route->family, &route->in_addr)) {
+if (route->family == AF_INET)
+r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY, 
&route->in_addr.in);
+else if (route->family == AF_INET6)
+r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY, 
&route->in_addr.in6);
+if (r < 0) {
+log_error("Could not append RTA_GATEWAY attribute: 
%s", strerror(-r));
+return r;
+}
 }
 
 if (route->dst_prefixlen) {
@@ -203,13 +205,15 @@ int route_configure(Route *route, Link *link,
 return r;
 }
 
-if (route->family == AF_INET)
-r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY, 
&route->in_addr.in);
-else if (route->family == AF_INET6)
-r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY, 
&route->in_addr.in6);
-if (r < 0) {
-log_error("Could not append RTA_GATEWAY attribute: %s", 
strerror(-r));
-return r;
+if (!in_addr_is_null(route->family, &route->in_addr)) {
+if (route->family == AF_INET)
+r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY, 
&route->in_addr.in);
+else if (route->family == AF_INET6)
+r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY, 
&route->in_addr.in6);
+if (r < 0) {
+log_error("Could not append RTA_GATEWAY attribute: 
%s", strerror(-r));
+return r;
+}
 }
 
 if (route->dst_prefixlen) {
-- 
2.1.3

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

Re: [systemd-devel] Shutdown problems

[Nikolaus Rath]

Nikolaus Rath  writes:
> On 11/13/2014 12:54 PM, Nikolaus Rath wrote:
>> Nikolaus Rath  writes:
>>> Lennart Poettering  writes:
 On Sat, 08.11.14 11:16, Nikolaus Rath (nikol...@rath.org) wrote:

>> Please boot with "systemd.log_level=debug", then make the machine hang
>> and check what the last things in the logs say. Maybe then paste that
>> somewhere online and post the URL for that here, so that we can have a
>> look.
>
> Here's the output (obtained by changing log level and remounting earlier
> in the debug.sh script):
>
> https://dl.dropboxusercontent.com/u/11545826/shutdown.log
>
> Thanks for your help!

 Hmm the logs show that systemd pretty much completed its
 shutdown. After the message "Cannot finalize remaining DM devices,
 continuing." the only thing that still runs is the shutdown hooks you
 used to generate this log, plus either a jump back into your initrd
 (if your initrd supports that) or the reboot() system call. 

 If the latter hangs then it's a kernel bug.
>>>
>>> reboot -f works fine - could it still be a kernel bug?
>>>
 Please check if there are any other scripts in
 /lib/systemd/system-shutdown/ that might be at fault here.
>>>
>>> Nope, none.
>>>
 Please check if your initrd is one of those which support jumping back
 into the initrd on shutdown. For that check if /run/initramfs/shutdown
 exists during runtime and is executable.
>>>
>>> No, /run/initramfs/shutdown does not exist.
>>>
 If so, it's probably an
 initrd problem, please file a bug against your initrd implementation.

 You appear to be using LVM, I wouldn't be surprised if LVM is broken
 here, but I cannot help you debugging this, please contact the LVM
 maintainers in this case.
>>>
>>> Is there some indication that LVN is at fault? As I said in my first
>>> email, the crucial difference seems to be if an X11 console is active or
>>> not:
>>>
>>>  * If I execute "systemctl reboot" while a text console is active,
>>>everything works fine.
>>>
>>>  * If I execute "systemctl reboot" while the X11 console is active, the
>>>system hangs (I tried waiting up to 7 minutes). Furthermore, I am
>>>unable to switch to another console with Ctrl+Alt+Fn, the computer
>>>becomes unresponsive to the keyboard and the monitor powers down.
>>>
>>> On which tty/pty systemctl itself is executed does not matter (I tested
>>> this by running systemctl in an ssh session from a remote system), it
>>> only matters which console is currently active.
>> 
>> Some more information:
>> 
>> * if I start a debug-shell on a serial port, at some point the shell
>> seems to freeze as well.
>> 
>> * if I boot with sysvinit instead of systemd things work fine:
>> 
>>   - The system reboots even if an X11 console is active
>>   - During the shutdown, I can switch between text consoles and see
>> log messages
>> 
>> Any ideas?
>
> On a whim, I also tried blacklisting the nouveau module and using the
> integrated graphics with the i915 module instead. It did not make a
> difference.

*ping*. Really no one able to help with this?


Thanks,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] networkd: route - allow routes without a gateway

[Lennart Poettering]

On Mon, 24.11.14 12:01, Gavin Li (gavi...@thegavinli.com) wrote:

> For IPv6, the kernel returns EINVAL if a route is added with the
> RTA_GATEWAY attribute set to in6addr_any (::). A route without a
> gateway is useful in some situations, such as layer 3 tunneling
> (sit, gre, etc.).
> 
> This patch prevents the RTA_GATEWAY attribute from being added
> when route.in_addr is ip6addr_any (::).

Patch is line-broken. It's hard to review it and we cannot apply it
this way. Please resend non-line-broken version. If your mailer
doesn't allow that, just attach the git-format-patch formatted patch
to your email.

> ---
>  src/network/networkd-route.c | 32 ++--
>  1 file changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/src/network/networkd-route.c b/src/network/networkd-route.c
> index 10d8cd9..82c9e00 100644
> --- a/src/network/networkd-route.c
> +++ b/src/network/networkd-route.c
> @@ -118,13 +118,15 @@ int route_drop(Route *route, Link *link,
>  return r;
>  }
> 
> -if (route->family == AF_INET)
> -r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY,
> &route->in_addr.in);
> -else if (route->family == AF_INET6)
> -r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY,
> &route->in_addr.in6);
> -if (r < 0) {
> -log_error("Could not append RTA_GATEWAY attribute:
> %s", strerror(-r));
> -return r;
> +if (!in_addr_is_null(route->family, &route->in_addr)) {
> +if (route->family == AF_INET)
> +r = sd_rtnl_message_append_in_addr(req,
> RTA_GATEWAY, &route->in_addr.in);
> +else if (route->family == AF_INET6)
> +r = sd_rtnl_message_append_in6_addr(req,
> RTA_GATEWAY, &route->in_addr.in6);
> +if (r < 0) {
> +log_error("Could not append RTA_GATEWAY
> attribute: %s", strerror(-r));
> +return r;
> +}
>  }
> 
>  if (route->dst_prefixlen) {
> @@ -203,13 +205,15 @@ int route_configure(Route *route, Link *link,
>  return r;
>  }
> 
> -if (route->family == AF_INET)
> -r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY,
> &route->in_addr.in);
> -else if (route->family == AF_INET6)
> -r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY,
> &route->in_addr.in6);
> -if (r < 0) {
> -log_error("Could not append RTA_GATEWAY attribute:
> %s", strerror(-r));
> -return r;
> +if (!in_addr_is_null(route->family, &route->in_addr)) {
> +if (route->family == AF_INET)
> +r = sd_rtnl_message_append_in_addr(req,
> RTA_GATEWAY, &route->in_addr.in);
> +else if (route->family == AF_INET6)
> +r = sd_rtnl_message_append_in6_addr(req,
> RTA_GATEWAY, &route->in_addr.in6);
> +if (r < 0) {
> +log_error("Could not append RTA_GATEWAY
> attribute: %s", strerror(-r));
> +return r;
> +}
>  }
> 
>  if (route->dst_prefixlen) {
> -- 
> 2.1.3
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

[systemd-devel] [PATCH] networkd: route - allow routes without a gateway

[Gavin Li]

For IPv6, the kernel returns EINVAL if a route is added with the
RTA_GATEWAY attribute set to in6addr_any (::). A route without a
gateway is useful in some situations, such as layer 3 tunneling
(sit, gre, etc.).

This patch prevents the RTA_GATEWAY attribute from being added
when route.in_addr is ip6addr_any (::).
---
 src/network/networkd-route.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/src/network/networkd-route.c b/src/network/networkd-route.c
index 10d8cd9..82c9e00 100644
--- a/src/network/networkd-route.c
+++ b/src/network/networkd-route.c
@@ -118,13 +118,15 @@ int route_drop(Route *route, Link *link,
 return r;
 }

-if (route->family == AF_INET)
-r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY,
&route->in_addr.in);
-else if (route->family == AF_INET6)
-r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY,
&route->in_addr.in6);
-if (r < 0) {
-log_error("Could not append RTA_GATEWAY attribute:
%s", strerror(-r));
-return r;
+if (!in_addr_is_null(route->family, &route->in_addr)) {
+if (route->family == AF_INET)
+r = sd_rtnl_message_append_in_addr(req,
RTA_GATEWAY, &route->in_addr.in);
+else if (route->family == AF_INET6)
+r = sd_rtnl_message_append_in6_addr(req,
RTA_GATEWAY, &route->in_addr.in6);
+if (r < 0) {
+log_error("Could not append RTA_GATEWAY
attribute: %s", strerror(-r));
+return r;
+}
 }

 if (route->dst_prefixlen) {
@@ -203,13 +205,15 @@ int route_configure(Route *route, Link *link,
 return r;
 }

-if (route->family == AF_INET)
-r = sd_rtnl_message_append_in_addr(req, RTA_GATEWAY,
&route->in_addr.in);
-else if (route->family == AF_INET6)
-r = sd_rtnl_message_append_in6_addr(req, RTA_GATEWAY,
&route->in_addr.in6);
-if (r < 0) {
-log_error("Could not append RTA_GATEWAY attribute:
%s", strerror(-r));
-return r;
+if (!in_addr_is_null(route->family, &route->in_addr)) {
+if (route->family == AF_INET)
+r = sd_rtnl_message_append_in_addr(req,
RTA_GATEWAY, &route->in_addr.in);
+else if (route->family == AF_INET6)
+r = sd_rtnl_message_append_in6_addr(req,
RTA_GATEWAY, &route->in_addr.in6);
+if (r < 0) {
+log_error("Could not append RTA_GATEWAY
attribute: %s", strerror(-r));
+return r;
+}
 }

 if (route->dst_prefixlen) {
-- 
2.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd: Support setting mtu / mac address by interface name

[William Kennington]

I'd like to be able to set the MAC Address and MTU of interfaces, with just
the interface name alone. The current method for matching links seems to be
heavily tied to udev ATTRs and I understand given the nature of
systemd.link that it might not make sense to Match based on name. However,
I need this functionality to support mapping the current OS defined network
configuration syntax to networkd. Is there any chance this could be
supported in systemd.network instead of systemd.link?

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

[systemd-devel] systemd.netdev: Tunnel should support ANY addresses for Local option

[William Kennington]

Currently, networkd netdevs do not support tunnel devices which do not have
a local address configured. This breaks the configuration of sit devices on
my hosts which run dhcp for ipv4 configuration, which normally have local
set to 0.0.0.0. Is there any chance we could remove the any check for the
local endpoint address?

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

Re: [systemd-devel] Service not restarting after Condition failed

[Umut Tezduyar Lindskog]

Hi

On Monday, November 24, 2014, D.S. Ljungmark  wrote:

> On 10/11/14 23:09, Lennart Poettering wrote:
> > On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se
> ) wrote:
> >
> >> Hi
> >>  we have a service set to:
> >> ConditionFileNotEmpty=
> >>
> >> and
> >>
> >> Restart=Always
> >>
> >>
> >> This combination would (in my feebled mind) cause the service to restart
> >> once the Condition was fulfilled, but that doesn't seem to be the
> >> case.
> >
> > Conditions are something that are on-time evaluated right before we
> > would start a unit, and cause this starting to be shortcut. That's all
> > really. Restarts are only triggered when a running service dies, and
> > the start job queued by that will then check the conditions again. If
> > the condition doesn't hold then this start will not be executed, and
> > hence no restart ever again either...
> >
> >> Is there a way I can get a service to restart even after it has been set
> >> as inactive (dead) "start condition failed"?
> >
> > Nope, conditions are not for that. For the specific check of
> > file-not-empty there's no nice way to handle this, however for
> > directory-not-empty you could set up DirectoryNotEmpty=...
> >
> >> Should I simply remove the Condition, or something else?
> >
> > What precisely are you trying to do?
> >
> > Lennart
>
> Basically, some files (config & certificates) may not exist on a system
> until it's provisioned properly, something that may take a while ( a few
> days)
>
> After provisioning, we want the services depending on those file to
> start automatically.


Path unit files should work for you,
http://www.freedesktop.org/software/systemd/man/systemd.path.html

Umut

>
> //D.S.
>
>
> --
> 8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] networkd: integrate LLDP

[Umut Tezduyar Lindskog]

On Sunday, November 23, 2014, Susant Sahani  wrote:

>
> On 11/23/2014 09:33 PM, Umut Tezduyar Lindskog wrote:
>
>> Hi,
>>
> Hi Umut,
>
>>
>> On Sun, Nov 23, 2014 at 5:45 AM, Susant Sahani  wrote:
>>
>>> This patch integrates LLDP with networkd.
>>>
>>> Example conf:
>>> file : lldp.network
>>>
>>> [Match]
>>> Name=em1
>>>
>>> [Network]
>>> LLDP=yes
>>> ---
>>>   man/systemd.network.xml  |  7 +
>>>   src/network/networkd-link.c  | 45
>>> 
>>>   src/network/networkd-link.h  |  2 ++
>>>   src/network/networkd-network-gperf.gperf |  1 +
>>>   src/network/networkd.h   |  3 +++
>>>   5 files changed, 58 insertions(+)
>>>
>>> diff --git a/man/systemd.network.xml b/man/systemd.network.xml
>>> index 4cc13b2..143c9ee 100644
>>> --- a/man/systemd.network.xml
>>> +++ b/man/systemd.network.xml
>>> @@ -234,6 +234,13 @@
>>>   
>>>   
>>>   
>>> +LLDP=
>>> 
>>> +
>>> +A boolean. When
>>> true, enables LLDP link receive support.
>>>
>>
>> Maybe enum instead of bool? lldp can run in "send-only",
>> "receive-only", "both" mode.
>>
> Now we don't support tx . that's why it's a boolean . Later when we add
> other features(TX) we will definitely modify that. It'a a very basic
> implementation now :). Lots of things are in TODO


Thanks.

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

[systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging

[Peter Wu]

The --gc-sections linker option triggers a bug in the gold linker[1] which
results in a bogus .eh_frame section making debugging harder: gdb backtraces
stop at a library built by systemd and libunwind simply segfaults.

Workaround by that bug by removing the option. The additional disk space
saved by this option is marginal anyway (less than 1%). To illustrate this, see
this `du -ks` on the installed files:

83548   without-gc-sections/install
25796   without-gc-sections/install-strip
83432   with-gc-sections/install
25752   with-gc-sections/install-strip

 [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639

https://bugs.freedesktop.org/show_bug.cgi?id=8
---
 configure.ac | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index bd3cc0e..8d926be 100644
--- a/configure.ac
+++ b/configure.ac
@@ -219,7 +219,6 @@ AC_SUBST([OUR_CPPFLAGS], "$with_cppflags 
$sanitizer_cppflags")
 CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS], [\
 -Wl,--as-needed \
 -Wl,--no-undefined \
--Wl,--gc-sections \
 -Wl,-z,relro \
 -Wl,-z,now \
 -pie \
-- 
1.9.1

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

Re: [systemd-devel] Service not restarting after Condition failed

[D.S. Ljungmark]

On 10/11/14 23:09, Lennart Poettering wrote:
> On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se) wrote:
> 
>> Hi
>>  we have a service set to:
>> ConditionFileNotEmpty=
>>
>> and
>>
>> Restart=Always
>>
>>
>> This combination would (in my feebled mind) cause the service to restart
>> once the Condition was fulfilled, but that doesn't seem to be the
>> case.
> 
> Conditions are something that are on-time evaluated right before we
> would start a unit, and cause this starting to be shortcut. That's all
> really. Restarts are only triggered when a running service dies, and
> the start job queued by that will then check the conditions again. If
> the condition doesn't hold then this start will not be executed, and
> hence no restart ever again either...
> 
>> Is there a way I can get a service to restart even after it has been set
>> as inactive (dead) "start condition failed"?
> 
> Nope, conditions are not for that. For the specific check of
> file-not-empty there's no nice way to handle this, however for
> directory-not-empty you could set up DirectoryNotEmpty=...
> 
>> Should I simply remove the Condition, or something else?
> 
> What precisely are you trying to do?
> 
> Lennart

Basically, some files (config & certificates) may not exist on a system
until it's provisioned properly, something that may take a while ( a few
days)

After provisioning, we want the services depending on those file to
start automatically.

//D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



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

Re: [systemd-devel] Watchdog timeout signals

[D.S. Ljungmark]

On 24/11/14 17:58, Peter Sztanojev wrote:
> On Mon, Nov 24, 2014 at 5:39 PM, D.S. Ljungmark  wrote:
>> Hi,
>>  We're pondering to use the WatchdogSec=.. function, but wanted to know
>> what signal (if any) are sent to the application before termination.
>>
>> Main reason is that we want to get a proper stacktrace of the daemon if
>> it is killed for some reason.
>>
> 
> You will be glad to hear this (depending on your version):
> http://cgit.freedesktop.org/systemd/systemd/tree/NEWS#n189
> 

Those are great news, except that I'm on 215...

Well, it'll get there sooner or later, thanks!

//D.S.

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



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

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

[Lennart Poettering]

On Mon, 24.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:

> > char fd_name[sizeof("/proc/")-1 + DECIMAL_STR_MAX(pid_t) + sizeof("/fd/")-1 
> > + DECIMAL_STR_MAX(int) + 1];
> 
> 
> OK, I thought systemd prefers alloca(). I was inspired by
> procfs_file_alloca().

Well, this is a pseudo-function implemented as macro. In a pseudo-function we 
can easily
return alloca() allocated buffers, but of course no normal
stack-allocated arrays.

> 
> > > +
> > > +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.
> > 
> 
> OK.
> Just a note, it iterates until it finds the first non-existing fd.

That end condition is wrong too, as commonly there are "holes" in the
allocation because people may close fds at any times, and keep fds
with later numbers around.

> > I think using libc's open_memstream() and then simply writing to it
> > would be a *ton* prettier than this.
> 
> Fabulous! I think so too. I wasn't allowed to use such a construction in
> other projects.

open_memstream() is even POSIX! For us, GNU and Linux-specific APIs
are fine too, and POSIX is absolutely baseline...

Lennart

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

Re: [systemd-devel] [systemd-commits] src/cryptsetup

[Quentin Lefebvre]

Le 24/11/2014 19:17, Zbigniew Jędrzejewski-Szmek a écrit :

On Mon, Nov 24, 2014 at 07:03:27PM +0100, Quentin Lefebvre wrote:

Le 24/11/2014 19:01, Zbigniew Jędrzejewski-Szmek a écrit :

On Mon, Nov 24, 2014 at 06:44:25PM +0100, Quentin Lefebvre wrote:

Hi,

I tested your patch and actually it doesn't solve the bug.
For example, if "hash=sha512" is provided in /etc/crypttab, the
first >   if (!streq(arg_hash, "plain"))
is true, and the

+} else if (!key_file)

is not reached.

This is be design. My patch is quite different from your patch,
which I tried to make clear in the description.

If you specify hash=sha512, then you get hash=sha512.


Yes, and this is the problem.
cryptsetup ignores the hash, so that we should obtain hash=NULL for
it to work.

Systemd is not going to work around a bug in a different package.
Specifying a hash in the configuration if you don't want a hash
is an error, please just fix it there.


I understand your point.
Still you have a cryptsetup tool in systemd, so I would expect it 
behaves as the "true" cryptsetup program.


The problem here is compatibility, you do something with cryptsetup and 
then your system fails to boot because of a different behaviour of systemd.


But it's up to you, that may just get users and installers into trouble.

Best regards,
Quentin

PS: Actually, the good practice is to have a key file obtained from 
/dev/random, with the correct key size, so I'm not sure hashing the key 
file matters.

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

Re: [systemd-devel] [systemd-commits] src/cryptsetup

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 24, 2014 at 07:03:27PM +0100, Quentin Lefebvre wrote:
> Le 24/11/2014 19:01, Zbigniew Jędrzejewski-Szmek a écrit :
> >On Mon, Nov 24, 2014 at 06:44:25PM +0100, Quentin Lefebvre wrote:
> >>Hi,
> >>
> >>I tested your patch and actually it doesn't solve the bug.
> >>For example, if "hash=sha512" is provided in /etc/crypttab, the
> >>first >   if (!streq(arg_hash, "plain"))
> >>is true, and the
> >>>+} else if (!key_file)
> >>is not reached.
> >This is be design. My patch is quite different from your patch,
> >which I tried to make clear in the description.
> >
> >If you specify hash=sha512, then you get hash=sha512.
> 
> Yes, and this is the problem.
> cryptsetup ignores the hash, so that we should obtain hash=NULL for
> it to work.
Systemd is not going to work around a bug in a different package.
Specifying a hash in the configuration if you don't want a hash
is an error, please just fix it there.

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

Re: [systemd-devel] [systemd-commits] src/cryptsetup

[Quentin Lefebvre]

Le 24/11/2014 19:01, Zbigniew Jędrzejewski-Szmek a écrit :

On Mon, Nov 24, 2014 at 06:44:25PM +0100, Quentin Lefebvre wrote:

Hi,

I tested your patch and actually it doesn't solve the bug.
For example, if "hash=sha512" is provided in /etc/crypttab, the
first >   if (!streq(arg_hash, "plain"))
is true, and the

+} else if (!key_file)

is not reached.

This is be design. My patch is quite different from your patch,
which I tried to make clear in the description.

If you specify hash=sha512, then you get hash=sha512.


Yes, and this is the problem.
cryptsetup ignores the hash, so that we should obtain hash=NULL for it 
to work.


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

Re: [systemd-devel] [systemd-commits] src/cryptsetup

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 24, 2014 at 06:44:25PM +0100, Quentin Lefebvre wrote:
> Hi,
> 
> I tested your patch and actually it doesn't solve the bug.
> For example, if "hash=sha512" is provided in /etc/crypttab, the
> first >   if (!streq(arg_hash, "plain"))
> is true, and the
> > +} else if (!key_file)
> is not reached.
This is be design. My patch is quite different from your patch,
which I tried to make clear in the description.

If you specify hash=sha512, then you get hash=sha512.

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

Re: [systemd-devel] Type=simple and BusName=

[David Herrmann]

Hi

On Wed, Nov 19, 2014 at 2:05 PM, Umut Tezduyar Lindskog
 wrote:
> Hi,
>
> Quote from man service:
>
> BusName= Takes a D-Bus bus name that this service is reachable as.
> This option is mandatory for services where Type= is set to dbus, but
> its use is otherwise recommended if the process takes a name on the
> D-Bus bus.
>
> Why it is recommended?

I think the description tries to say: "If you take a bus-name, try to
convert your application file to Type=dbus"

The text is little misleading, indeed. Patches to reword this
paragraph are welcome!

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

Re: [systemd-devel] [PATCH] This patch solves the bug 52630 described here: https://bugs.freedesktop.org/show_bug.cgi?id=52630 .

[Quentin Lefebvre]

Hi,

I reopened the bug after testing the patch.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=52630
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025490.html
(sorry for the poor formatting of the last email).

Best,
Quentin

Le 24/11/2014 15:21, Zbigniew Jędrzejewski-Szmek a écrit :

On Wed, Nov 19, 2014 at 02:22:02PM +0100, Quentin Lefebvre wrote:

For plain dm-crypt devices, the behavior of cryptsetup package is to ignore the 
hash algorithm when a key file is provided.
With this patch, systemd-cryptsetup now behaves as cryptsetup, so that old 
plain dm-crypt devices created with cryptsetup can be mounted at boot time by 
systemd, with no modification of /etc/crypttab.


[replying here too for the sake of ml archives]

As I said on the bug tracker, it seems wrong to ignore the hash
if it is explicitly configured by the user. I pushed a change to
default to no hash if the keyfile is specified instead.

Zbyszek
___
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] [systemd-commits] src/cryptsetup

[Quentin Lefebvre]

Hi,

I tested your patch and actually it doesn't solve the bug.
For example, if "hash=sha512" is provided in /etc/crypttab, the first > 
  if (!streq(arg_hash, "plain"))

is true, and the
> +} else if (!key_file)
is not reached.

So I suggest rewriting the patch, or applying my original patch, that is 
maybe less elegant, but has both advantages to work and be easily readable.


Best regards,
Quentin

On 24/11/2014 15:14, Zbigniew Jędrzejewski-Szmek wrote :

  src/cryptsetup/cryptsetup.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

New commits:
commit 8a52210c9392887a31fdb2845f65b4c5869e8e66
Author: Zbigniew Jędrzejewski-Szmek 
Date:   Mon Nov 24 09:11:12 2014 -0500

 cryptsetup: default to no hash when keyfile is specified

 For plain dm-crypt devices, the behavior of cryptsetup package is to
 ignore the hash algorithm when a key file is provided. It seems wrong
 to ignore a hash when it is explicitly specified, but we should default
 to no hash if the keyfile is specified.

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

diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 94570eb..b9e67fa 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -400,7 +400,9 @@ static int attach_luks_or_plain(struct crypt_device *cd,
  /* plain isn't a real hash type. it just means "use no 
hash" */
  if (!streq(arg_hash, "plain"))
  params.hash = arg_hash;
-} else
+} else if (!key_file)
+/* for CRYPT_PLAIN, the behaviour of cryptsetup
+ * package is to not hash when a key file is provided 
*/
  params.hash = "ripemd160";

  if (arg_cipher) {



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



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

Re: [systemd-devel] Watchdog timeout signals

[Peter Sztanojev]

On Mon, Nov 24, 2014 at 5:39 PM, D.S. Ljungmark  wrote:
> Hi,
>  We're pondering to use the WatchdogSec=.. function, but wanted to know
> what signal (if any) are sent to the application before termination.
>
> Main reason is that we want to get a proper stacktrace of the daemon if
> it is killed for some reason.
>

You will be glad to hear this (depending on your version):
http://cgit.freedesktop.org/systemd/systemd/tree/NEWS#n189
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Watchdog timeout signals

[D.S. Ljungmark]

Hi,
 We're pondering to use the WatchdogSec=.. function, but wanted to know
what signal (if any) are sent to the application before termination.

Main reason is that we want to get a proper stacktrace of the daemon if
it is killed for some reason.

//D.S.
-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



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

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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 24, 2014 at 07:48:17AM +0200, Mantas Mikulėnas wrote:
> On Mon, Nov 24, 2014 at 2:59 AM, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> > On Thu, Nov 20, 2014 at 09:13:02AM +0200, Mantas Mikulėnas wrote:
> > > ~ If there are two .swap units for the same partition (one made by
> > > fstab-generator, another by gpt-generator), systemd tries to swapon it
> > > twice, resulting in "swapon failed: Device or resource busy".
> > IIUC, the problem is that swapons are called concurently, and one fails.
> > If they were started sequentially, systemd would notice that they both
> > refer to the same device and make one of the follow the other. What
> > I'm guessing happens is that initially the units use different device
> > names, so they are not merged. Could you post both units (systemctl cat
> > would probably be best), so we can see what is going wrong?
> 
> Right, after all, since .swap unit names directly depend on device names,
> then it's pretty much guaranteed that the latter will differ...
> 
> What I have is:
> 
> ---
> # /run/systemd/generator/dev-disk-by\x2dpartlabel-swap.swap
> # Automatically generated by systemd-fstab-generator
> 
> [Unit]
> SourcePath=/etc/fstab
> Documentation=man:fstab(5) man:systemd-fstab-generator(8)
> 
> [Swap]
> What=/dev/disk/by-partlabel/swap
> Options=rw
> ---
> 
> ---
> # /run/systemd/generator.late/dev-sda7.swap
> # Automatically generated by systemd-gpt-auto-generator
> 
> [Unit]
> Description=Swap Partition
> Documentation=man:systemd-gpt-auto-generator(8)
> 
> [Swap]
> What=/dev/sda7
> ---
And what does 'udevadm info /dev/sda7' and 'systemctl show dev-sda7.swap' and
the same for dev-disk-by\x2dpartlabel-swap.swap?

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

Re: [systemd-devel] [PATCH v3] smack: introduce new SmackProcessLabel option

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 24, 2014 at 08:46:20PM +0900, WaLyong Cho wrote:
> In service file, if the file has some of special SMACK label in
> ExecStart= and systemd has no permission for the special SMACK label
> then permission error will occurred. To resolve this, systemd should
> be able to set its SMACK label to something accessible of ExecStart=.
> So introduce new SmackProcessLabel. If label is specified with
> SmackProcessLabel= then the child systemd will set its label to
> that. To successfully execute the ExecStart=, accessible label should
> be specified with SmackProcessLabel=.
> Additionally, by SMACK policy, if the file in ExecStart= has no
> SMACK64EXEC then the executed process will have given label by
> SmackProcessLabel=. But if the file has SMACK64EXEC then the
> SMACK64EXEC label will be overridden.
Applied!

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

Re: [systemd-devel] [PATCH] This patch solves the bug 52630 described here: https://bugs.freedesktop.org/show_bug.cgi?id=52630 .

[Quentin Lefebvre]

On 24/11/2014 15:21, Zbigniew Jędrzejewski-Szmek wrote :

On Wed, Nov 19, 2014 at 02:22:02PM +0100, Quentin Lefebvre wrote:

For plain dm-crypt devices, the behavior of cryptsetup package is to ignore the 
hash algorithm when a key file is provided.
With this patch, systemd-cryptsetup now behaves as cryptsetup, so that old 
plain dm-crypt devices created with cryptsetup can be mounted at boot time by 
systemd, with no modification of /etc/crypttab.


As I said on the bug tracker, it seems wrong to ignore the hash
if it is explicitly configured by the user.


Yes, I agree on that.


I pushed a change to
default to no hash if the keyfile is specified instead.


Thanks, I think it was the default choice for compatibility.

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

Re: [systemd-devel] [PATCH] This patch solves the bug 52630 described here: https://bugs.freedesktop.org/show_bug.cgi?id=52630 .

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 19, 2014 at 02:22:02PM +0100, Quentin Lefebvre wrote:
> >For plain dm-crypt devices, the behavior of cryptsetup package is to ignore 
> >the hash algorithm when a key file is provided.
> >With this patch, systemd-cryptsetup now behaves as cryptsetup, so that old 
> >plain dm-crypt devices created with cryptsetup can be mounted at boot time 
> >by systemd, with no modification of /etc/crypttab.

[replying here too for the sake of ml archives]

As I said on the bug tracker, it seems wrong to ignore the hash
if it is explicitly configured by the user. I pushed a change to
default to no hash if the keyfile is specified instead.

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

Re: [systemd-devel] [PATCH v2] localed: validate set-x11-keymap input

[David Herrmann]

Hi

On Wed, Nov 19, 2014 at 9:41 AM, Jan Synacek  wrote:
> David Herrmann  writes:
>> Hi
>>
>> On Fri, Nov 14, 2014 at 12:42 PM, Jan Synacek  wrote:
>>> Try to validate the input similarly to how setxkbmap does it. Multiple
>>> layouts and variants can be specified, separated by a comma. Variants
>>> can also be left out, meaning that the user doesn't want any particular
>>> variant for the respective layout.
>>>
>>> Variants are validated respectively to their layouts. First variant
>>> validates against first layout, second variant to second layout, etc. If
>>> there are more entries of either layouts or variants, only their
>>> respective counterparts are validated, the rest is ignored.
>>>
>>> Examples:
>>> $ set-x11-keymap us,cz  pc105 ,qwerty
>>> "us" is not validated, because no respective variant was specified. "cz"
>>> is checked for an existing "qwerty" variant, the check succeeds.
>>>
>>> $ set-x11-keymap us pc105 ,qwerty
>>> "us" is not validated as in the above example. The rest of the variants
>>> is ignored, because there are no respective layouts.
>>>
>>> $ set-x11-keymap us,cz pc105 qwerty
>>> "us" is validated against the "qwerty" variant, check fails, because
>>> there is no "qwerty" variant for the "us" layout.
>>>
>>> $ set-x11-keymap us,cz pc105 euro,qwerty
>>> Validation succeeds, there is the "euro" variant for the "us" layout,
>>> and "qwerty" variant for the "cz" layout.
>>>
>>> http://lists.freedesktop.org/archives/systemd-devel/2014-October/024411.html
>>
>> I didn't follow the discussion on v1, but why don't we use
>> libxkbcommon to compile the keymap? If it doesn't compile, print an
>> error (or warning and maybe optionally still proceed?).
>>
>> Sure, this would add a dependency to libxkbcommon for localed, but we
>> could make it optional. And libxkbcommon has no dependencies by
>> itself. Furthermore, set-x11-keymap is pretty useless without
>> libxkbcommon installed, anyway.
>>
>> It'd be a ~10 line patch to use
>> xkb_context_new()+xkb_keymap_from_rmlvo(). And it would be guaranteed
>> to have the same semantics as the real keymap compilation.
>>
>> Thanks
>> David
>
> For some reason, I was under the impression that depending on
> libxkbcommon would mean depending on plenty of X libraries... Using the
> library and making the dependency on it optional sounds like the best
> solution to me.
>
> Waiting for more opinions.

I now pushed something to -git, see:

commit d4f5a1f47dbd04f26f2ddf951c97c4cb0ebbbe62
Author: David Herrmann 
Date:   Mon Nov 24 15:12:42 2014 +0100

localed: validate xkb keymaps

I think duplicating the xkb-parsers is something we should avoid. Ran
Benita was even working on a v2 format to drop all the legacy bits
no-one uses in the old, crufty xkb format. I dislike having a fixed
parser in systemd. Sure, our --list-layouts option needs to do this,
but maybe we can drop that some day, too.

I pushed a fix to test-compile keymaps on set-x11-keymap calls. So
far, I only print a warning if it fails. Please feel free to post
patches to extend this. For instance, I think we might want to do that
in localectl (maybe even forward the xkb-logs then) and fail hard if
the compilation fails (even though I dislike --force options..).

I hope my commit is something to base further work on. I tried keeping
it as non-intrusive as possible.

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

Re: [systemd-devel] [PATCH v2] localed: validate set-x11-keymap input

[Jan Synacek]

Lennart Poettering  writes:
> On Fri, 14.11.14 12:42, Jan Synacek (jsyna...@redhat.com) wrote:
>> +if (look_for == LAYOUTS) {
>> +Set *s;
>> +char *k;
>> +Iterator i;
>> +/* XXX: Is there a better way to sort Hashmap keys? */
>> +_cleanup_strv_free_ char **tmp = NULL;
>> +
>> +HASHMAP_FOREACH_KEY(s, k, keymap->x11_layouts, i)
>> +if (strv_extend(&tmp, k) < 0)
>> +(void) log_oom();
>
> There's hashmap_get_strv() for cases like this.

I need keys, not values. I didn't find any hashmap_get_strv() equivalent
for keys.

>
> Also, please neer invoke strv_extend() when appending to unbounded
> arrays. It's slow! 

What is a preffered way to extend a strv? In this case, I know the final
size, so it the array could manually be copied. I don't think that
that's very nice, though.

>> +void xkb_keymap_free_components(X11Keymap *keymap) {
>> +if (keymap->x11_layouts) {
>> +Set *s;
>> +char *k;
>> +Iterator i;
>> +
>> +HASHMAP_FOREACH_KEY(s, k, keymap->x11_layouts, i) {
>> +free(k);
>> +set_free_free(s);
>> +}
>
> Humm, when clearing up hashmaps please just write a loop that steals
> the first entry, free it and then repeat. Iterating through a hashmap
> while deleting its entries is unnecessary...

I need to free its entries *and* keys. I didn't find any function that I
could use for that, apart from hashmap_free_free(), which crashes in my case.

> Lennart
>
> -- 
> Lennart Poettering, Red Hat

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat


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

[systemd-devel] [PATCH v3] smack: introduce new SmackProcessLabel option

[WaLyong Cho]

In service file, if the file has some of special SMACK label in
ExecStart= and systemd has no permission for the special SMACK label
then permission error will occurred. To resolve this, systemd should
be able to set its SMACK label to something accessible of ExecStart=.
So introduce new SmackProcessLabel. If label is specified with
SmackProcessLabel= then the child systemd will set its label to
that. To successfully execute the ExecStart=, accessible label should
be specified with SmackProcessLabel=.
Additionally, by SMACK policy, if the file in ExecStart= has no
SMACK64EXEC then the executed process will have given label by
SmackProcessLabel=. But if the file has SMACK64EXEC then the
SMACK64EXEC label will be overridden.
---
 man/systemd.exec.xml  | 19 +
 src/core/dbus-execute.c   | 19 +
 src/core/execute.c| 11 
 src/core/execute.h|  3 +++
 src/core/load-fragment-gperf.gperf.m4 |  7 +++--
 src/core/load-fragment.c  | 50 +++
 src/core/load-fragment.h  |  1 +
 src/shared/exit-status.h  |  1 +
 src/shared/smack-util.c   | 20 ++
 src/shared/smack-util.h   |  1 +
 10 files changed, 130 insertions(+), 2 deletions(-)

diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index e9af4ab..ea2130d 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -1138,6 +1138,25 @@
 
 
 
+
SmackProcessLabel=
+
+Set the SMACK security
+label to run given executable file in
+ExecStart=. The
+executable file has no SMACK64EXEC
+label then the executed process run
+with this label. But if the file has
+SMACK64EXEC label then executed
+process run with its own SMACK64EXEC
+label. If no label set, defaults to
+label of systemd by SMACK policy. This
+directive is ignored if SMACK is
+disabled. If prefixed
+by-, all
+errorswillbe ignored.
+
+
+
 IgnoreSIGPIPE=
 
 Takes a boolean
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index 9276da4..bbcd610 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -508,6 +508,24 @@ static int property_get_apparmor_profile(
 return sd_bus_message_append(reply, "(bs)", 
c->apparmor_profile_ignore, c->apparmor_profile);
 }
 
+static int property_get_smack_process_label(
+sd_bus *bus,
+const char *path,
+const char *interface,
+const char *property,
+sd_bus_message *reply,
+void *userdata,
+sd_bus_error *error) {
+
+ExecContext *c = userdata;
+
+assert(bus);
+assert(reply);
+assert(c);
+
+return sd_bus_message_append(reply, "(bs)", 
c->smack_process_label_ignore, c->smack_process_label);
+}
+
 static int property_get_personality(
 sd_bus *bus,
 const char *path,
@@ -636,6 +654,7 @@ const sd_bus_vtable bus_exec_vtable[] = {
 SD_BUS_PROPERTY("UtmpIdentifier", "s", NULL, offsetof(ExecContext, 
utmp_id), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("SELinuxContext", "(bs)", 
property_get_selinux_context, 0, SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("AppArmorProfile", "(bs)", 
property_get_apparmor_profile, 0, SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("SmackProcessLabel", "(bs)", 
property_get_smack_process_label, 0, SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("IgnoreSIGPIPE", "b", bus_property_get_bool, 
offsetof(ExecContext, ignore_sigpipe), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("NoNewPrivileges", "b", bus_property_get_bool, 
offsetof(ExecContext, no_new_privileges), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("SystemCallFilter", "(bas)", 
property_get_syscall_filter, 0, SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/execute.c b/src/core/execute.c
index 5cfd4a1..e6c1999 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -83,6 +83,7 @@
 #include "af-list.h"
 #include "mkdir.h"
 #include "apparmor-util.h"
+#include "smack-util.h"
 #include "bus-kernel.h"
 #include "label.h"
 
@@ -1618,6 +1619,16 @@ static int exec_child(ExecCommand *command,
 }
 }
 
+#ifdef HAVE_SMACK
+if (context->smack_pr

[systemd-devel] [PATCH 5/5] machine-id-commit: add man pages

[Didier Roche]

>From 9b8d7613894838ce67db5141b8012b5abf7c02e4 Mon Sep 17 00:00:00 2001
From: Didier Roche 
Date: Mon, 24 Nov 2014 11:14:22 +0100
Subject: [PATCH 5/5] machine-id-commit: add man pages

Add man pages for systemd-machine-id-commit.service and
systemd-machine-id-commit.
---
 Makefile-man.am   |   2 +
 man/systemd-machine-id-commit.service.xml | 101 
 man/systemd-machine-id-commit.xml | 125 ++
 3 files changed, 228 insertions(+)
 create mode 100644 man/systemd-machine-id-commit.service.xml
 create mode 100644 man/systemd-machine-id-commit.xml

diff --git a/Makefile-man.am b/Makefile-man.am
index bdbc54f..a79292a 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -75,6 +75,7 @@ MANPAGES += \
 	man/systemd-inhibit.1 \
 	man/systemd-initctl.service.8 \
 	man/systemd-journald.service.8 \
+	man/systemd-machine-id-commit.1 \
 	man/systemd-machine-id-setup.1 \
 	man/systemd-notify.1 \
 	man/systemd-nspawn.1 \
@@ -210,6 +211,7 @@ MANPAGES_ALIAS += \
 	man/systemd-journald.8 \
 	man/systemd-journald.socket.8 \
 	man/systemd-kexec.service.8 \
+	man/systemd-machine-id-commit.service.8 \
 	man/systemd-poweroff.service.8 \
 	man/systemd-reboot.service.8 \
 	man/systemd-remount-fs.8 \
diff --git a/man/systemd-machine-id-commit.service.xml b/man/systemd-machine-id-commit.service.xml
new file mode 100644
index 000..6da19b9
--- /dev/null
+++ b/man/systemd-machine-id-commit.service.xml
@@ -0,0 +1,101 @@
+
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+
+systemd-machine-id-commit.service
+systemd
+
+
+
+Developer
+Didier
+Roche
+didro...@ubuntu.com
+
+
+
+
+
+systemd-machine-id-commit.service
+8
+
+
+
+systemd-machine-id-commit.service
+Commit transient machine-id to disk
+
+
+
+systemd-machine-id-commit.service
+/usr/lib/systemd/systemd-machine-id-commit
+
+
+
+Description
+
+systemd-machine-id-commit.service is
+a service responsible for commiting any transient
+/etc/machine-id file to a writable file
+system. See
+machine-id5
+for more information about this file.
+
+This service is started shortly after
+local-fs.target if
+/etc/machine-id is an independent mount
+point (probably a tmpfs one) and /etc is writable.
+systemd-machine-id-commit will then
+write current machine ID to disk and unmount the transient
+/etc/machine-id file in a race-free
+manner to ensure that file is always valid for other
+processes.
+
+Note that the traditional way to initialize the machine
+ID in /etc/machine-id is to use
+systemd-machine-id-setup by system
+installer tools. You can also use
+systemd-firstboot1
+to initialize the machine ID on mounted (but not
+booted) system images. The main use case for that service is
+/etc/machine-id being an empty file at
+boot and initrd chaining to systemd giving it a read only file
+system that will be turned read-write later during the boot
+process.
+
+There is no consequence if that service fails other than
+a newer machine-id will be generated during next system boot.
+
+
+
+
+See Also
+
+systemd1,
+systemd-machine-id-commit1,
+systemd-machine-id-setup1,
+machine-id5,
+systemd-firstboot1
+
+
+
+
diff --git a/man/systemd-machine-id-commit.xml b/man/systemd-machine-id-commit.xml
new file mode 100644
index 000..ed2a6d0
--- /dev/null
+++ b/man/systemd-machine-id-commit.xml
@@ -0,0 +1,125 @@
+ 
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+http://www.w3.org/2001/XInclude";>
+
+
+systemd-machine-id-commit
+systemd
+
+
+
+Developer
+Didier
+Roche
+didro...@ubuntu.com
+
+
+
+
+
+systemd-machine-id-commit
+1
+
+
+

[systemd-devel] [PATCH 4/5] machine-id-commit: add unit file

[Didier Roche]

>From 6821788f561770ea7e49f170a5bea4a7033f6ad3 Mon Sep 17 00:00:00 2001
From: Didier Roche 
Date: Mon, 24 Nov 2014 10:12:06 +0100
Subject: [PATCH 4/5] machine-id-commit: add unit file

The unit file only active the machine-id-commit helper if /etc is mounted
writable and /etc/machine-id is an independant mount point (should be a tmpfs).
---
 Makefile.am|  5 +
 units/.gitignore   |  1 +
 units/systemd-machine-id-commit.service.in | 20 
 3 files changed, 26 insertions(+)
 create mode 100644 units/systemd-machine-id-commit.service.in

diff --git a/Makefile.am b/Makefile.am
index 49e45d1..50f6f29 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -537,6 +537,7 @@ nodist_systemunit_DATA = \
 	units/systemd-kexec.service \
 	units/systemd-fsck@.service \
 	units/systemd-fsck-root.service \
+	units/systemd-machine-id-commit.service \
 	units/systemd-udevd.service \
 	units/systemd-udev-trigger.service \
 	units/systemd-udev-settle.service \
@@ -589,6 +590,7 @@ EXTRA_DIST += \
 	units/user/systemd-exit.service.in \
 	units/systemd-f...@.service.in \
 	units/systemd-fsck-root.service.in \
+	units/systemd-machine-id-commit.service.in \
 	units/u...@.service.in \
 	units/debug-shell.service.in \
 	units/systemd-suspend.service.in \
@@ -2189,6 +2191,9 @@ systemd_machine_id_commit_LDADD = \
 	libsystemd-internal.la \
 	libsystemd-shared.la
 
+SYSINIT_TARGET_WANTS += \
+	systemd-machine-id-commit.service
+
 # --
 systemd_ac_power_SOURCES = \
 	src/ac-power/ac-power.c
diff --git a/units/.gitignore b/units/.gitignore
index a1276e5..e12d299 100644
--- a/units/.gitignore
+++ b/units/.gitignore
@@ -25,6 +25,7 @@
 /systemd-firstboot.service
 /systemd-fsck-root.service
 /systemd-fsck@.service
+/systemd-machine-id-commit.service
 /systemd-halt.service
 /systemd-hibernate.service
 /systemd-hostnamed.service
diff --git a/units/systemd-machine-id-commit.service.in b/units/systemd-machine-id-commit.service.in
new file mode 100644
index 000..bed3d2e
--- /dev/null
+++ b/units/systemd-machine-id-commit.service.in
@@ -0,0 +1,20 @@
+#  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.
+
+[Unit]
+Description=Commit a transient machine-id on disk
+Documentation=man:systemd-machine-id-commit.service(8)
+DefaultDependencies=no
+Before=shutdown.target
+After=local-fs.target
+ConditionPathIsReadWrite=/etc
+ConditionPathIsMountPoint=/etc/machine-id
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=@rootlibexecdir@/systemd-machine-id-commit
-- 
2.1.3

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

[systemd-devel] [PATCH 3/5] Introduce machine-id-commit binary

[Didier Roche]

>From 6a9dfa52ea8a5564c86942ac55c9173ee06f53fe Mon Sep 17 00:00:00 2001
From: Didier Roche 
Date: Mon, 24 Nov 2014 09:54:18 +0100
Subject: [PATCH 3/5] Introduce machine-id-commit binary

This binary enables to commit transient machine-id on disk if it becomes
writable.
---
 .gitignore|   1 +
 Makefile.am   |  12 
 src/machine-id-commit/Makefile|   1 +
 src/machine-id-commit/machine-id-commit.c | 105 ++
 4 files changed, 119 insertions(+)
 create mode 12 src/machine-id-commit/Makefile
 create mode 100644 src/machine-id-commit/machine-id-commit.c

diff --git a/.gitignore b/.gitignore
index 2293ded..f6d3151 100644
--- a/.gitignore
+++ b/.gitignore
@@ -89,6 +89,7 @@
 /systemd-kmsg-syslogd
 /systemd-localed
 /systemd-logind
+/systemd-machine-id-commit
 /systemd-machine-id-setup
 /systemd-machined
 /systemd-modeset
diff --git a/Makefile.am b/Makefile.am
index 3f9f3fa..49e45d1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -385,6 +385,7 @@ rootlibexec_PROGRAMS = \
 	systemd-remount-fs \
 	systemd-reply-password \
 	systemd-fsck \
+	systemd-machine-id-commit \
 	systemd-ac-power \
 	systemd-sysctl \
 	systemd-sleep \
@@ -2178,6 +2179,17 @@ systemd_fsck_LDADD = \
 	libsystemd-shared.la
 
 # --
+systemd_machine_id_commit_SOURCES = \
+	src/machine-id-commit/machine-id-commit.c \
+	src/core/machine-id-setup.c \
+	src/core/machine-id-setup.h
+
+systemd_machine_id_commit_LDADD = \
+	libsystemd-label.la \
+	libsystemd-internal.la \
+	libsystemd-shared.la
+
+# --
 systemd_ac_power_SOURCES = \
 	src/ac-power/ac-power.c
 
diff --git a/src/machine-id-commit/Makefile b/src/machine-id-commit/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/machine-id-commit/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/machine-id-commit/machine-id-commit.c b/src/machine-id-commit/machine-id-commit.c
new file mode 100644
index 000..c7e4de8
--- /dev/null
+++ b/src/machine-id-commit/machine-id-commit.c
@@ -0,0 +1,105 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Didier Roche
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see .
+***/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "machine-id-setup.h"
+#include "log.h"
+#include "build.h"
+
+static const char *arg_root = "";
+
+static void help(void) {
+printf("%s [OPTIONS...]\n\n"
+   "Commit a transient /etc/machine-id on disk if writable.\n\n"
+   "  -h --help Show this help\n"
+   " --version  Show package version\n"
+   " --root=ROOTFilesystem root\n",
+   program_invocation_short_name);
+}
+
+static int parse_argv(int argc, char *argv[]) {
+
+enum {
+ARG_VERSION = 0x100,
+ARG_ROOT,
+};
+
+static const struct option options[] = {
+{ "help",  no_argument,   NULL, 'h'   },
+{ "version",   no_argument,   NULL, ARG_VERSION   },
+{ "root",  required_argument, NULL, ARG_ROOT  },
+{}
+};
+
+int c;
+
+assert(argc >= 0);
+assert(argv);
+
+while ((c = getopt_long(argc, argv, "hqcv", options, NULL)) >= 0)
+switch (c) {
+
+case 'h':
+help();
+return 0;
+
+case ARG_VERSION:
+puts(PACKAGE_STRING);
+puts(SYSTEMD_FEATURES);
+return 0;
+
+case ARG_ROOT:
+arg_root = optarg;
+break;
+
+case '?':
+return -EINVAL;
+
+default:
+assert_not_reached("Unhandled option");
+}
+
+if (optind < argc) {
+log_error("Extraneous arguments");
+return -EINVAL;
+}
+
+return 1;
+}
+
+int main(int argc, char *argv[]) {
+int r;
+
+log_set_target

[systemd-devel] [PATCH 2/5] Add a machine_id_commit call to commit on disk a, transient machine-id

[Didier Roche]

>From 7506756189164ad7512a896b5d74e4eb1b19a1a5 Mon Sep 17 00:00:00 2001
From: Didier Roche 
Date: Mon, 24 Nov 2014 09:43:29 +0100
Subject: [PATCH 2/5] Add a machine_id_commit call to commit on disk a
 transient machine-id

If /etc was read only at boot time with an empty /etc/machine-id, the latter
will mounted as a tmpfs and resetted at each boot. If the system becomes rw
latter, this functionality enables to commit in a race-free manner the
transient machine-id to disk.
---
 src/core/machine-id-setup.c | 122 
 src/core/machine-id-setup.h |   1 +
 2 files changed, 123 insertions(+)

diff --git a/src/core/machine-id-setup.c b/src/core/machine-id-setup.c
index 578bcfb..0cf5a73 100644
--- a/src/core/machine-id-setup.c
+++ b/src/core/machine-id-setup.c
@@ -25,7 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "systemd/sd-id128.h"
 
@@ -187,6 +189,126 @@ static int write_machine_id(int fd, char id[34]) {
 return -errno;
 }
 
+static int is_on_temporary_fs(int fd) {
+struct statfs s;
+
+if (fstatfs(fd, &s) < 0)
+return -errno;
+
+return F_TYPE_EQUAL(s.f_type, TMPFS_MAGIC) ||
+   F_TYPE_EQUAL(s.f_type, RAMFS_MAGIC);
+}
+
+int machine_id_commit(const char *root) {
+const char *etc_machine_id;
+_cleanup_close_ int fd = -1;
+_cleanup_close_ int initial_mntns_fd = -1;
+struct stat st;
+char id[34]; /* 32 + \n + \0 */
+int r;
+
+if (isempty(root))
+etc_machine_id = "/etc/machine-id";
+else {
+etc_machine_id = strappenda(root, "/etc/machine-id");
+path_kill_slashes((char*) etc_machine_id);
+}
+
+r = path_is_mount_point(etc_machine_id, false);
+if (r <= 0) {
+log_error("We expected that %s was an independent mount.", etc_machine_id);
+return r < 0 ? r : -ENOENT;
+}
+
+/* read existing machine-id */
+fd = open(etc_machine_id, O_RDONLY|O_CLOEXEC|O_NOCTTY);
+if (fd < 0) {
+log_error("Cannot open %s: %m", etc_machine_id);
+return -errno;
+}
+if (fstat(fd, &st) < 0) {
+log_error("fstat() failed: %m");
+return -errno;
+}
+if (!S_ISREG(st.st_mode)) {
+log_error("We expected %s to be a regular file.", etc_machine_id);
+return -EISDIR;
+}
+r = get_valid_machine_id(fd, id);
+if (r < 0) {
+log_error("We didn't find a valid machine-id.");
+return r;
+}
+
+r = is_on_temporary_fs(fd);
+if (r <= 0) {
+log_error("We expected %s to be a temporary file system.", etc_machine_id);
+return r;
+}
+
+fd = safe_close(fd);
+
+/* store current mount namespace */
+r = namespace_open(0, NULL, &initial_mntns_fd, NULL, NULL);
+if (r < 0) {
+log_error("Can't fetch current mount namespace: %s", strerror(r));
+return r;
+}
+
+/* switch to a new mount namespace, isolate ourself and unmount etc_machine_id in our new namespace */
+if (unshare(CLONE_NEWNS) == -1) {
+ log_error("Not enough privilege to switch to another namespace.");
+ return EPERM;
+}
+
+if (mount(NULL, "/", NULL, MS_SLAVE | MS_REC, NULL) < 0) {
+ log_error("Couldn't make-rslave / mountpoint in our private namespace.");
+ return EPERM;
+}
+
+r = umount(etc_machine_id);
+if (r < 0) {
+log_error("Failed to unmount transient %s file in our private namespace: %m", etc_machine_id);
+return -errno;
+}
+
+/* update a persistent version of etc_machine_id */
+fd = open(etc_machine_id, O_RDWR|O_CREAT|O_CLOEXEC|O_NOCTTY, 0444);
+if (fd < 0) {
+log_error("Cannot open for writing %s. This is mandatory to get a persistent machine-id: %m",
+  etc_machine_id);
+return -errno;
+}
+if (fstat(fd, &st) < 0) {
+log_error("fstat() failed: %m");
+return -errno;
+}
+if (!S_ISREG(st.st_mode)) {
+log_error("We expected %s to be a regular file.", etc_machine_id);
+return -EISDIR;
+}
+
+r = write_machine_id(fd, id);
+if (r < 0) {
+log_error("Cannot write %s: %s", etc_machine_id, strerror(r));
+return r;
+}
+
+fd = safe_close(fd);
+
+/* return to initial namespace and proceed a lazy tmpfs unmount */
+r = namespace_enter(-1, initial_mntns_fd, -1, -1);
+if (r < 0) {
+log_warning("Failed to switch back to initial mount namespace.

[systemd-devel] [PATCH 1/5] Factorize some machine-id-setup functions to be reused

[Didier Roche]

>From b4619f01b6f25752220b2fe5c5ccd22e248f4015 Mon Sep 17 00:00:00 2001
From: Didier Roche 
Date: Mon, 24 Nov 2014 09:40:57 +0100
Subject: [PATCH 1/5] Factorize some machine-id-setup functions to be reused

---
 src/core/machine-id-setup.c | 41 +++--
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/src/core/machine-id-setup.c b/src/core/machine-id-setup.c
index ce6d8e0..578bcfb 100644
--- a/src/core/machine-id-setup.c
+++ b/src/core/machine-id-setup.c
@@ -159,6 +159,34 @@ static int generate(char id[34], const char *root) {
 return 0;
 }
 
+static int get_valid_machine_id(int fd, char id[34]) {
+assert(fd >= 0);
+assert(id);
+
+if (loop_read(fd, id, 33, false) == 33 && id[32] == '\n') {
+id[32] = 0;
+
+if (id128_is_valid(id)) {
+id[32] = '\n';
+id[33] = 0;
+return 0;
+}
+}
+
+return -EINVAL;
+}
+
+static int write_machine_id(int fd, char id[34]) {
+assert(fd >= 0);
+assert(id);
+lseek(fd, 0, SEEK_SET);
+
+if (loop_write(fd, id, 33, false) == 33)
+return 0;
+
+return -errno;
+}
+
 int machine_id_setup(const char *root) {
 const char *etc_machine_id, *run_machine_id;
 _cleanup_close_ int fd = -1;
@@ -211,13 +239,8 @@ int machine_id_setup(const char *root) {
 return -errno;
 }
 
-if (S_ISREG(st.st_mode))
-if (loop_read(fd, id, 33, false) == 33 && id[32] == '\n') {
-id[32] = 0;
-
-if (id128_is_valid(id))
-return 0;
-}
+if (S_ISREG(st.st_mode) && get_valid_machine_id(fd, id) == 0)
+return 0;
 
 /* Hmm, so, the id currently stored is not useful, then let's
  * generate one */
@@ -227,9 +250,7 @@ int machine_id_setup(const char *root) {
 return r;
 
 if (S_ISREG(st.st_mode) && writable) {
-lseek(fd, 0, SEEK_SET);
-
-if (loop_write(fd, id, 33, false) == 33)
+if (write_machine_id(fd, id) == 0)
 return 0;
 }
 
-- 
2.1.3

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

Re: [systemd-devel] Hosts without /etc/machine-id on boot

[Didier Roche]

Le 21/11/2014 00:41, Lennart Poettering a écrit :

On Thu, 20.11.14 17:23, Didier Roche (didro...@ubuntu.com) wrote:


a) make /etc writable before systemd is invoked. If you use an initrd
this is without risk, given that the initrd should really invoke
fsck on the root disk anyway, and there's hence little reason to
transition to a read-only root, rather than just doing rw
right-away.

Interesting, I run that through our kernel team. However, we run fsck a
little bit later on in the boot process to be able to pipe the output to
plymouth.

At least on Fedora plymouth already runs on the initrd. If Ubuntu does
the same, then there shouldn't be a difference regarding where fsck is
run...

Note that running fsck in the initrd for the root fs is really the
right thing to do: running fsck from the file system you are about to
check, which you hence cannot trust, is really wrong.


I'm not sure we should then have two code paths:
- one fscking from the initrd if /etc/machine-id is empty (like after a
factory reset), showing the results and eventual failures to the user in
some way
- and then, the general use case: fscking through the systemd service via
systemd-fsck-root.service before local-fs.target and piping the result in
plymouth

The latter is useful only really on non-initrd boots where there isn't
any initrd where the fsck could run. General purpose distributions
should really run fsck in the initrd.

Note that systemd-fsck-root.service skips itself when it notices that
the fs was already checked (via a flag file in /run).


Indeed, that makes sense and we should investigate that with our kernel 
team in the near future. I'm going to open a thread on it.



The guarantee with /etc/machine-id is really that it is valid at *any*
time, in early boot and late boot and all the time in between.

I think I will go that path which is an interesting one and mapping some of
my thoughts. Thanks for the guidance and documentation on what's the right
approach to achieve this race-free! I'll work on something around that and
propose a patch.

Looking forword to it.


Here we go :)
I did some factorization to reuse some functions on the first path and 
added the binary helper, unit and man page.


It should follow your advice and be race-free. Tested various cases locally.

Cheers,
Didier
___
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

[Jakub Filak]

On Fri, 2014-11-21 at 21:14 +0100, Lennart Poettering wrote:
> 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.
> 

I took this format from ABRT. I will add the extra blank line.

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

Not sure, typo? Lack of caffeine?

> 
> > +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!  

Thanks, I overlooked it.

> > +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];


OK, I thought systemd prefers alloca(). I was inspired by
procfs_file_alloca().

> > +
> > +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.
> 

OK.
Just a note, it iterates until it finds the first non-existing fd.

> > +_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...

Very bad! I hate code where people cast from const to non-const. What I
was thinking about while writing this patch?

> 
> > +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.
> 

Fabulous! I think so too. I wasn't allowed to use such a construction in
other projects.



Jakub


___
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

[Łukasz Stelmach]

It was <2014-11-21 pią 21:36>, when Lennart Poettering wrote:
> 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.

Will it be necessary for this directory to be owned by systemd-network
even without networkd?

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics


pgpii7s5h9dwS.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Ł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.

Use m4 to include information associated with networkd in tmpfiles.d and
sysusers.d conditionally. Do not install it if netwrorkd is not enabled.
---
 Makefile.am|  4 
 configure.ac   |  1 +
 sysusers.d/.gitignore  |  1 +
 sysusers.d/systemd.conf| 12 
 sysusers.d/systemd.conf.m4 | 14 ++
 tmpfiles.d/.gitignore  |  3 ++-
 tmpfiles.d/systemd.conf| 32 
 tmpfiles.d/systemd.conf.m4 | 34 ++
 8 files changed, 56 insertions(+), 45 deletions(-)
 delete mode 100644 sysusers.d/systemd.conf
 create mode 100644 sysusers.d/systemd.conf.m4
 delete mode 100644 tmpfiles.d/systemd.conf
 create mode 100644 tmpfiles.d/systemd.conf.m4

diff --git a/Makefile.am b/Makefile.am
index fae946a..69d9c9e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5821,6 +5821,10 @@ src/%: src/%.m4
$(AM_V_at)$(MKDIR_P) $(dir $@)
$(AM_V_M4)$(M4) -P $(M4_DEFINES) < $< > $@
 
+sysusers.d/%: sysusers.d/%.m4
+   $(AM_V_at)$(MKDIR_P) $(dir $@)
+   $(AM_V_M4)$(M4) -P $(M4_DEFINES) < $< > $@
+
 tmpfiles.d/%: tmpfiles.d/%.m4
$(AM_V_at)$(MKDIR_P) $(dir $@)
$(AM_V_M4)$(M4) -P $(M4_DEFINES) < $< > $@
diff --git a/configure.ac b/configure.ac
index c3b4ea3..5ec2e6c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1050,6 +1050,7 @@ AC_ARG_ENABLE(networkd, 
AS_HELP_STRING([--disable-networkd], [disable networkd])
 AS_IF([test "x$enable_networkd" != "xno"], [
 AC_DEFINE(ENABLE_NETWORKD, 1, [Define if networkd support is to be 
enabled])
 have_networkd=yes
+M4_DEFINES="$M4_DEFINES -DENABLE_NETWORKD"
 ])
 AM_CONDITIONAL(ENABLE_NETWORKD, [test "x$have_networkd" = "xyes"])
 
diff --git a/sysusers.d/.gitignore b/sysusers.d/.gitignore
index f7957a9..bb3aaaf 100644
--- a/sysusers.d/.gitignore
+++ b/sysusers.d/.gitignore
@@ -1 +1,2 @@
 /basic.conf
+/systemd.conf
diff --git a/sysusers.d/systemd.conf b/sysusers.d/systemd.conf
deleted file mode 100644
index 95437b8..000
--- a/sysusers.d/systemd.conf
+++ /dev/null
@@ -1,12 +0,0 @@
-#  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.
-
-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/sysusers.d/systemd.conf.m4 b/sysusers.d/systemd.conf.m4
new file mode 100644
index 000..eeb13fb
--- /dev/null
+++ b/sysusers.d/systemd.conf.m4
@@ -0,0 +1,14 @@
+#  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.
+
+g systemd-journal   - -
+u systemd-bus-proxy - "systemd Bus Proxy"
+m4_ifdef(`ENABLE_NETWORKD',
+u systemd-network   - "systemd Network Management"
+)m4_dnl
+u systemd-resolve   - "systemd Resolver"
+u systemd-timesync  - "systemd Time Synchronization"
diff --git a/tmpfiles.d/.gitignore b/tmpfiles.d/.gitignore
index eb32315..4f0ecaa 100644
--- a/tmpfiles.d/.gitignore
+++ b/tmpfiles.d/.gitignore
@@ -1 +1,2 @@
-etc.conf
+/etc.conf
+/systemd.conf
diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf
deleted file mode 100644
index 9ca5ad2..000
--- a/tmpfiles.d/systemd.conf
+++ /dev/null
@@ -1,32 +0,0 @@
-#  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/user 0755 root root -
-F! /run/utmp 0664 root utmp -
-
-d /run/systemd/ask-password 0755 root root -
-d /run/systemd/seats 0755 root root -
-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 -
-
-z /run/log/journal 2755 root systemd-journal - -
-Z /run/log/journal/%m ~2750 root systemd-journal - -
-
-z /var/log/journal 2755 root systemd-journal - -
-z /var/log/journal/%m 2755 root systemd-journal - -
-
-d /var/lib/systemd 0755 root root -
-d /var/