date:20141202


Le 01/12/2014 18:37, Lennart Poettering a écrit :

On Mon, 24.11.14 12:35, Didier Roche (didro...@ubuntu.com) wrote:

  
+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);
+}

This should really move to util.[ch] I figure, and reuse
is_temporary_fs() that we already have there.


Thanks for your feedback.
I did introduce is_fd_on_temporary_fs() in utils.[ch] and reused 
is_temporary_fs there.



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

I think this should really work in idempotent style, i.e. so that you
exit cleanly if the thing is already a proper file.


Making sense. I downgraded the error messaging to debug and always 
returns 0. I tried other various use case and I think the functions 
(hence, the binary) is idempotent now.





+
+/* 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;
+}

Since you prepared the original patch, we improved the loggic logic of
systemd. It would be great if you would update the patch to make use
of it. In particular, this means avoiding strerror() for cases like
the above (because it is not thread-safe to use). Instead use the new
log_error_errno() that takes the error value as first parameter, and
then makes sure that %m actually evaluates to the error string for
that error. Also it will then return the error, so that you can
simplify the four lines above into:

if (r  0)
 return log_error_errno(r, Cannot write %s: %m,
 etc_machine_id);


Nice feature! I replaced it in some other places as well.



+fd =

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


Le 01/12/2014 18:38, Lennart Poettering a écrit :

On Mon, 24.11.14 12:35, Didier Roche (didro...@ubuntu.com) wrote:

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

As a matter of coding style we try hard to avoid functions that clobber
their parameters if they fail. Please follow the same scheme here.

That makes sense, I rewrote the function to avoid this.

Didier
From 7cf7322ab08c9434ba303d9958517f262b1797e0 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
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 | 44 ++--
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/src/core/machine-id-setup.c b/src/core/machine-id-setup.c
index 6710038..f3763ed 100644
--- a/src/core/machine-id-setup.c
+++ b/src/core/machine-id-setup.c
@@ -157,6 +157,37 @@ static int generate(char id[34], const char *root) {
 return 0;
 }
 
+static int get_valid_machine_id(int fd, char id[34]) {
+char id_to_validate[34];
+
+assert(fd = 0);
+assert(id);
+
+if (loop_read(fd, id_to_validate, 33, false) == 33  id_to_validate[32] == '\n') {
+id_to_validate[32] = 0;
+
+if (id128_is_valid(id_to_validate)) {
+strncpy(id, id_to_validate, sizeof(id_to_validate));
+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;
@@ -207,13 +238,8 @@ int machine_id_setup(const char *root) {
 if (fstat(fd, st)  0)
 return log_error_errno(errno, fstat() failed: %m);
 
-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 */
@@ -223,9 +249,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] [k]dbus: api, match replace and test extending

2014-12-02 Thread Rui Miguel Silva

Hi,
On Tue, Dec 02, 2014 at 03:02:17AM +0100, Lennart Poettering wrote:
 On Mon, 17.11.14 12:31, Rui Miguel Silva (rmf...@gmail.com) wrote:
 
 Heya,
 
 - technical debt, if in the future the filter mechanism is change 
by
   other than bloom.
so bloom maybe just be replaced with only generic filter could make more
sense?
   
   What do you mean by only generic filter?
   
  Maybe I did not explain myself well, what I mean is:
  Imagine that ahead we find that instead of bloom filtering mechanism, for
  example, cuckoo filters are more eficient. The api have the filter
  structs called struct kdbus_bloom_filter, my suggestion was to just change
  that to struct kdbus_filter (and no attach to filter specific
  implementation). Since they are very generic (generation and a data field)
  and for the kdbus it is just a check between a mask and a filter.
 
 I had a closer look at cuckoo filters now. The lookup logic is quite
 different from bloom filters and involves iterating through entries
 of a bucket. Now, I am not convinced that Cuckoo filters are really
 something we want to do in kdbus, but should we determine one day that
 they in fact are, then the kernel side matching of filter against mask
 needs to look very different anyway, with different data
 structures. And in that case we really should define new items for
 that, that should not overload the existing kdbus_bloom_filter
 structures but be seperate, new structs.
 
 Hope this makes sense,
Yes, it make, thanks.

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

Re: [systemd-devel] [WIP PATCH] Do not realize and migrate cgroups multiple times

2014-12-02 Thread Michal Sekletar

On Mon, Dec 01, 2014 at 12:06:03PM +0100, Martin Pitt wrote:
 Hello all,
 
 In my efforts to make user LXC containers work I noticed that under a
 real desktop (not just nspawn with VT login or ssh logins) my
 carefully set up cgroups in the non-systemd controllers get reverted.
 I. e. I put the session leader (and all other pids) of logind sessions
 (/user.slice/user-1000.slice/session-XX.scope) into all cgroup
 controllers, but a second after they are all back in the / cgroups (or
 sometimes in /user.slice). After some days of debugging (during which
 I learned a lot about the innards of systemd :-) I finally found out
 why:
 
 During unit cgroup initialization (unit_realize_cgroup), sibling
 cgroups are queued instead of initialized immediately.
 unit_create_cgroups() makes an attempt to avoid initializing and
 migrating a cgroup more than once:
 
path = unit_default_cgroup_path(u);
[...]
r = hashmap_put(u-manager-cgroup_unit, path, u);
 if (r  0) {
 log_error(r == -EEXIST ? cgroup %s exists already: %s : 
 hashmap_put failed for %s: %s, path, strerror(-r));
 return r;
 }
 
 But this doesn't work: path always gets allocated freshly in that
 function, so the pointer is never in the hashmap and the -EEXISTS
 never actually hits. This causes -.slice to be initialized and
 recursively migrated a gazillion times, which explains the random
 punting of sub-cgroup PIDs back to /.
 
 I fixed this with an explicit hashmap_get() call, which compares
 values instead of pointers.
 
 I also added some debugging to that function:
 
   log_debug(unit_create_cgroups %s: path=%s realized %i hashmap %p, u-id, 
 path, u-cgroup_realized, hashmap_get(u-manager-cgroup_unit, path));
 
 (right before the hashmap_put() above), which illustrates the
 problem:
 
 systemd[1]: Starting Root Slice.
 systemd[1]: unit_create_cgroups -.slice: path= realized 0 hashmap (nil)
 systemd[1]: Created slice Root Slice.
 [...]
 pid1 systemd[1]: unit_create_cgroups session-c1.scope: 
 path=/user.slice/user-1000.slice/session-c1.scope realized 0 hashmap (nil)
 systemd[1]: Started Session c1 of user martin.
 [... later on when most things have been started ...]
 systemd[1]: unit_create_cgroups -.slice: path= realized 1 hashmap 
 0x7f0e14aa4850
 systemd[1]: unit_create_cgroups -.slice: cgroup  exists already
 systemd[1]: Failed to realize cgroups for queued unit user.slice: File exists
 systemd[1]: unit_create_cgroups -.slice: path= realized 1 hashmap 
 0x7f0e14aa4850
 systemd[1]: unit_create_cgroups -.slice: cgroup  exists already
 systemd[1]: Failed to realize cgroups for queued unit grub-common.slice: File 
 exists
 systemd[1]: unit_create_cgroups -.slice: path= realized 1 hashmap 
 0x7f0e14aa4850
 systemd[1]: unit_create_cgroups -.slice: cgroup  exists already
 systemd[1]: Failed to realize cgroups for queued unit networking.slice: File 
 exists
 
 ... and so on, basically once for each .service.
 
 Initializing -.slice so many times is certainly an unintended effect
 of the peer cgroup creation. Thus the patch fixes the multiple
 initialization/creation, but a proper fix should also quiesce these
 error messages. The condition could be checked explicitly, i. e. we
 skip the Failed to realize... error for EEXISTS, or we generally
 tone this down to log_debug. I'm open to suggestions. And of course
 the log_debug should be removed; it's nice to illustrate the problem,
 but doesn't really belong into production code.
 
 Thanks,
 
 Martin

Also this looks like a possible fix to the problem I tried to describe in,

http://lists.freedesktop.org/archives/systemd-devel/2014-November/025607.html

Michal

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

 From fd2f8a444c9c644a39dd3b619934e8768e03c2a3 Mon Sep 17 00:00:00 2001
 From: Martin Pitt martin.p...@ubuntu.com
 Date: Mon, 1 Dec 2014 10:50:06 +0100
 Subject: [PATCH] Do not realize and migrate cgroups multiple times
 
 unit_create_cgroups() tries to check if a cgroup already exists. But has the
 destination path is always allocated dynamically as a new string, that pointer
 will never already be in the hashmap, thus hashmap_put() will never actually
 fail with EEXISTS. Thus check for the existance of the cgroup path explicitly.
 
 Before this, -.slice got initialized and its child PIDs migrated many times
 through queuing the realization of sibling units; thiss caused any cgroup
 controller layout from sub-cgroups to be reverted and their pids moved back to
 the root cgroup in all controllers (except systemd).
 ---
  src/core/cgroup.c | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/src/core/cgroup.c b/src/core/cgroup.c
 index 8820bee..3d36080 100644
 --- a/src/core/cgroup.c
 +++ b/src/core/cgroup.c
 @@ -614,6 +614,13 @@ static int unit_create_cgroups(Unit *u, 
 CGroupControllerMask mask) {
  if (!path)

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

Just to sum up other branches of this thread: we are trying to avoid 
having systemctl calls in debian/ubuntu postinst (or duplicated manual 
symlinks logic as we currently have).
systemctl preset seems the cleanest path, but we want to ensure corner 
cases can be handled.


d/u policy is to enable newly installed package by default (difference 
from other distributions)


Le 02/12/2014 01:59, Lennart Poettering a écrit :

On Fri, 28.11.14 11:15, Didier Roche (didro...@ubuntu.com) wrote:


The distribution comes preinstalled with one dm, enable * - enable it, have
the Alias=display-manager.service picking the right one.
However, let's say the user installed then another dm, what happens? Both
will be enabled if we systemctl preset new_service (as the discussion was
to remove our debian enable service that was conditioned on the
postinst).

systemctl preset will fail if there are already conflicting
symlinks. Hence the first installed DM wins, the second loses.


Ok, that works with the initial install case then.
However, if lightdm is installed and the admin install gdm, he will get 
a prompt (from postinst) asking him which dm to choose. How would you 
handle that (without messing manually with the symlinks or systemctl 
enable --force in the postinst?). Writing new presets in /etc which 
enables the chosen dm and disable other, then reloading preset file to 
reset that display-manager.service alias?





I don't think we should have systemctl preset new_service running under
any condition as a wipe of /etc and then systemctl preset-all would give a
potential different result (I'm not even sure how this will work with those
alias, the first matching the alias wins and get the symlinks?)

Dont follow? wipe?


I meant deleting the entire /etc content (or I guess as you told using 
systemctl preset-all to reset to default):


1. lightdm and gdm were installed on my system.
2. gdm was enabled as the default display-manager.
3. I then use systemctl preset-all
- how the behavior of selecting the display-manager will be determined? 
See below implementing this with presets where enabling all services is 
the default.



We can of course have an ubuntu-desktop.preset which disables all dms by
lightdm, and an ubuntu-gnome.preset which disables all dms but gdm (and
having those settings conflicting with each other), but it's seems that for
every aliases, we need to maintain such a list (as we enable * by
default)?

Not following here. Different flavours of Ubuntu should probably just
ship different preset files. (Or well, the main ubuntu should ship one
that enables lightdm, and then the gnome flavour ship another preset
file, with a lower name, tht overries the lightdm line, and enables
gdm instead).


You meant disable, right? As our default is to enable all services.
So we need for any services shipping Aliases to have a preset list per 
flavor (if their behaviors differs) with:

99-ubuntu-desktop.preset:
enable lightdm.service
disable kdm.service
disable gdm.service
disable nodm.service
(and whatnot… dm files in distro)

Then, we would have 01-ubuntu-gnome.preset:
enable gdm.service
disable lightdm.service
disable kdm.service
…

It seems maintaining this list in sync for all flavors would be a 
growing pain (this is a positive effect of the disable by default: you 
don't have to maintain such a list), or do you think we can come with 
something better?



Finally, on the know what the administrator did on this machine, here 
are two cases that we can identify:


I. if the administrator removes the service package, we usually keep 
current service state (enabled/disabled) on reinstall.

So:
foo.service enabled by default
1. systemctl disable foo.service
2. apt-get remove foo
3. apt-get install foo
- foo should still be disabled. However, that won't be the case as on 
reinstall, systemctl preset will re-enable the service as of the preset 
policy.
Indeed, we don't have any record that the admin disabled it compared 
default distro policy as there is no difference between: no previous 
installation state and service being disabled state (no symlink).


Same for enabling a service that is by default disabled: next systemctl 
call on reinstall will remove the symlinks (Alias included).



II. if the adminstrator purges the service package, we usually expect 
that reinstalling it will reset the service to the default 
enablement/disablement state.

So:
foo.service enabled by default
1. systemctl disable foo.service
2. apt-get remove --purge foo
3. apt-get install foo
- foo should be enabled as this is the default state in distro.
This use case works because the previous one doesn't :)

So, I think we should really be able to fix case I. Also, we would have 
to condition the systemctl preset call (we have idempotent postinst 
script, and need to track new installs from upgrade, as we run those 
during postinst configure). We proposed the separate /usr vs /etc as 
this would have been a simple way to know what the

Re: [systemd-devel] [WIP PATCH] Do not realize and migrate cgroups multiple times

2014-12-02 Thread Martin Pitt

Michal Sekletar [2014-12-02 12:32 +0100]:
 Also this looks like a possible fix to the problem I tried to describe in,
 
 http://lists.freedesktop.org/archives/systemd-devel/2014-November/025607.html

Yes, most probably. While I found that bug in the context of LXC user
containers, it's by no means restricted to that case. Any unit which
sets up cgroups in other controllers will be affected by that.

Martin

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

Re: [systemd-devel] [systemd-commits] 8 commits - src/libsystemd src/network src/shared src/systemd

On Tue, 02.12.14 01:50, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:

  
 +/* IEEE Organizationally Unique Identifier vendor string */
 +static int ieee_oui(struct udev_hwdb *hwdb, struct ether_addr *mac, char 
 **ret) {
 +struct udev_list_entry *entry;
 +char *description;
 +char str[32];

Shouldnt this be 4 + 6*2 + 1?

 +
 +/* skip commonly misused 00:00:00 (Xerox) prefix */
 +if (memcmp(mac, \0\0\0, 3) == 0)
 +return -EINVAL;
 +
 +snprintf(str, sizeof(str), OUI:%02X%02X%02X%02X%02X%02X, 
 mac-ether_addr_octet[0], mac-ether_addr_octet[1], mac-ether_addr_octet[2],
 +   
 mac-ether_addr_octet[3], mac-ether_addr_octet[4], mac-ether_addr_octet[5]);
 +

Hmm, maybe we should have a new set of macros for this, similar to
SD_ID128_FORMAT_STR and SD_ID128_FORMAT_VAL?


 +udev_list_entry_foreach(entry, 
 udev_hwdb_get_properties_list_entry(hwdb, str, 0))
 +if (strcmp(udev_list_entry_get_name(entry), 
 ID_OUI_FROM_DATABASE) == 0) {
 +description = 
 strdup(udev_list_entry_get_value(entry));
 +if (!description)
 +return -ENOMEM;
 +
 +*ret = description;
 +return 0;
 +}

Hmm, why not just call udev_device_get_property_value()?

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] /usr vs /etc for default distro units enablement

On Tue, 02.12.14 01:29, Lennart Poettering (lenn...@poettering.net) wrote:

 On Tue, 18.11.14 14:10, Tom Gundersen (t...@jklm.no) wrote:
 
   - We are mixing sys admin information and distro default choices in the 
   same
   directories, and can't tell apart what is what.
  
  That is true. Could we perhaps improve on systemctl by printing
  enabled (preset)/disable (preset) for units that are in the
  default state? I know this does not change the fact that you have
  distro-default (via presets) links in /etc, but it should give the
  end-user a nicer experienc I guess?
 
 Sounds like a good idea. Added to TODO list.

Implemented now.

Lennart

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

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

2014-12-02 Thread Colin Guthrie

Didier Roche wrote on 02/12/14 11:50:
 Just to sum up other branches of this thread: we are trying to avoid
 having systemctl calls in debian/ubuntu postinst (or duplicated manual
 symlinks logic as we currently have).
 systemctl preset seems the cleanest path, but we want to ensure corner
 cases can be handled.
 
 d/u policy is to enable newly installed package by default (difference
 from other distributions)
 
 Le 02/12/2014 01:59, Lennart Poettering a écrit :
 On Fri, 28.11.14 11:15, Didier Roche (didro...@ubuntu.com) wrote:

 The distribution comes preinstalled with one dm, enable * - enable
 it, have
 the Alias=display-manager.service picking the right one.
 However, let's say the user installed then another dm, what happens?
 Both
 will be enabled if we systemctl preset new_service (as the
 discussion was
 to remove our debian enable service that was conditioned on the
 postinst).
 systemctl preset will fail if there are already conflicting
 symlinks. Hence the first installed DM wins, the second loses.
 
 Ok, that works with the initial install case then.
 However, if lightdm is installed and the admin install gdm, he will get
 a prompt (from postinst) asking him which dm to choose. How would you
 handle that (without messing manually with the symlinks or systemctl
 enable --force in the postinst?). 

If you are giving the user a choice here specifically, then calling
systemctl enable --force is, IMO, the right thing to do.


 Writing new presets in /etc which
 enables the chosen dm and disable other, then reloading preset file to
 reset that display-manager.service alias?

I would say that the preset file would be in place for the GNOME spin
such that when it was installed, it would be enabled. The GNOME spin's
installer would likely not install lightdm in the first place and thus
gdm would get enabled when it was installed anyway (with your default
enable policy)

That said, as your policy is to enable things by default, you might want
to actually list all the dms as disable in your standard .preset file
and then have a separate .preset file to enable the appropriate dm that
is shipped with your various spins. That way, simply installing a dm is
not enough to enable it via the default policy. This guards against
needing to stop lightdm being installed on the GNOME spin - installing
would be unneeded, but not problematic - and both lightdm and gdm could
both be installed happily and only gdm would be enabled due to preset.



 I don't think we should have systemctl preset new_service running
 under
 any condition as a wipe of /etc and then systemctl preset-all would
 give a
 potential different result (I'm not even sure how this will work with
 those
 alias, the first matching the alias wins and get the symlinks?)
 Dont follow? wipe?
 
 I meant deleting the entire /etc content (or I guess as you told using
 systemctl preset-all to reset to default):
 
 1. lightdm and gdm were installed on my system.
 2. gdm was enabled as the default display-manager.
 3. I then use systemctl preset-all
 - how the behavior of selecting the display-manager will be determined?
 See below implementing this with presets where enabling all services is
 the default.

Yeah, I can see this problem. I guess the setup of preset files as I
mentioned above would deal with this.

I guess the problem doesn't exist on Fedora due to it's disable *
default policy and the easiest way to get the same behaviour would be to
just list all dms as disable in your default .preset file and then
enable them all again via drop in as needed (it's not quite as clean but
it's certainly manageable IMO)


 We can of course have an ubuntu-desktop.preset which disables all dms by
 lightdm, and an ubuntu-gnome.preset which disables all dms but gdm (and
 having those settings conflicting with each other), but it's seems
 that for
 every aliases, we need to maintain such a list (as we enable * by
 default)?
 Not following here. Different flavours of Ubuntu should probably just
 ship different preset files. (Or well, the main ubuntu should ship one
 that enables lightdm, and then the gnome flavour ship another preset
 file, with a lower name, tht overries the lightdm line, and enables
 gdm instead).
 
 You meant disable, right? As our default is to enable all services.
 So we need for any services shipping Aliases to have a preset list per
 flavor (if their behaviors differs) with:
 99-ubuntu-desktop.preset:
 enable lightdm.service
 disable kdm.service
 disable gdm.service
 disable nodm.service
 (and whatnot… dm files in distro)
 
 Then, we would have 01-ubuntu-gnome.preset:
 enable gdm.service
 disable lightdm.service
 disable kdm.service
 …
 
 It seems maintaining this list in sync for all flavors would be a
 growing pain (this is a positive effect of the disable by default: you
 don't have to maintain such a list), or do you think we can come with
 something better?

I should read emails to the bottom I guess - seems you see the same
issue here :)

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

2014-12-02 Thread Jóhann B. Guðmundsson



On 11/25/2014 02:09 AM, Flavio Leitner wrote:

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?


Post an link to the pasted initscripts currently being used.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] 8 commits - src/libsystemd src/network src/shared src/systemd

2014-12-02 Thread David Herrmann

Hi

On Tue, Dec 2, 2014 at 1:18 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 02.12.14 01:50, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
 +udev_list_entry_foreach(entry, 
 udev_hwdb_get_properties_list_entry(hwdb, str, 0))
 +if (strcmp(udev_list_entry_get_name(entry), 
 ID_OUI_FROM_DATABASE) == 0) {
 +description = 
 strdup(udev_list_entry_get_value(entry));
 +if (!description)
 +return -ENOMEM;
 +
 +*ret = description;
 +return 0;
 +}

 Hmm, why not just call udev_device_get_property_value()?

That would require a udev_device, but we just have the RTNL
information at this point. That's why we have to query the hwdb
directly, instead of a udev-device. We might wanna add a
udev_hwdb_get_property_value() just like the udev-device equivalent,
though.

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

Re: [systemd-devel] [systemd-commits] 8 commits - src/libsystemd src/network src/shared src/systemd

2014-12-02 Thread Tom Gundersen

On Tue, Dec 2, 2014 at 1:42 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Tue, Dec 2, 2014 at 1:18 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Tue, 02.12.14 01:50, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
 +udev_list_entry_foreach(entry, 
 udev_hwdb_get_properties_list_entry(hwdb, str, 0))
 +if (strcmp(udev_list_entry_get_name(entry), 
 ID_OUI_FROM_DATABASE) == 0) {
 +description = 
 strdup(udev_list_entry_get_value(entry));
 +if (!description)
 +return -ENOMEM;
 +
 +*ret = description;
 +return 0;
 +}

 Hmm, why not just call udev_device_get_property_value()?

 That would require a udev_device, but we just have the RTNL
 information at this point.

More importantly it would require the udev_device from the remote
machine. So yeah, we are just matching the gateway's mac address
against the hwdb directly.

 That's why we have to query the hwdb
 directly, instead of a udev-device. We might wanna add a
 udev_hwdb_get_property_value() just like the udev-device equivalent,
 though.

Yeah, makes sense I guess.

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

[systemd-devel] [PATCH] localed: forward xkbcommon errors

2014-12-02 Thread Jan Synacek

The errors are prefixed with libxkbcommon, because they are quite
confusing. With the prefix, we at least know where they come from.
---
 src/locale/localed.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/locale/localed.c b/src/locale/localed.c
index 4e56382..ea54798 100644
--- a/src/locale/localed.c
+++ b/src/locale/localed.c
@@ -1011,10 +1011,16 @@ static int method_set_vc_keyboard(sd_bus *bus, 
sd_bus_message *m, void *userdata
 
 #ifdef HAVE_XKBCOMMON
 static void log_xkb(struct xkb_context *ctx, enum xkb_log_level lvl, const 
char *format, va_list args) {
-/* suppress xkb messages for now */
+_cleanup_free_ char *fmt = NULL;
+sd_bus_error *e;
+
+if (asprintf(fmt, libxkbcommon: %s, format)  0)
+(void) log_oom();
+e = xkb_context_get_user_data(ctx);
+bus_error_setfv(e, SD_BUS_ERROR_INVALID_ARGS, fmt, args);
 }
 
-static int verify_xkb_rmlvo(const char *model, const char *layout, const char 
*variant, const char *options) {
+static int verify_xkb_rmlvo(const char *model, const char *layout, const char 
*variant, const char *options, sd_bus_error *error) {
 const struct xkb_rule_names rmlvo = {
 .model  = model,
 .layout = layout,
@@ -1033,6 +1039,7 @@ static int verify_xkb_rmlvo(const char *model, const char 
*layout, const char *v
 goto exit;
 }
 
+xkb_context_set_user_data(ctx, (void *)error);
 xkb_context_set_log_fn(ctx, log_xkb);
 
 km = xkb_keymap_new_from_names(ctx, rmlvo, 
XKB_KEYMAP_COMPILE_NO_FLAGS);
@@ -1049,7 +1056,7 @@ exit:
 return r;
 }
 #else
-static int verify_xkb_rmlvo(const char *model, const char *layout, const char 
*variant, const char *options) {
+static int verify_xkb_rmlvo(const char *model, const char *layout, const char 
*variant, const char *options, sd_bus_error *error) {
 return 0;
 }
 #endif
@@ -1087,7 +1094,7 @@ static int method_set_x11_keyboard(sd_bus *bus, 
sd_bus_message *m, void *userdat
 (options  !string_is_safe(options)))
 return sd_bus_error_set_errnof(error, -EINVAL, 
Received invalid keyboard data);
 
-r = verify_xkb_rmlvo(model, layout, variant, options);
+r = verify_xkb_rmlvo(model, layout, variant, options, error);
 if (r  0)
 log_warning(Cannot compile XKB keymap for new x11 
keyboard layout ('%s' / '%s' / '%s' / '%s'): %s,
 strempty(model), strempty(layout), 
strempty(variant), strempty(options), strerror(-r));
-- 
1.9.3

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

Re: [systemd-devel] [systemd-commits] 8 commits - src/libsystemd src/network src/shared src/systemd

2014-12-02 Thread Tom Gundersen

On Tue, Dec 2, 2014 at 1:18 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 02.12.14 01:50, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:


 +/* IEEE Organizationally Unique Identifier vendor string */
 +static int ieee_oui(struct udev_hwdb *hwdb, struct ether_addr *mac, char 
 **ret) {
 +struct udev_list_entry *entry;
 +char *description;
 +char str[32];

 Shouldnt this be 4 + 6*2 + 1?

 +
 +/* skip commonly misused 00:00:00 (Xerox) prefix */
 +if (memcmp(mac, \0\0\0, 3) == 0)
 +return -EINVAL;
 +
 +snprintf(str, sizeof(str), OUI:%02X%02X%02X%02X%02X%02X, 
 mac-ether_addr_octet[0], mac-ether_addr_octet[1], mac-ether_addr_octet[2],
 +   
 mac-ether_addr_octet[3], mac-ether_addr_octet[4], 
 mac-ether_addr_octet[5]);
 +

 Hmm, maybe we should have a new set of macros for this, similar to
 SD_ID128_FORMAT_STR and SD_ID128_FORMAT_VAL?

Fixed both these now. Thanks!

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

Re: [systemd-devel] reacting to unit failures (OnFailure)

2014-12-02 Thread Nekrasov, Alexander

Meaning that I have to create a myfailureunitname.service file/unit for every 
unit I want to register for? Which in my case is going to be almost all of 
them, in a high availability system

 -Original Message-
 From: Lennart Poettering [mailto:lenn...@poettering.net]
 Sent: Monday, December 01, 2014 5:46 PM
 To: Nekrasov, Alexander
 Cc: systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] reacting to unit failures (OnFailure)

 On Mon, 01.12.14 17:10, Nekrasov, Alexander (alexander.nekra...@emc.com)
 wrote:

  Hello,

  While converting from Upstart to SystemD, came upon this issue. Is
 this case not covered or am I missing something?

  In Upstart, I can start a job when another job fails, and there's a
 $JOB variable that tells me what was the job that failed.

  start on (stopped RESULT=failed PROCESS=post-stop)

  script
  echo this just failed: $JOB
  end script

  In SystemD I can register a unit to be started when another unit
  fails. But there seems to be no way of knowing what unit failed. Is
  that correct?

 The idea is that you use OnFailure=myfailureunit@%n.service. %n is
 automatically replaced by the name of the unit you place this
 in. Then, in the failure unit you can identify the instance again with
 %i or %I.

 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] localed: forward xkbcommon errors

2014-12-02 Thread Ronny Chevalier

2014-12-02 14:02 GMT+01:00 Jan Synacek jsyna...@redhat.com:
Hi,

 The errors are prefixed with libxkbcommon, because they are quite
 confusing. With the prefix, we at least know where they come from.
 ---
  src/locale/localed.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

 diff --git a/src/locale/localed.c b/src/locale/localed.c
 index 4e56382..ea54798 100644
 --- a/src/locale/localed.c
 +++ b/src/locale/localed.c
 @@ -1011,10 +1011,16 @@ static int method_set_vc_keyboard(sd_bus *bus, 
 sd_bus_message *m, void *userdata

  #ifdef HAVE_XKBCOMMON
  static void log_xkb(struct xkb_context *ctx, enum xkb_log_level lvl, const 
 char *format, va_list args) {
 -/* suppress xkb messages for now */
 +_cleanup_free_ char *fmt = NULL;
 +sd_bus_error *e;
 +
 +if (asprintf(fmt, libxkbcommon: %s, format)  0)
 +(void) log_oom();
If you only need to concatenate you can use strjoin and since this is
only valid for this scope, strappenda is even more appropriate here.

 +e = xkb_context_get_user_data(ctx);
 +bus_error_setfv(e, SD_BUS_ERROR_INVALID_ARGS, fmt, args);
  }

 -static int verify_xkb_rmlvo(const char *model, const char *layout, const 
 char *variant, const char *options) {
 +static int verify_xkb_rmlvo(const char *model, const char *layout, const 
 char *variant, const char *options, sd_bus_error *error) {
  const struct xkb_rule_names rmlvo = {
  .model  = model,
  .layout = layout,
 @@ -1033,6 +1039,7 @@ static int verify_xkb_rmlvo(const char *model, const 
 char *layout, const char *v
  goto exit;
  }

 +xkb_context_set_user_data(ctx, (void *)error);
  xkb_context_set_log_fn(ctx, log_xkb);

  km = xkb_keymap_new_from_names(ctx, rmlvo, 
 XKB_KEYMAP_COMPILE_NO_FLAGS);
 @@ -1049,7 +1056,7 @@ exit:
  return r;
  }
  #else
 -static int verify_xkb_rmlvo(const char *model, const char *layout, const 
 char *variant, const char *options) {
 +static int verify_xkb_rmlvo(const char *model, const char *layout, const 
 char *variant, const char *options, sd_bus_error *error) {
  return 0;
  }
  #endif
 @@ -1087,7 +1094,7 @@ static int method_set_x11_keyboard(sd_bus *bus, 
 sd_bus_message *m, void *userdat
  (options  !string_is_safe(options)))
  return sd_bus_error_set_errnof(error, -EINVAL, 
 Received invalid keyboard data);

 -r = verify_xkb_rmlvo(model, layout, variant, options);
 +r = verify_xkb_rmlvo(model, layout, variant, options, error);
  if (r  0)
  log_warning(Cannot compile XKB keymap for new x11 
 keyboard layout ('%s' / '%s' / '%s' / '%s'): %s,
  strempty(model), strempty(layout), 
 strempty(variant), strempty(options), strerror(-r));
 --
 1.9.3

 ___
 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

[systemd-devel] [PATCH v4 1/4] bus: StartTransientUnit can have aux unit

---
 src/core/dbus-manager.c | 123 +---
 1 file changed, 105 insertions(+), 18 deletions(-)

diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 0994d7b..643aa8b 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -615,6 +615,93 @@ static int method_set_unit_properties(sd_bus *bus, 
sd_bus_message *message, void
 return bus_unit_method_set_properties(bus, message, u, error);
 }
 
+static int transient_unit_from_message(
+Manager *m,
+sd_bus_message *message,
+const char *name,
+Unit **unit,
+sd_bus_error *error) {
+
+Unit *u;
+int r;
+
+assert(m);
+assert(message);
+assert(name);
+
+r = manager_load_unit(m, name, NULL, error, u);
+if (r  0)
+return r;
+
+if (u-load_state != UNIT_NOT_FOUND ||
+set_size(u-dependencies[UNIT_REFERENCED_BY])  0)
+return sd_bus_error_setf(error,
+ BUS_ERROR_UNIT_EXISTS,
+ Unit %s already exists.,
+ name);
+
+/* OK, the unit failed to load and is unreferenced, now let's
+ * fill in the transient data instead */
+r = unit_make_transient(u);
+if (r  0)
+return r;
+
+/* Set our properties */
+r = bus_unit_set_properties(u, message, UNIT_RUNTIME, false, error);
+if (r  0)
+return r;
+
+*unit = u;
+
+return 0;
+}
+
+static int try_aux_units_in_message(
+Manager *m,
+sd_bus_message *message,
+sd_bus_error *error) {
+
+Unit *u;
+char *name = NULL;
+int r;
+
+assert(m);
+assert(message);
+
+r = sd_bus_message_enter_container(message, 'a', (sa(sv)));
+if (r  0)
+return r;
+
+while ((r = sd_bus_message_enter_container(message, 'r', sa(sv)))  
0) {
+if (r = 0)
+return r;
+
+r = sd_bus_message_read(message, s, name);
+if (r  0)
+return r;
+
+r = transient_unit_from_message(m, message, name, u, error);
+if (r  0  r != -EEXIST)
+return r;
+
+r = sd_bus_message_exit_container(message);
+if (r  0)
+return r;
+
+r = unit_load(u);
+if (r  0)
+return r;
+}
+if (r  0)
+return r;
+
+r = sd_bus_message_exit_container(message);
+if (r  0)
+return r;
+
+return 0;
+}
+
 static int method_start_transient_unit(sd_bus *bus, sd_bus_message *message, 
void *userdata, sd_bus_error *error) {
 const char *name, *smode;
 Manager *m = userdata;
@@ -631,7 +718,9 @@ static int method_start_transient_unit(sd_bus *bus, 
sd_bus_message *message, voi
 if (r  0)
 return r;
 if (r == 0)
-return 1; /* No authorization for now, but the async polkit 
stuff will call us again when it has it */
+/* No authorization for now, but the async polkit
+ * stuff will call us again when it has it */
+return 1;
 
 r = sd_bus_message_read(message, ss, name, smode);
 if (r  0)
@@ -639,34 +728,32 @@ static int method_start_transient_unit(sd_bus *bus, 
sd_bus_message *message, voi
 
 t = unit_name_to_type(name);
 if (t  0)
-return sd_bus_error_setf(error, SD_BUS_ERROR_INVALID_ARGS, 
Invalid unit type.);
+return sd_bus_error_setf(error,
+ SD_BUS_ERROR_INVALID_ARGS,
+ Invalid unit type.);
 
 if (!unit_vtable[t]-can_transient)
-return sd_bus_error_setf(error, SD_BUS_ERROR_INVALID_ARGS, 
Unit type %s does not support transient units., unit_type_to_string(t));
-
-mode = job_mode_from_string(smode);
-if (mode  0)
-return sd_bus_error_setf(error, SD_BUS_ERROR_INVALID_ARGS, 
Job mode %s is invalid., smode);
+return sd_bus_error_setf(error,
+ SD_BUS_ERROR_INVALID_ARGS,
+ Unit type %s does not support 
transient units.,
+ unit_type_to_string(t));
 
 r = mac_selinux_access_check(message, start, error);
 if (r  0)
 return r;
 
-r = manager_load_unit(m, name, NULL, error, u);
-if (r  0)
-return r;
-
-if (u-load_state != UNIT_NOT_FOUND || 
set_size(u-dependencies[UNIT_REFERENCED_BY])  0)
-

[systemd-devel] [PATCH v4 2/4] timer: timer can be a transient unit

---
 src/core/dbus-timer.c | 159 ++
 src/core/dbus-timer.h |   3 +
 src/core/timer.c  |   4 ++
 3 files changed, 166 insertions(+)

diff --git a/src/core/dbus-timer.c b/src/core/dbus-timer.c
index f1f8c54..e916f5a 100644
--- a/src/core/dbus-timer.c
+++ b/src/core/dbus-timer.c
@@ -24,6 +24,8 @@
 #include dbus-unit.h
 #include dbus-timer.h
 #include bus-util.h
+#include errno-list.h
+#include strv.h
 
 static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_result, timer_result, 
TimerResult);
 
@@ -183,3 +185,160 @@ const sd_bus_vtable bus_timer_vtable[] = {
 SD_BUS_PROPERTY(WakeSystem, b, bus_property_get_bool, 
offsetof(Timer, wake_system), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_VTABLE_END
 };
+
+static int bus_timer_set_transient_property(
+Timer *t,
+const char *name,
+sd_bus_message *message,
+UnitSetPropertiesMode mode,
+sd_bus_error *error) {
+
+const char *str;
+int r;
+
+assert(t);
+assert(name);
+assert(message);
+
+if (STR_IN_SET(name,
+   OnActiveSec,
+   OnBootSec,
+   OnStartupSec,
+   OnUnitActiveSec,
+   OnUnitInactiveSec)) {
+
+TimerValue *v;
+TimerBase b = _TIMER_BASE_INVALID;
+usec_t u = 0;
+
+b = timer_base_from_string(name);
+if (b  0)
+return 0;
+
+r = sd_bus_message_read(message, t, u);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+unit_write_drop_in_private_format(UNIT(t),
+  mode,
+  name,
+  %s=%lu\n,
+  name,
+  u);
+
+v = new0(TimerValue, 1);
+if (!v)
+return -ENOMEM;
+
+v-base = b;
+v-value = u;
+
+LIST_PREPEND(value, t-values, v);
+}
+
+return 1;
+
+} else if (streq(name, OnCalendar)) {
+
+TimerValue *v;
+CalendarSpec *c = NULL;
+
+r = sd_bus_message_read(message, s, str);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+r = calendar_spec_from_string(str, c);
+if (r  0)
+return r;
+
+unit_write_drop_in_private_format(UNIT(t),
+  mode,
+  name,
+  %s=%s\n,
+  name,
+  str);
+
+v = new0(TimerValue, 1);
+if (!v) {
+if (c)
+calendar_spec_free(c);
+return -ENOMEM;
+}
+
+v-base = TIMER_CALENDAR;
+v-calendar_spec = c;
+
+LIST_PREPEND(value, t-values, v);
+}
+
+return 1;
+
+} else if (streq(name, AccuracySec)) {
+
+usec_t u = 0;
+
+r = sd_bus_message_read(message, t, u);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+t-accuracy_usec = u;
+unit_write_drop_in_private_format(UNIT(t),
+  mode,
+  name,
+  %s=%lu\n,
+  name,
+  u);
+}
+
+return 1;
+
+} else if (streq(name, WakeSystem)) {
+
+int b;
+
+r = sd_bus_message_read(message, b, b);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+t-wake_system = b;
+unit_write_drop_in_private_format(UNIT(t),
+  mode,
+  name,
+

[systemd-devel] [PATCH v4 4/4] run: introduce timer support option

Supported timer options --on-active=, --on-boot=, --on-startup=,
--on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options
corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=,
OnUnitActiveSec=, OnUnitInactiveSec= of timer respectively.
---
 man/systemd-run.xml  |  42 +++
 src/libsystemd/sd-bus/bus-util.c |  14 +-
 src/run/run.c| 583 ---
 3 files changed, 539 insertions(+), 100 deletions(-)

diff --git a/man/systemd-run.xml b/man/systemd-run.xml
index 28a9878..abac26c 100644
--- a/man/systemd-run.xml
+++ b/man/systemd-run.xml
@@ -210,6 +210,37 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   xi:include href=user-system-options.xml xpointer=host /
   xi:include href=user-system-options.xml xpointer=machine /
 
+  varlistentry
+termoption--on-active=/option/term
+termoption--on-boot=/option/term
+termoption--on-startup=/option/term
+termoption--on-unit-active=/option/term
+termoption--on-unit-inactive=/option/term
+
+listitemparaDefines monotonic timers relative to different
+starting points. Also see varnameOnActiveSec=/varname,
+varnameOnBootSec=/varname,
+varnameOnStartupSec=/varname,
+varnameOnUnitActiveSec=/varname and
+varnameOnUnitInactiveSec=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+option has no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termoption--on-calendar=/option/term
+
+listitemparaDefines realtime (i.e. wallclock) timers with
+calendar event expressions. Also see
+varnameOnCalendar=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+option has no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
   xi:include href=standard-options.xml xpointer=help /
   xi:include href=standard-options.xml xpointer=version /
 /variablelist
@@ -250,6 +281,16 @@ Sep 08 07:37:21 bupkis env[19948]: 
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.
 property./para
 
 programlisting# systemd-run -p BlockIOWeight=10 updatedb/programlisting
+
+paraThe following command will touch a file after 10 seconds./para
+
+programlisting# date; systemd-run --on-active=10 touch /tmp/hello
+Mon Oct 27 20:02:57 KST 2014
+Running as unit run-66.timer.
+# journalctl -u run-115.service
+-- Logs begin at Mon 2014-10-27 19:44:57 KST, end at Mon 2014-10-27 20:03:15 
KST. --
+Oct 27 20:03:15 container systemd[1]: Starting /bin/touch /tmp/hello...
+Oct 27 20:03:15 container systemd[1]: Started /bin/touch 
/tmp/hello./programlisting
   /refsect1
 
   refsect1
@@ -263,6 +304,7 @@ Sep 08 07:37:21 bupkis env[19948]: 
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.
   
citerefentryrefentrytitlesystemd.slice/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd.exec/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd.resource-control/refentrytitlemanvolnum5/manvolnum/citerefentry,
+  
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlemachinectl/refentrytitlemanvolnum1/manvolnum/citerefentry
 /para
   /refsect1
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index bdaa449..0f1a89c 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -1372,7 +1372,8 @@ int bus_append_unit_property_assignment(sd_bus_message 
*m, const char *assignmen
 
 if (STR_IN_SET(field,
CPUAccounting, MemoryAccounting, 
BlockIOAccounting,
-   SendSIGHUP, SendSIGKILL)) {
+   SendSIGHUP, SendSIGKILL,
+   WakeSystem)) {
 
 r = parse_boolean(eq);
 if (r  0) {
@@ -1533,6 +1534,17 @@ int bus_append_unit_property_assignment(sd_bus_message 
*m, const char *assignmen
 
 r = sd_bus_message_append(m, v, i, sig);
 
+} else if (streq(field, AccuracySec)) {
+usec_t u;
+
+r = parse_sec(eq, u);
+if (r  0) {
+log_error(Failed to parse %s value %s, field, eq);
+return -EINVAL;
+}
+
+r = sd_bus_message_append(m, v, t, u);
+
 } else {
 log_error(Unknown assignment %s., assignment);
 return -EINVAL;
diff --git a/src/run/run.c b/src/run/run.c
index 85eb052..03f49df 100644
--- a/src/run/run.c
+++ b/src/run/run.c
@@ -30,6 +30,7 @@
 #include env-util.h
 #include path-util.h
 #include bus-error.h
+#include calendarspec.h
 
 static

[systemd-devel] [PATCH v4 3/4] unit: add UnitMask enum and get unit scope(mask) api from property

---
 Makefile.am  |   7 ++
 src/shared/.gitignore|   1 +
 src/shared/unit-name.c   |  22 
 src/shared/unit-name.h   |  26 +
 src/shared/unit-property-scope.gperf | 202 +++
 5 files changed, 258 insertions(+)
 create mode 100644 src/shared/unit-property-scope.gperf

diff --git a/Makefile.am b/Makefile.am
index 38d320f..3cec5fb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -819,6 +819,7 @@ libsystemd_shared_la_SOURCES = \
src/shared/cgroup-show.h \
src/shared/unit-name.c \
src/shared/unit-name.h \
+   src/shared/unit-property-scope.c \
src/shared/utmp-wtmp.h \
src/shared/watchdog.c \
src/shared/watchdog.h \
@@ -907,6 +908,12 @@ libsystemd_shared_la_CFLAGS = \
$(SECCOMP_CFLAGS) \
-pthread
 
+EXTRA_DIST += \
+   src/shared/unit-property-scope.gperf
+
+CLEANFILES += \
+   src/shared/unit-property-scope.c
+
 libsystemd_shared_la_LIBADD = \
$(CAP_LIBS)
 
diff --git a/src/shared/.gitignore b/src/shared/.gitignore
index 61709e8..e7faa23 100644
--- a/src/shared/.gitignore
+++ b/src/shared/.gitignore
@@ -10,3 +10,4 @@
 /arphrd-from-name.h
 /arphrd-list.txt
 /arphrd-to-name.h
+/unit-property-scope.c
diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
index 21b6691..7cf0160 100644
--- a/src/shared/unit-name.c
+++ b/src/shared/unit-name.c
@@ -602,3 +602,25 @@ static const char* const 
unit_dependency_table[_UNIT_DEPENDENCY_MAX] = {
 };
 
 DEFINE_STRING_TABLE_LOOKUP(unit_dependency, UnitDependency);
+
+static UnitMask unit_get_mask_from_property(const char *property) {
+const unit_property_scope_mapping *m;
+
+assert(property);
+
+m = unit_property_scope_mapping_lookup(property, strlen(property));
+if (m)
+return m-scope;
+
+return _UNIT_MASK_MAX;
+
+}
+
+bool unit_can_have_property(UnitType t, const char *property) {
+UnitMask m;
+
+assert(property);
+
+m = unit_get_mask_from_property(property);
+return !!((1ULL  t)  m);
+}
diff --git a/src/shared/unit-name.h b/src/shared/unit-name.h
index 6f139cc..191c930 100644
--- a/src/shared/unit-name.h
+++ b/src/shared/unit-name.h
@@ -28,6 +28,7 @@
 #define UNIT_NAME_MAX 256
 
 typedef enum UnitType UnitType;
+typedef enum UnitMask UnitMask;
 typedef enum UnitLoadState UnitLoadState;
 typedef enum UnitDependency UnitDependency;
 
@@ -49,6 +50,23 @@ enum UnitType {
 _UNIT_TYPE_INVALID = -1
 };
 
+enum UnitMask {
+UNIT_MASK_SERVICE   = 1ULL  UNIT_SERVICE,
+UNIT_MASK_SOCKET= 1ULL  UNIT_SOCKET,
+UNIT_MASK_BUSNAME   = 1ULL  UNIT_BUSNAME,
+UNIT_MASK_TARGET= 1ULL  UNIT_TARGET,
+UNIT_MASK_SNAPSHOT  = 1ULL  UNIT_SNAPSHOT,
+UNIT_MASK_DEVICE= 1ULL  UNIT_DEVICE,
+UNIT_MASK_MOUNT = 1ULL  UNIT_MOUNT,
+UNIT_MASK_AUTOMOUNT = 1ULL  UNIT_AUTOMOUNT,
+UNIT_MASK_SWAP  = 1ULL  UNIT_SWAP,
+UNIT_MASK_TIMER = 1ULL  UNIT_TIMER,
+UNIT_MASK_PATH  = 1ULL  UNIT_PATH,
+UNIT_MASK_SLICE = 1ULL  UNIT_SLICE,
+UNIT_MASK_SCOPE = 1ULL  UNIT_SCOPE,
+_UNIT_MASK_MAX  = 1ULL _UNIT_TYPE_MAX,
+};
+
 enum UnitLoadState {
 UNIT_STUB = 0,
 UNIT_LOADED,
@@ -165,3 +183,11 @@ int build_subslice(const char *slice, const char*name, 
char **subslice);
 
 const char *unit_dependency_to_string(UnitDependency i) _const_;
 UnitDependency unit_dependency_from_string(const char *s) _pure_;
+
+struct unit_property_scope_mapping {
+const char* property;
+UnitMask scope;
+};
+typedef struct unit_property_scope_mapping unit_property_scope_mapping;
+const unit_property_scope_mapping* unit_property_scope_mapping_lookup 
(register const char *str, register unsigned int len);
+bool unit_can_have_property(UnitType t, const char *property);
diff --git a/src/shared/unit-property-scope.gperf 
b/src/shared/unit-property-scope.gperf
new file mode 100644
index 000..bbcfcba
--- /dev/null
+++ b/src/shared/unit-property-scope.gperf
@@ -0,0 +1,202 @@
+%{
+#include unit-name.h
+#include bus-util.h
+%}
+unit_property_scope_mapping;
+%null_strings
+%language=ANSI-C
+%define slot-name property
+%define hash-function-name bus_property_scope_mapping_hash
+%define lookup-function-name unit_property_scope_mapping_lookup
+%readonly-tables
+%omit-struct-type
+%struct-type
+%includes
+%%
+Description,
UNIT_MASK_SERVICE|UNIT_MASK_SOCKET|UNIT_MASK_DEVICE|UNIT_MASK_MOUNT|UNIT_MASK_AUTOMOUNT|UNIT_MASK_SWAP|UNIT_MASK_TARGET|UNIT_MASK_PATH|UNIT_MASK_TIMER|UNIT_MASK_SNAPSHOT|UNIT_MASK_SLICE|UNIT_MASK_SCOPE
+Documentation,

[systemd-devel] [PATCH v4] run: introduce timer support option

Supported timer options --on-active=, --on-boot=, --on-startup=,
--on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options
corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=,
OnUnitActiveSec=, OnUnitInactiveSec= of timer respectively.
---
 man/systemd-run.xml  |  42 +++
 src/libsystemd/sd-bus/bus-util.c |  14 +-
 src/run/run.c| 581 ---
 3 files changed, 538 insertions(+), 99 deletions(-)

diff --git a/man/systemd-run.xml b/man/systemd-run.xml
index 28a9878..abac26c 100644
--- a/man/systemd-run.xml
+++ b/man/systemd-run.xml
@@ -210,6 +210,37 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   xi:include href=user-system-options.xml xpointer=host /
   xi:include href=user-system-options.xml xpointer=machine /
 
+  varlistentry
+termoption--on-active=/option/term
+termoption--on-boot=/option/term
+termoption--on-startup=/option/term
+termoption--on-unit-active=/option/term
+termoption--on-unit-inactive=/option/term
+
+listitemparaDefines monotonic timers relative to different
+starting points. Also see varnameOnActiveSec=/varname,
+varnameOnBootSec=/varname,
+varnameOnStartupSec=/varname,
+varnameOnUnitActiveSec=/varname and
+varnameOnUnitInactiveSec=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+option has no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termoption--on-calendar=/option/term
+
+listitemparaDefines realtime (i.e. wallclock) timers with
+calendar event expressions. Also see
+varnameOnCalendar=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+option has no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
   xi:include href=standard-options.xml xpointer=help /
   xi:include href=standard-options.xml xpointer=version /
 /variablelist
@@ -250,6 +281,16 @@ Sep 08 07:37:21 bupkis env[19948]: 
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.
 property./para
 
 programlisting# systemd-run -p BlockIOWeight=10 updatedb/programlisting
+
+paraThe following command will touch a file after 10 seconds./para
+
+programlisting# date; systemd-run --on-active=10 touch /tmp/hello
+Mon Oct 27 20:02:57 KST 2014
+Running as unit run-66.timer.
+# journalctl -u run-115.service
+-- Logs begin at Mon 2014-10-27 19:44:57 KST, end at Mon 2014-10-27 20:03:15 
KST. --
+Oct 27 20:03:15 container systemd[1]: Starting /bin/touch /tmp/hello...
+Oct 27 20:03:15 container systemd[1]: Started /bin/touch 
/tmp/hello./programlisting
   /refsect1
 
   refsect1
@@ -263,6 +304,7 @@ Sep 08 07:37:21 bupkis env[19948]: 
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.
   
citerefentryrefentrytitlesystemd.slice/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd.exec/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd.resource-control/refentrytitlemanvolnum5/manvolnum/citerefentry,
+  
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlemachinectl/refentrytitlemanvolnum1/manvolnum/citerefentry
 /para
   /refsect1
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index bdaa449..0f1a89c 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -1372,7 +1372,8 @@ int bus_append_unit_property_assignment(sd_bus_message 
*m, const char *assignmen
 
 if (STR_IN_SET(field,
CPUAccounting, MemoryAccounting, 
BlockIOAccounting,
-   SendSIGHUP, SendSIGKILL)) {
+   SendSIGHUP, SendSIGKILL,
+   WakeSystem)) {
 
 r = parse_boolean(eq);
 if (r  0) {
@@ -1533,6 +1534,17 @@ int bus_append_unit_property_assignment(sd_bus_message 
*m, const char *assignmen
 
 r = sd_bus_message_append(m, v, i, sig);
 
+} else if (streq(field, AccuracySec)) {
+usec_t u;
+
+r = parse_sec(eq, u);
+if (r  0) {
+log_error(Failed to parse %s value %s, field, eq);
+return -EINVAL;
+}
+
+r = sd_bus_message_append(m, v, t, u);
+
 } else {
 log_error(Unknown assignment %s., assignment);
 return -EINVAL;
diff --git a/src/run/run.c b/src/run/run.c
index 85eb052..e1ef7b4 100644
--- a/src/run/run.c
+++ b/src/run/run.c
@@ -30,6 +30,7 @@
 #include env-util.h
 #include path-util.h
 #include bus-error.h
+#include calendarspec.h
 
 static

Re: [systemd-devel] reacting to unit failures (OnFailure)

On Tue, 02.12.14 08:00, Nekrasov, Alexander (alexander.nekra...@emc.com) wrote:

 Meaning that I have to create a myfailureunitname.service
 file/unit for every unit I want to register for? Which in my case is
 going to be almost all of them, in a high availability system

No. systemd has a concept of template units, that can be
instantiated a number of times. The unit names with @ in the name
are such templated units. The files on disk are name foo@.service, and
at runtime you can then instantiate them as foo@bar.service,
foo@waldo.service and so on. The foo in this scheme is the template
name, while bar/waldo/... is the instance id. In my proposal below I
suggested using one template and then instantiate them once for each
failed unit, using the faile unit's name as the instance id.

  -Original Message-
  From: Lennart Poettering [mailto:lenn...@poettering.net]
  Sent: Monday, December 01, 2014 5:46 PM
  To: Nekrasov, Alexander
  Cc: systemd-devel@lists.freedesktop.org
  Subject: Re: [systemd-devel] reacting to unit failures (OnFailure)
  
  On Mon, 01.12.14 17:10, Nekrasov, Alexander (alexander.nekra...@emc.com)
  wrote:
  
   Hello,
  
   While converting from Upstart to SystemD, came upon this issue. Is
  this case not covered or am I missing something?
  
   In Upstart, I can start a job when another job fails, and there's a
  $JOB variable that tells me what was the job that failed.
  
   start on (stopped RESULT=failed PROCESS=post-stop)
  
   script
   echo this just failed: $JOB
   end script
  
   In SystemD I can register a unit to be started when another unit
   fails. But there seems to be no way of knowing what unit failed. Is
   that correct?
  
  The idea is that you use OnFailure=myfailureunit@%n.service. %n is
  automatically replaced by the name of the unit you place this
  in. Then, in the failure unit you can identify the instance again with
  %i or %I.
  
  Lennart
  
  --
  Lennart Poettering, Red Hat
 


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] 8 commits - src/libsystemd src/network src/shared src/systemd

On Tue, 02.12.14 14:02, Tom Gundersen (t...@jklm.no) wrote:

  That's why we have to query the hwdb
  directly, instead of a udev-device. We might wanna add a
  udev_hwdb_get_property_value() just like the udev-device equivalent,
  though.
 
 Yeah, makes sense I guess.

Yeah, I agree.

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] 8 commits - src/libsystemd src/network src/shared src/systemd

On Tue, 02.12.14 13:42, David Herrmann (dh.herrm...@gmail.com) wrote:

 Hi
 
 On Tue, Dec 2, 2014 at 1:18 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 02.12.14 01:50, Tom Gundersen (tome...@kemper.freedesktop.org) 
  wrote:
  +udev_list_entry_foreach(entry, 
  udev_hwdb_get_properties_list_entry(hwdb, str, 0))
  +if (strcmp(udev_list_entry_get_name(entry), 
  ID_OUI_FROM_DATABASE) == 0) {
  +description = 
  strdup(udev_list_entry_get_value(entry));
  +if (!description)
  +return -ENOMEM;
  +
  +*ret = description;
  +return 0;
  +}
 
  Hmm, why not just call udev_device_get_property_value()?
 
 That would require a udev_device, but we just have the RTNL
 information at this point. That's why we have to query the hwdb
 directly, instead of a udev-device. We might wanna add a
 udev_hwdb_get_property_value() just like the udev-device equivalent,
 though.

Ah, sorry, I wasn't really awake when I read the code, didn't realize
this was reading directly from hwdb, not from a udev db. 

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] localed: forward xkbcommon errors

On Tue, 02.12.14 14:02, Jan Synacek (jsyna...@redhat.com) wrote:

 The errors are prefixed with libxkbcommon, because they are quite
 confusing. With the prefix, we at least know where they come from.
 ---
  src/locale/localed.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)
 
 diff --git a/src/locale/localed.c b/src/locale/localed.c
 index 4e56382..ea54798 100644
 --- a/src/locale/localed.c
 +++ b/src/locale/localed.c
 @@ -1011,10 +1011,16 @@ static int method_set_vc_keyboard(sd_bus *bus, 
 sd_bus_message *m, void *userdata
  
  #ifdef HAVE_XKBCOMMON
  static void log_xkb(struct xkb_context *ctx, enum xkb_log_level lvl, const 
 char *format, va_list args) {
 -/* suppress xkb messages for now */
 +_cleanup_free_ char *fmt = NULL;
 +sd_bus_error *e;
 +
 +if (asprintf(fmt, libxkbcommon: %s, format)  0)
 +(void) log_oom();
 +e = xkb_context_get_user_data(ctx);
 +bus_error_setfv(e, SD_BUS_ERROR_INVALID_ARGS, fmt, args);

I thought the plan now was to log them at debug level but not return
them to the client?

Also, strappenda()!

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] DISTRO_PORTING: Full path for /usr/lib/systemd/systemd

2014-12-02 Thread David Herrmann

Hi

On Tue, Dec 2, 2014 at 4:05 PM, Chris Atkinson c...@pipeline.com wrote:
 The systemd binary was moved from /usr/bin/systemd
 to /usr/lib/systemd/systemd (commit
 e0d25329b23a43332ea340f9907721873a316f4e) and is thus no longer in
 $PATH. This adds the absolute path /usr/lib/systemd/systemd to
 DISTRO_PORTING and does grammar/punctuation cleanup.

Your patch adds trailing white-space. Please make sure to not add them
next time, I dropped them now.

Patch applied, thanks!
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] reacting to unit failures (OnFailure)

2014-12-02 Thread Jóhann B. Guðmundsson



On 12/02/2014 03:12 PM, Nekrasov, Alexander wrote:

Lennart just gave me a solution, thank you. I'll use templates

I have a system where components at the single node level have dependencies and HA 
policies, such as restart this many times within this interval, if still fails - run this 
action where action is a sequence of commands. Components provide this information in their 
own language and I have to generate systemd configuration for them. It's more complex than just 
rebooting the node so I couldn't use FailureAction.


Right but you already have
Restart=on-failure
RestartSec=...

and the likes to restart the services in graceful HA manner ( and at the 
sametime allowing it to fail gracefully ) so what I was curious about 
what else you are doing in the background since it might lead to a worse 
situation in HA setup by doing so depending on the HA setup ( split 
brains etc you know the drill ).


JBG
___
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

On Tue, 02.12.14 10:24, Łukasz Stelmach (l.stelm...@samsung.com) wrote:

  Will it be necessary for this directory to be owned by systemd-network
  even without networkd?
 
  Yes. If networkd is compile-time enable the dir should exist and be
  properly owned, even if it networkd is split off into a separate
  binary package and currently not installed.
 
 And what if the networkd is disabled? Does the directory must exist? Now
 if networkd is disabled /run/systemd/netif* are not in
 tmpfiles.d/systemd.conf. Is this correct?

If networkd is compile-time disabled then the directory should go away
too.

If networkd is compile-time enabled but its split-off binary package
not installed then the directory should exist however, since the user
might install the package later at which time clients using
sd-network should magically start to work. But that they can only if
the dir already exists which they can place their inotify watch in.

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] build-sys: remove --gc-sections to fix debugging

2014-12-02 Thread Peter Wu

On Monday 01 December 2014 01:06:12 Lennart Poettering wrote:
 On Mon, 24.11.14 20:00, Peter Wu (pe...@lekensteyn.nl) wrote:
 
  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.
 
 To my knowledge libunwind is mostly obsolete, and libelfutils should
 be used instead.

The Fedora maintainer dropped libunwind support, but there is still
upstream activity. Documentation of libunwind is superior to
libelfutils. Even by looking in the headers, I could not find a way to
get a backtrace in libelfutils.

libunwind backtracing functionality is signal and thread-safe while
libelfutils does not have a strong focus on that as far as I can see.

See also the discussion on this X patch where libelfutils was ultimately
dropped in favor if libunwind. https://freedesktop.org/patch/15054/

  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
 
 Are you sure you built the non-debug build?

Just ./autogen.sh  ./configure, nothing fancy. The default options
include '-g', but for some reason the linking drops this option and
there are no debugging symbols.

 The reason we use gc-sections logic is that much of what we hae in
 src/shared/ is linked into every single binary we have even though
 most binaries need only very little of it. We rely on the linker to
 remove all the bits that are unnecessary hence.

It turns out that my compiler (GCC 4.9.2) behaved worse with
--gc-sections because LTO already optimized the unused parts away.
-- 
Kind regards,
Peter
https://lekensteyn.nl

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

[systemd-devel] preset enables everything by default

2014-12-02 Thread Michael Marineau

I didn't catch this behavior when it was first introduced since
originally it was much harder to trigger systemd's empty /etc logic
but now that it only requires /etc/machine-id to be missing it is
quite easy, booting a new instance from an image for example. By
default applying presets enables everything unless there is a preset
config that defines otherwise. I found this to be rather surprising,
booting a fresh machine reported all sorts of failures by trying to
start oodles of unconfigured services. Also the options are only
enable and disable so the existing pattern of pre-preconfiguring a
reference host and then creating an image (EC2 AMIs for example) won't
work very well since the preset defaults will clobber what the user
enabled/disabled. (assuming the user properly clears machine-id before
creating the image which may be rare, in all likelihood many people
just get away with having non-unique machine ids)

This behavior is probably ok in the case of interactively using
systemctl preset and preset-all when it is known that the user
explicitly asked the system to do something and can see what it did.
In the case of the system booting I would expect do nothing to be
the default when no preset file explicitly sates otherwise.

Is there a particular reason for the existing behavior? Would
switching the default to disable be reasonable or should the automatic
at boot mode gain a third do nothing option? Not sure where the
safest and least-surprising behavior lies while continuing to provide
this preset functionality.

Personally I've always found the enable/disable terminology to be
incredibly misleading to begin with since it only refers to
configuration in /etc and units can be equally activated in /usr. If
disable and mask were equivalent then the distro's presets would
just be whatever is in /usr and there won't be a need for this extra
preset mechanism to initialize /etc.

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

[systemd-devel] [PATCH rebased 2/3] cryptsetup-generator: Add support for UUID-specific key files on kernel command line

2014-12-02 Thread Jan Janssen

---
 man/systemd-cryptsetup-generator.xml  | 11 ---
 src/cryptsetup/cryptsetup-generator.c | 17 ++---
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/man/systemd-cryptsetup-generator.xml 
b/man/systemd-cryptsetup-generator.xml
index ff94e88..d4a9cc7 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -165,11 +165,16 @@
 termvarnameluks.key=/varname/term
 termvarnamerd.luks.key=/varname/term
 
-listitemparaTakes a password file as 
argument./para
+listitemparaTakes a password file name as 
argument or
+a LUKS super block UUID followed by a '=' and 
a password
+file name./para
+
 paraFor those entries specified with
 varnamerd.luks.uuid=/varname or 
varnameluks.uuid=/varname,
-the password file will be set to the password 
file specified by
-varnamerd.luks.key=/varname or 
varnameluks.key/varname/para
+the password file will be set to the one 
specified by
+varnamerd.luks.key=/varname or 
varnameluks.key=/varname
+of the corresponding UUID, or the password 
file that was specified
+without a UUID./para
 paravarnamerd.luks.key=/varname
 is honored only by initial RAM disk
 (initrd) while
diff --git a/src/cryptsetup/cryptsetup-generator.c 
b/src/cryptsetup/cryptsetup-generator.c
index c1581ef..efbcb3a 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -36,6 +36,7 @@
 
 typedef struct crypto_device {
 char *uuid;
+char *keyfile;
 char *options;
 bool create;
 } crypto_device;
@@ -264,6 +265,7 @@ static void free_arg_disks(void) {
 
 while ((d = hashmap_steal_first(arg_disks))) {
 free(d-uuid);
+free(d-keyfile);
 free(d-options);
 free(d);
 }
@@ -284,7 +286,7 @@ static crypto_device *get_crypto_device(const char *uuid) {
 return NULL;
 
 d-create = false;
-d-options = NULL;
+d-keyfile = d-options = NULL;
 
 d-uuid = strdup(uuid);
 if (!d-uuid) {
@@ -348,7 +350,16 @@ static int parse_proc_cmdline_item(const char *key, const 
char *value) {
 
 } else if (STR_IN_SET(key, luks.key, rd.luks.key)  value) {
 
-if (free_and_strdup(arg_default_keyfile, value))
+r = sscanf(value, %m[0-9a-fA-F-]=%ms, uuid, uuid_value);
+if (r == 2) {
+d = get_crypto_device(uuid);
+if (!d)
+return log_oom();
+
+free(d-keyfile);
+d-keyfile = uuid_value;
+uuid_value = NULL;
+} else if (free_and_strdup(arg_default_keyfile, value))
 return log_oom();
 
 }
@@ -455,7 +466,7 @@ static int add_proc_cmdline_devices(void) {
 else
 options = timeout=0;
 
-r = create_disk(name, device, arg_default_keyfile, options);
+r = create_disk(name, device, d-keyfile ?: 
arg_default_keyfile, options);
 if (r  0)
 return r;
 }
-- 
2.1.3

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

[systemd-devel] [PATCH rebased 1/3] cryptsetup-generator: Split main() into more functions and use hasmaps

2014-12-02 Thread Jan Janssen

---
 man/systemd-cryptsetup-generator.xml  |   9 +-
 src/cryptsetup/cryptsetup-generator.c | 380 +-
 2 files changed, 199 insertions(+), 190 deletions(-)

diff --git a/man/systemd-cryptsetup-generator.xml 
b/man/systemd-cryptsetup-generator.xml
index 3abb39d..ff94e88 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -120,7 +120,7 @@
 activate the specified device as part
 of the boot process as if it was
 listed in
-filename/etc/fstab/filename. This
+filename/etc/crypttab/filename. This
 option may be specified more than once
 in order to set up multiple
 devices. varnamerd.luks.uuid=/varname
@@ -130,9 +130,10 @@
 honored by both the main system and
 the initrd./para
 paraIf /etc/crypttab contains entries with
-the same UUID, then the options for this entry
-will be used./para
-paraIf /etc/crypttab exists, only those UUID
+the same UUID, then the name, keyfile and 
options
+specified there will be used. Otherwise the 
device
+will have the name 
literalluks-UUID/literal./para
+paraIf /etc/crypttab exists, only those UUIDs
 specified on the kernel command line
 will be activated in the initrd or the real 
root./para
 /listitem
diff --git a/src/cryptsetup/cryptsetup-generator.c 
b/src/cryptsetup/cryptsetup-generator.c
index 45c23bb..c1581ef 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -19,26 +19,34 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
-#include string.h
 #include errno.h
+#include string.h
 #include unistd.h
 
+#include dropin.h
+#include fileio.h
+#include generator.h
+#include hashmap.h
 #include log.h
-#include util.h
-#include unit-name.h
 #include mkdir.h
-#include strv.h
-#include fileio.h
 #include path-util.h
-#include dropin.h
-#include generator.h
+#include strv.h
+#include unit-name.h
+#include util.h
+
+typedef struct crypto_device {
+char *uuid;
+char *options;
+bool create;
+} crypto_device;
 
 static const char *arg_dest = /tmp;
 static bool arg_enabled = true;
 static bool arg_read_crypttab = true;
-static char **arg_disks = NULL;
-static char **arg_options = NULL;
-static char *arg_keyfile = NULL;
+static bool arg_whitelist = false;
+static Hashmap *arg_disks = NULL;
+static char *arg_default_options = NULL;
+static char *arg_default_keyfile = NULL;
 
 static bool has_option(const char *haystack, const char *needle) {
 const char *f = haystack;
@@ -251,8 +259,54 @@ static int create_disk(
 return 0;
 }
 
+static void free_arg_disks(void) {
+crypto_device *d;
+
+while ((d = hashmap_steal_first(arg_disks))) {
+free(d-uuid);
+free(d-options);
+free(d);
+}
+
+hashmap_free(arg_disks);
+}
+
+static crypto_device *get_crypto_device(const char *uuid) {
+int r;
+crypto_device *d;
+
+assert(uuid);
+
+d = hashmap_get(arg_disks, uuid);
+if (!d) {
+d = new0(struct crypto_device, 1);
+if (!d)
+return NULL;
+
+d-create = false;
+d-options = NULL;
+
+d-uuid = strdup(uuid);
+if (!d-uuid) {
+free(d);
+return NULL;
+}
+
+r = hashmap_put(arg_disks, d-uuid, d);
+if (r  0) {
+free(d-uuid);
+free(d);
+return NULL;
+}
+}
+
+return d;
+}
+
 static int parse_proc_cmdline_item(const char *key, const char *value) {
 int r;
+crypto_device *d;
+_cleanup_free_ char *uuid = NULL, *uuid_value = NULL;
 
 if (STR_IN_SET(key, luks, rd.luks)  value) {
 
@@ -272,19 +326,29 @@ static int parse_proc_cmdline_item(const char *key, const 
char *value) {
 
 } else if (STR_IN_SET(key, luks.uuid, rd.luks.uuid)  value) {
 
-if (strv_extend(arg_disks, value)  0)
+d = get_crypto_device(startswith(value, luks-) ? value+5 : 
value);
+if (!d)
 return log_oom();
 
+d-create = arg_whitelist = true;
+
 } else if

[systemd-devel] [PATCH rebased 3/3] cryptsetup-generator: Add support for naming luks devices on kernel cmdline

2014-12-02 Thread Jan Janssen

---
 man/kernel-command-line.xml   |  2 ++
 man/systemd-cryptsetup-generator.xml  | 19 +++
 src/cryptsetup/cryptsetup-generator.c | 32 ++--
 3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index 68460ac..e32ed19 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -283,6 +283,8 @@
 termvarnamerd.luks=/varname/term
 termvarnameluks.crypttab=/varname/term
 
termvarnamerd.luks.crypttab=/varname/term
+termvarnameluks.name=/varname/term
+termvarnamerd.luks.name=/varname/term
 termvarnameluks.uuid=/varname/term
 termvarnamerd.luks.uuid=/varname/term
 termvarnameluks.options=/varname/term
diff --git a/man/systemd-cryptsetup-generator.xml 
b/man/systemd-cryptsetup-generator.xml
index d4a9cc7..c8753ce 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -140,6 +140,25 @@
 /varlistentry
 
 varlistentry
+termvarnameluks.name=/varname/term
+termvarnamerd.luks.name=/varname/term
+
+listitemparaTakes a LUKS super
+block UUID followed by an '=' and a name. This 
implies
+varnamerd.luks.uuid=/varname or 
varnameluks.uuid=/varname
+and will additionally make the LUKS device 
given by
+the UUID appear under the provided name./para
+
+paravarnamerd.luks.name=/varname
+is honored only by initial RAM disk
+(initrd) while
+varnameluks.name=/varname is
+honored by both the main system and
+the initrd./para
+/listitem
+/varlistentry
+
+varlistentry
 termvarnameluks.options=/varname/term
 
termvarnamerd.luks.options=/varname/term
 
diff --git a/src/cryptsetup/cryptsetup-generator.c 
b/src/cryptsetup/cryptsetup-generator.c
index efbcb3a..3a866f3 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -37,6 +37,7 @@
 typedef struct crypto_device {
 char *uuid;
 char *keyfile;
+char *name;
 char *options;
 bool create;
 } crypto_device;
@@ -266,6 +267,7 @@ static void free_arg_disks(void) {
 while ((d = hashmap_steal_first(arg_disks))) {
 free(d-uuid);
 free(d-keyfile);
+free(d-name);
 free(d-options);
 free(d);
 }
@@ -286,7 +288,7 @@ static crypto_device *get_crypto_device(const char *uuid) {
 return NULL;
 
 d-create = false;
-d-keyfile = d-options = NULL;
+d-keyfile = d-options = d-name = NULL;
 
 d-uuid = strdup(uuid);
 if (!d-uuid) {
@@ -362,6 +364,22 @@ static int parse_proc_cmdline_item(const char *key, const 
char *value) {
 } else if (free_and_strdup(arg_default_keyfile, value))
 return log_oom();
 
+} else if (STR_IN_SET(key, luks.name, rd.luks.name)  value) {
+
+r = sscanf(value, %m[0-9a-fA-F-]=%ms, uuid, uuid_value);
+if (r == 2) {
+d = get_crypto_device(uuid);
+if (!d)
+return log_oom();
+
+d-create = arg_whitelist = true;
+
+free(d-name);
+d-name = uuid_value;
+uuid_value = NULL;
+} else
+log_warning(Failed to parse luks name switch %s. 
Ignoring., value);
+
 }
 
 return 0;
@@ -446,14 +464,16 @@ static int add_proc_cmdline_devices(void) {
 
 HASHMAP_FOREACH(d, arg_disks, i) {
 const char *options;
-_cleanup_free_ char *name = NULL, *device = NULL;
+_cleanup_free_ char *device = NULL;
 
 if (!d-create)
 continue;
 
-name = strappend(luks-, d-uuid);
-if (!name)
-return log_oom();
+if (!d-name) {
+d-name = strappend(luks-, d-uuid);
+if (!d-name)
+return

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

2014-12-02 Thread Uoti Urpala

On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
 On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
 
  2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
   For the avoidance of doubt, I believe that running systemctl preset
   should only ever happen on *first* install, never on upgrade or such like.
  
  
  And what are you going to do, if the unit file changes?
  Say v1  had
  
  [Install]
  WantedBy=multi-user.target
  
  and version B has
  [Install]
  WantedBy=foo.target
 
 Package installs should probably not try to do something about this
 case, just leave things as is.

I think this would be a very bad idea. Installing a system and then
upgrading it should give you the same state as installing a newer system
directly; silently leaving outdated configuration in use almost ensures
that systems will fail/degrade over time.

 I mean, let's not forget that admins should be able to define their
 own targets and then enabled units in them and disable them
 elsewhere. Package upgrades should not manipulate that. The first
 installation of a package should enable a unit if that's what the
 preset policy says, but from that point on the configuration is admin
 configuration and not be changed anymore automatically.

It's theoretically possible that the admin could have moved it to a
different target, but that's the exception. The system should still
sanely handle the normal case where the admin has changed nothing, and
in that case leaving the unit in its original target is completely
wrong.

For example, if you move a unit from sysinit.target to multi-user.target
and remove DefaultDependencies=no from the .service file, then leaving
the installed symlink for sysinit.target will cause a dependency loop.
Even in cases where the resulting configuration is not so obviously
broken, differences from the behavior of new installs are always
harmful.

If the admin HAS changed the configuration, then silently ignoring
package changes is still not good behavior: it's likely that the admin
should at least check whether the local changes are still required/valid
and fix the setup to match the new package behavior if needed.

So overall, I think the rules for package upgrades should be:
In the default no-local-changes case, package upgrades MUST change
symlinks to match what a new package install would set.
If local configuration changes can be detected, then the admin should be
alerted to the need to check the configuration if possible.


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

Re: [systemd-devel] set rr scheduler failed with cpushares

On Mon, 17.11.14 23:46, WaLyong Cho (walyong@samsung.com) wrote:

 Hello,
 
 I'd made two different services. One has *CPUSchedulingPolicy=rr* and
 the others has *CPUShares=*.
 
 Could anyone help me?

If CPUShares= is set this has the effect that the service and all
services in the same slice will be have the cpu cgroup controller
turned on. Unfortunately this has the effect that RT scheduling will
be unavailable then, unless an explicit RT budget is configured for
that specific cgroup. This is something systemd cannot be used for
nicely however, as we don't expose high-level controls for the RT
budget. 

The RT budget is configured in the cpu.rt_runtime_us and
cpu.rt_period_us cgroup attributes. You can write to them from
ExecStartPre= for example using the %c specified.

Another option is to simply disable CONFIG_RT_GROUP_SCHED in the
kernel, if you don't need it anyway.

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 v8] tmpfiles, man: Add xattr support to tmpfiles

On Thu, 13.11.14 09:11, Maciej Wereski (m.were...@partner.samsung.com) wrote:

Sorry for the late review.

 +static int get_xattrs_from_arg(Item *i) {
 +char *xattr;
 +const char *p;
 +int n;
 +
 +assert(i);
 +if (i-type != SET_XATTR)
 +return 0;
 +
 +if (!i-argument) {
 +log_error(%s: Argument can't be empty!, i-path);
 +return -EBADMSG;
 +}
 +p = i-argument;
 +
 +while ((n = unquote_first_word(p, xattr, false))  0) {
 +if (strv_consume(i-xattrs, xattr)  0)
 +return log_oom();
 +}
 +
 +return n;

I think we really should parse the xattrs into key and value at the
time of parsing, not at the time of applying things. If something
parses incorrectly this should be noted before we do actually do
anything.

i think you can even stick to an strv for this, and simply store key
and value alternating in the list. We have STRV_FOREACH_PAIR in place
to iterate through such a list of pairs.

 -r = hashmap_put(h, i-path, i);
 -if (r  0) {
 -log_error(Failed to insert item %s: %s, i-path, 
 strerror(-r));
 -return r;
 +if (i-type == SET_XATTR) {
 +char **tmp;
 +r = get_xattrs_from_arg(i);
 +if (r  0)
 +return r;
 +tmp = existing-xattrs;
 +r = strv_extend_strv(existing-xattrs, i-xattrs);
 +if (r  0) {
 +strv_free(tmp);
 +return log_oom();
 +}

strv_extend_strv() actually realloc()s the existing array, you are
*not* supposed to free the old version! 

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] Automatic journal check?

On Thu, 13.11.14 22:22, Nikolaus Rath (nikol...@rath.org) wrote:

Hello,

My journal gets corrupted on pretty much a daily basis. I typically
notice this because things like systemctl -n 3 take ages to run. When
I then run journalctl --verify, I get output like this:

Corrupted journals do not have the effect of slowing things down
really. Badly fragmented journals (as they are common on btrfs, due to
btrfs' limitations) do.

Running journactl --verify on a set of journal files that are online
is like running a fsck on a file system you are writing to, and will
of course mean you will run into issues.

Invalid data object at hash entry 3944 of 233016░░░ 49%
File corruption detected at
/var/log/journal/b865c77cc176b5ef3b69390a000d/user-1000@0005065350521a47-17e420d2d51ab126.journal~:00
(of 8388608 bytes, 0%).
Data object references invalid entry at 5182040███░ 75%
File corruption detected at
/var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050713408c0d34-e40e6aa5c35eb139.journal~:00
(of 8388608 bytes, 0%).
FAIL:
/var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050713408c0d34-e40e6aa5c35eb139.journal~
(Bad message)
Data number mismatch██░ 39%
File corruption detected at
/var/log/journal/b865c77cc176b5ef3b69390a000d/system@000507165d32850c-5b4cd09ceb6b2ea6.journal~:00
(of 16777216 bytes, 0%).
Invalid tail monotonic timestamp░░░ 48%
File corruption detected at
/var/log/journal/b865c77cc176b5ef3b69390a000d/user-65534@763da377eefc4369ad61af34c4a5a1c6-000263f0-000504a444037da7.journal:00
(of 8388608 bytes, 0%).

This corruption is probably caused by me hard-rebooting the computer
recently to debug some other issues.

Yes, if you hard reset your system journal files might stay
half-written. However, on the next startup journald will notice that,
and move the journal files away. This worked correctly in your case as
you can see by the ~ suffix the files acquired.

However, I think it's quite unfortunate that journald isn't able to
recover from this on its own.

It is. journalctl --verify is a very strict. It will show you every
single issue with the file, if it has half-written entries. And journald
rotates the files if it detects that it has half-written
entries. Also, journalctl when reading will actually handle
half-written entries gracefully, and simply show as many entries as it
can, only leaving out the incompletely written ones.

Is there a reason why the journal doesn't have a clean flag like
regular file systems? This would allow an automatic --verify run when
the journal has not been closed properly, and would save people like me
the trouble of monitoring this manually.

There's really no need to ever invoke --verify except to verify
sealing, and even then you only want to invoke it offline.

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] daemon-reload timestamped: coalesce redundant daemon-reloads

2014-12-02 Thread Ken Sedgwick

Systems with many units (~10K) take many seconds to perform a
daemon-reload.  The process of load-balancing these systems requires
multiple daemon-reloads, many issued concurrently.  Currently many of
these redundant daemon-reloads timeout and fail.

This patch adds a new systemd method ReloadTimestamped which contains
the monotonic timestamp of the daemon-reload issuance.  When a
ReloadTimestamped message is handled it's timestamp is compared to
the timestamp of the most recent successful daemon reload.  If the
message is redundant it is returns with success immediately.

The original Reload method is preserved to support compatibility with
older systemctl versions.

If a new systemctl receives a SD_BUS_ERROR_UNKNOWN_METHOD error in
response to ReloadTimestamped it retries with the original Reload
method.
---
 src/core/dbus-manager.c   | 47 +++
 src/core/manager.c|  8 
 src/core/manager.h|  3 +++
 src/systemctl/systemctl.c | 19 ++-
 4 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 0994d7b..6a42456 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1100,6 +1100,52 @@ static int method_reload(sd_bus *bus, sd_bus_message 
*message, void *userdata, s
 return 1;
 }
 
+static int method_reload_timestamped(sd_bus *bus, sd_bus_message *message, 
void *userdata, sd_bus_error *error) {
+Manager *m = userdata;
+int r;
+usec_t requested_time;
+
+assert(bus);
+assert(message);
+assert(m);
+
+r = bus_verify_reload_daemon_async(m, message, error);
+if (r  0)
+return r;
+if (r == 0)
+return 1; /* No authorization for now, but the async polkit 
stuff will call us again when it has it */
+
+r = mac_selinux_access_check(message, reload, error);
+if (r  0)
+return r;
+
+r = sd_bus_message_read(message, t, requested_time);
+if (r  0)
+return r;
+
+/* Is this reload needed?  If a completed reload was started
+ * after this reload was requested we can coalesce it and
+ * return immediate success. */
+
+if (requested_time  m-last_reload_time)
+return sd_bus_reply_method_return(message, NULL);
+
+/* Instead of sending the reply back right away, we just
+ * remember that we need to and then send it after the reload
+ * is finished. That way the caller knows when the reload
+ * finished. */
+
+assert(!m-queued_message);
+r = sd_bus_message_new_method_return(message, m-queued_message);
+if (r  0)
+return r;
+
+m-queued_message_bus = sd_bus_ref(bus);
+m-exit_code = MANAGER_RELOAD;
+
+return 1;
+}
+
 static int method_reexecute(sd_bus *bus, sd_bus_message *message, void 
*userdata, sd_bus_error *error) {
 Manager *m = userdata;
 int r;
@@ -1917,6 +1963,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
 SD_BUS_METHOD(CreateSnapshot, sb, o, method_create_snapshot, 0),
 SD_BUS_METHOD(RemoveSnapshot, s, NULL, method_remove_snapshot, 0),
 SD_BUS_METHOD(Reload, NULL, NULL, method_reload, 
SD_BUS_VTABLE_UNPRIVILEGED),
+SD_BUS_METHOD(ReloadTimestamped, t, NULL, 
method_reload_timestamped, SD_BUS_VTABLE_UNPRIVILEGED),
 SD_BUS_METHOD(Reexecute, NULL, NULL, method_reexecute, 
SD_BUS_VTABLE_UNPRIVILEGED),
 SD_BUS_METHOD(Exit, NULL, NULL, method_exit, 0),
 SD_BUS_METHOD(Reboot, NULL, NULL, method_reboot, 
SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)),
diff --git a/src/core/manager.c b/src/core/manager.c
index cff24fa..4619ce3 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -616,6 +616,8 @@ int manager_new(SystemdRunningAs running_as, bool test_run, 
Manager **_m) {
 
 m-taint_usr = dir_is_empty(/usr)  0;
 
+m-last_reload_time = 0ULL;
+
 *_m = m;
 return 0;
 
@@ -2444,9 +2446,12 @@ int manager_reload(Manager *m) {
 int r, q;
 _cleanup_fclose_ FILE *f = NULL;
 _cleanup_fdset_free_ FDSet *fds = NULL;
+usec_t this_reload_time;
 
 assert(m);
 
+this_reload_time = now(CLOCK_MONOTONIC);
+
 r = manager_open_serialization(m, f);
 if (r  0)
 return r;
@@ -2518,6 +2523,9 @@ int manager_reload(Manager *m) {
 
 m-send_reloading_done = true;
 
+if (r = 0)
+m-last_reload_time = this_reload_time;
+
 return r;
 }
 
diff --git a/src/core/manager.h b/src/core/manager.h
index ab75f90..7790127 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -295,6 +295,9 @@ struct Manager {
 
 /* Used for processing polkit authorization responses */
 Hashmap *polkit_registry;
+
+/* Used to coalesce redundant reloads */
+usec_t

[systemd-devel] (no subject)

2014-12-02 Thread Andrey Shinkevich


Hello,
 
My name is Andrey. I would like to activate a service by socket or D-Bus and  
stop it when unneeded. The activation works fine but I failed to find a way how 
the service can be stopped/deactivated automatically when it is no longer 
needed by using applications.
Would you please help me with information on that subject? I will appreciate.
 
Kind regards,  
Andrey Shinkevich___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] (no subject)

On Tue, 02.12.14 23:50, Andrey Shinkevich (andys...@mail.ru) wrote:

Heya,

 My name is Andrey. I would like to activate a service by socket or
 D-Bus and stop it when unneeded. The activation works fine but I
 failed to find a way how the service can be stopped/deactivated
 automatically when it is no longer needed by using applications.

Services need to determine internally when they are idle and then
exit. We cannot determine from the outside if a daemon is idle, and
hence we cannot decide when the right time would be to shut down a
service.

There might be a variety of reasons why a daemon is busy: it might be
client connections, and all kinds of background work, but systemd from
the outside cannot really know much about that.

Please contact the authors of the daemons you are interested in, and
ask them to consider implementing an exit-on-idle logic.

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] Cannot use systemctl after heavy swapping

On Fri, 14.11.14 15:20, Jan Janssen (medhe...@web.de) wrote:

 Hi,
 
 I think there might be something wrong with how the rate limiting works in
 manager.c. Just recently, firefox went nuts and got the whole system
 swapping like crazy. After manual OOM killing, the system is back to normal,
 but I can't seem to do any service management with systemctl afterwards.
 
 A simple sudo systemctl start systemd-timedated.service will hang forever.
 While the journal keeps getting this message about every second:
 systemd[1]: Looping too fast. Throttling execution a little.
 while other systemctl actions tend to time out (status, for example).
 
 Interestingly, if I don't use sudo (and instead rely on polkit), everything
 seems to work as expected and I can get things started.
 
 This is all on systemd 217 on up-to-date Arch.

Hmm, the looping too fast msg is usually triggerd by systemd for
some reason entering a busy loop. Which is bug we really should track
down and fix. Any chance you can use strace -p 1 when this happens
to see what PID 1 is spinning on there? If in doubt please attach a
fragment here.

Thanks,

Lennart

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

Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?

On Thu, 13.11.14 11:24, grantksupp...@operamail.com 
(grantksupp...@operamail.com) wrote:

 On Tue, Nov 11, 2014, at 08:09 AM, Lennart Poettering wrote:
  On the upstream ML we usually discuss only more recent problems, which
  are exposed upstream. Hence, please contact the Suse folks for more
  help on the issue, or check if a current systemd version fails.
 
 Already done, and just fyi -- appears now to be fixed:
 
 @ https://bugzilla.suse.com/show_bug.cgi?id=903560#c48
 
 rpm -q --changelog systemd
   * Thu Nov 13 2014 wer...@suse.de
   - Change patch 0001-add-hdflush-for-reboot-or-hddown-for-poweroff.patch
 to skip hdflush as well as hddown but only use halt as fallback
 for poweroff as well as synch in systemctl before any reboot command
 (compare with commit 4a3ad39957399c4a30fc472a804e72907ecaa4f9)
 
 https://build.opensuse.org/package/view_file/Base:System/systemd/0001-add-hdflush-for-reboot-or-hddown-for-poweroff.patch?expand=1
 
 shutdown now shuts down correctly.

I cannot make any sense out of that commit I must say. I really wish
suse would discuss this with us upstream, if there's a bug to fix
upstream...

Lennart

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

Re: [systemd-devel] xinetd REMOTE_IP (feature request)

On Thu, 13.11.14 13:53, Fisher, Charles J. (Top Echelon) 
(charles.fis...@alcoa.com) wrote:

 The xinetd server from previous versions of RedHat defined a REMOTE_IP 
 environment variable.
 
 I realize that I can extract that data with the following code:
 
 {
 struct sockaddr_in thisconn;
 int thislen = sizeof(thisconn);
 getpeername( /* STDIN */ 0, thisconn, thislen);
 printf(%s\n, inet_ntoa(thisconn.sin_addr));
 }
 
 ...but it would be nice if the behavior matched xinetd.

Makes sense to set this for per-connection socket activated
services. Added to TODO list. Any other renv vars xinetd was setting?

I wonder though whether it wouldn't be nicer to follow the variable
naming used by CGI here, and introduce $REMOTE_ADDR and $REMOTE_PORT
instead of $REMOTE_IP.

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] job_type_lookup_merge assertion failure in systemd

On Wed, 12.11.14 09:57, Steven Noonan (ste...@uplinklabs.net) wrote:

 Hi all,
 
 I've been seeing this happen every now and then on a couple machines.
 When I wake up in the morning and go to log in, I find X11 stopped,
 and when I try to log in to the VT it hangs when trying to create a
 session. I am forced to reset the box and then dig through logs on the
 next boot. This is the cause:

We fixed a couple of bugs recently in the code involving job
handling. Any chance you can check if you can reproduce the issue with
current git of systemd?

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] Shutdown problems

On Mon, 24.11.14 12:31, Nikolaus Rath (nikol...@rath.org) wrote:

Sorry for the late reply, still have a huge backlog of mail which I am
trying to process right now.

  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.

Hmm, this is weird. If there are no shutdown hooks and no initrd that
installs /run/initramfs/shutdown, then the only thing between your
hook and the reboot() syscall is an invocation of sync(). I wonder if
that might be the issue here? Can you try adding an explicit
/usr/bin/sync invocation to your hook script, and check if that
survives? (add an echo line after it, to check if it completes).

In general though: this really smells like an LVM or kernel issue. I
usually just reassign bugs involving LVM to the LVM package. I'd
recommend asking the LVM people for help, maybe?

Any chance you can try to reproduce this without LVM in the mix?

Sorry if I have no other recommendations, but if sync() and reboot()
are really the only things that are executed after the hook script then
I really have no suggestion what might be going wrong except that
there's something wrong with the kernel...

Sorry if this isn't too helpful,

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] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?

2014-12-02 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Dec 03, 2014 at 02:21:45AM +0100, Lennart Poettering wrote:
On Thu, 13.11.14 11:24, grantksupp...@operamail.com
(grantksupp...@operamail.com) wrote:

On Tue, Nov 11, 2014, at 08:09 AM, Lennart Poettering wrote:
On the upstream ML we usually discuss only more recent problems, which
are exposed upstream. Hence, please contact the Suse folks for more
help on the issue, or check if a current systemd version fails.

Already done, and just fyi -- appears now to be fixed:

@ https://bugzilla.suse.com/show_bug.cgi?id=903560#c48

rpm -q --changelog systemd
* Thu Nov 13 2014 wer...@suse.de
- Change patch 0001-add-hdflush-for-reboot-or-hddown-for-poweroff.patch
to skip hdflush as well as hddown but only use halt as fallback
for poweroff as well as synch in systemctl before any reboot command
(compare with commit 4a3ad39957399c4a30fc472a804e72907ecaa4f9)

https://build.opensuse.org/package/view_file/Base:System/systemd/0001-add-hdflush-for-reboot-or-hddown-for-poweroff.patch?expand=1

shutdown now shuts down correctly.

I cannot make any sense out of that commit I must say. I really wish
suse would discuss this with us upstream, if there's a bug to fix
upstream...
It seems that they add reboot(RB_HALT_SYSTEM) as a fallback to
reboot(RB_POWER_OFF).
I'd consider this a workaround for a bug in firmware or hardware.
I seems like it shouldn't hurt, so maybe let's take this part?

The other thing is adding an additional sync. I think you added one
in the meanwhile.

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

Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?

On Wed, 03.12.14 03:13, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

On Wed, Dec 03, 2014 at 02:21:45AM +0100, Lennart Poettering wrote:
On Thu, 13.11.14 11:24, grantksupp...@operamail.com
(grantksupp...@operamail.com) wrote:

Already done, and just fyi -- appears now to be fixed:

@ https://bugzilla.suse.com/show_bug.cgi?id=903560#c48

https://build.opensuse.org/package/view_file/Base:System/systemd/0001-add-hdflush-for-reboot-or-hddown-for-poweroff.patch?expand=1

shutdown now shuts down correctly.

I cannot make any sense out of that commit I must say. I really wish
suse would discuss this with us upstream, if there's a bug to fix
upstream...

It seems that they add reboot(RB_HALT_SYSTEM) as a fallback to
reboot(RB_POWER_OFF).
I'd consider this a workaround for a bug in firmware or hardware.
I seems like it shouldn't hurt, so maybe let's take this part?

Well, if RB_POWER_OFF doesn't work, we should let the kernel folks
figure this out. systemd is not the place to work around hardware
bugs.

The other thing is adding an additional sync. I think you added one
in the meanwhile.

An additional one? Why that?

Lennart

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

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

On Tue, 02.12.14 11:43, Didier Roche (didro...@ubuntu.com) wrote:

Heya!

Applied the patch with some changes (converted all log messages to the
new errno logging). Please check if everything still works as
intended.

Also applied patches 3, 4, 5 after that.

Thanks!

Lennart

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

Re: [systemd-devel] [PATCH] bootchart: add standalone bootchart service

On 12/03/2014 08:30 AM, Lennart Poettering wrote:
 On Sat, 15.11.14 15:42, WaLyong Cho (walyong@samsung.com) wrote:
 
 Heya,
 
 The suggested way to run boot chart is by specifying
 init=/usr/lib/systemd/systemd-bootchart on the kernel cmdline. What's
 the rationale behind making this a service? I mean, if it is started
 as service it races against other services and might thus not be able
 track services run in early boot. Can you please elaborate on the
 rationale for this patch?
 
Yes, right. I'm also generate bootchart using kernel command line. But,
in some kind of bootloader, it can be hard to modify the kernel command
line. In our mobile phone, we do not allow to modify kernel command line
to protect from hacking. In this case, this service can be useful even
if some of processes can not be shown. But according to this service
dependency, I think this bootchart service will be activated quite ahead
of boot sequence.
And as you said, this will race against others. That why this should NOT
be enabled as default. But if someone want to get bootchart easily then
he can get bootchart after just enable this. And also I think this can
be useful to newbie. Isn't it?

WaLyong

 ---
  Makefile.am|  9 +
  units/systemd-bootchart.service.in | 17 +
  2 files changed, 26 insertions(+)
  create mode 100644 units/systemd-bootchart.service.in

 diff --git a/Makefile.am b/Makefile.am
 index 1aef242..b682606 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -4428,6 +4428,15 @@ rootlibexec_PROGRAMS += \
  
  dist_pkgsysconf_DATA += \
  src/bootchart/bootchart.conf
 +
 +nodist_systemunit_DATA += \
 +units/systemd-bootchart.service
 +
 +EXTRA_DIST += \
 +units/systemd-bootchart.service.in
 +
 +CLEANFILES += \
 +units/systemd-bootchart.service
  endif
  
  # 
 --
 diff --git a/units/systemd-bootchart.service.in 
 b/units/systemd-bootchart.service.in
 new file mode 100644
 index 000..aafc1ea
 --- /dev/null
 +++ b/units/systemd-bootchart.service.in
 @@ -0,0 +1,17 @@
 +#  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=Standalone Bootchart
 +Documentation=man:systemd-bootchart.service(1) man:bootchart.conf(5)
 +DefaultDependencies=no
 +
 +[Service]
 +ExecStart=@rootlibexecdir@/systemd-bootchart -r
 +
 +[Install]
 +WantedBy=sysinit.target
 -- 
 1.9.3

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 
 
 Lennart
 
___
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-12-02 Thread Łukasz Stelmach

It was 2014-12-02 wto 10:31, when Tom Gundersen wrote:
 On Tue, Dec 2, 2014 at 10:24 AM, Łukasz Stelmach l.stelm...@samsung.com 
 wrote:
 It was 2014-12-02 wto 00:35, when Lennart Poettering wrote:
 On Mon, 24.11.14 09:30, Łukasz Stelmach (l.stelm...@samsung.com) wrote:
 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
[...]

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

 Yes. If networkd is compile-time enable the dir should exist and be
 properly owned, even if it networkd is split off into a separate
 binary package and currently not installed.

 And what if the networkd is disabled? Does the directory must exist? Now
 if networkd is disabled /run/systemd/netif* are not in
 tmpfiles.d/systemd.conf. Is this correct?

 No, if you disable networkd at compile-time the directory is not
 needed (and using the sd-network library will rightly fail).
[...]

 My two cents.

That gives about three with Lennart's ;-) Thanks.

-- 
Łukasz Stelmach
Samsung RD Institute Poland
Samsung Electronics


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

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