Re: [systemd-devel] systemd-networkd and openvswitch?

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 13:39, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

 Hi,
 
 is there any possibility to nicely integrate openvswitch to a system
 that runs systemd-networkd? While I understand that there does not
 currrently seem to be native openvswitch support in systemd-networkd,
 maybe somebody has written unit files to bring up the openvswitch
 before systemd-networkd kicks in?
 
 The reason I am trying to do this is that openvswitch is advertised as
 being capable to switch an entire dot1q VLAN trunk through to a VM,
 something that a standard Linux bridge doesn't seem to do.
 
 Any comments about this?

I don't know ovs that well, but as I mentioned before: if they have an
OK API I think it might make sense to add native ovs support to
networkd (and nspawn).

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] clarification on daemon-reload

2015-05-18 Thread Lennart Poettering
On Sun, 17.05.15 10:06, Igor Bukanov (i...@mir2.org) wrote:

 Hello,
 
 suppose a unit B runs just because another unit A contains Requires=B and
 After=B. When B runs, it changes A like adding new dependencies, altering
 Exec command etc and then B calls systemctl daemon-reload. Then the systemd
 uses the new definition for A, right?
 
 In particular, if according to the new configuration A should not run at
 all because B changed the systemd configuration so A is no longer required
 by any units, then systemd does not run A, right?

No, what is queued is queued. A daemon-reload should leave the execution
queue unmodified, neither remove nor add new entries.

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-nspawn trouble

2015-05-18 Thread Lennart Poettering
On Sun, 17.05.15 17:30, Michael Biebl (mbi...@gmail.com) wrote:

 2015-05-15 22:16 GMT+02:00 Tom Gundersen t...@jklm.no:
  on-demand I agree with Lennart that it makes the most sense to simply
  unconditionally load the modules. If this is undesirable the solution
  should be to teach the kernel to auto-load the modules, not to expect
  the admin to figure out that explicit loading is required, IMHO.
 
 And now we expect that the admin figures out how to disable loading of
 the iptables module, which isn't anymore obvious.

Why would he do that? 

I generally think we should make things easy if we can, and hence work
out of the box. But avoid the iptables module to be loaded is
certainly not making things work, it's the opposite, it is avoiding
to make things work. Hence, it's much less interesting to me.

 What I was suggesting was, that the iptables modules should only be
 loaded on demand, i.e. when the firewalling functionality is actually
 used. Lennart did argue, that he didn't want to do that within
 networkd, since he didn't want to grant networkd that capability to
 load modules and therefor to load the module unconditionally in PID 1.
 But moving the modules loading out of networkd doesn't mean, it has to
 be done unconditonally, see how we did it for
 udev/kmod-static-nodes.service

Note that effectively we just changed auto-loading of the iptables
module from opt-in to opt-out, to make it behave more like most other
modules. Previously it was never auto-loaded. Now it is by default
loaded at boot, but you can still blacklist it with modprobe.conf
files. This hence ensures behaviour is identical to modules that are
auto-loaded via udev or via opening of a device node: for all kinds of
modules the blacklist is now where you can turn off or on the
module. That's certainly the friendliest way for admins to handle
this...

Lennart

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


Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 10:18, Per Bergqvist (p...@bst.lu) wrote:

 Lennart,
 
 Thank you for all the comments. 
 
 I have changed everything except the 'No space between function name and 
 opening “(“‘.
 Cannot find anything about that in CODING_STYLE or evidence in other
 sources.

Hmm? This is from CODING_STYLE:

- Do not write foo (), write foo().

 +
 +static int nvme_identify(struct udev *udev, int fd, void *buf, __u32 
 buf_len) {
 +struct nvme_admin_cmd command = {
 +.opcode   = nvme_admin_identify,
 +.addr = (unsigned long)buf,
 +.data_len = buf_len,
 +.cdw10= 1 };

Hmm, why __u32? First of all, try to use userspace types,
i.e. uint32_t. But secondly, shouldn't this be size_t?

 +int main(int argc, char *argv[]) {
 +_cleanup_udev_unref_ struct udev *udev = NULL;
 +
 +struct nvme_id_ctrl nvme_id_ctrl = { .vid = 0 };

initializer appears unnecessary, as the compiler initializes all
fields to 0 anyway if they are unspecified. i.e. just write = { };
here...

 +node = argv[optind];
 +if (node == NULL) {
 +log_error(no node specified);
 +return EXIT_FAILURE;
 +}
 +
 +fd = open(node, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
 +if (fd  0) {
 +log_error_errno(errno, Unable to open '%s': %m, node);
 +return -errno;

needs to be return EXIT_FAILURE. After all this is the main()
function, where errors are not errno-style, but EXIT_FAILURE,
EXIT_SUCCESS or something else betwee 0..255...

 +}
 +
 +if (nvme_identify(udev, fd, nvme_id_ctrl, sizeof(struct 
 nvme_id_ctrl)) == 0) {
 +memcpy (model, nvme_id_ctrl.mn,
 sizeof(nvme_id_ctrl.mn));

Please remove the space...

 +if (serial[0] != '\0') {
 +printf(ID_SERIAL=%s_%s\n, model, serial);
 +printf(ID_SERIAL_SHORT=%s\n, serial);
 +} else {
 +printf(ID_SERIAL=%s\n, model);
 +}

Please no {} for single-line if blocks (or else blocks...)

To me this looks fine otherwise, but I figure Kay has to decide if
this goes in or not. He might want this as built-in rather than as
external tool though...

Lennart

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


Re: [systemd-devel] [PATCH] nspawn: cloexec extraneous fds

2015-05-18 Thread Alban Crequy
On Mon, May 18, 2015 at 2:00 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 18.05.15 10:34, Alban Crequy (al...@endocode.com) wrote:

 On Wed, May 13, 2015 at 6:14 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Mon, 11.05.15 16:41, Alban Crequy (alban.cre...@gmail.com) wrote:
 
   src/nspawn/nspawn.c | 9 -
   1 file changed, 8 insertions(+), 1 deletion(-)
 
  diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
  index 71a6239..2e45c3b 100644
  --- a/src/nspawn/nspawn.c
  +++ b/src/nspawn/nspawn.c
  @@ -3739,6 +3739,9 @@ int main(int argc, char *argv[]) {
   bool root_device_rw = true, home_device_rw = true, srv_device_rw 
  = true;
   _cleanup_close_ int master = -1, image_fd = -1;
   _cleanup_fdset_free_ FDSet *fds = NULL;
  +_cleanup_fdset_free_ FDSet *misc_fds = NULL;
  +int fd;
  +Iterator i;
   int r, n_fd_passed, loop_nr = -1;
   char veth_name[IFNAMSIZ];
   bool secondary = false, remove_subvol = false;
  @@ -3775,7 +3778,11 @@ int main(int argc, char *argv[]) {
   goto finish;
   }
   }
  -fdset_close_others(fds);
  +fdset_new_fill(misc_fds);
  +FDSET_FOREACH(fd, fds, i) {
  +fdset_remove(misc_fds, fd);
  +}
  +fdset_cloexec(misc_fds, true);
   log_open();
 
  Do we really need an extra FDSet object for this? Why not just remove
  the fdset_close_others() from the nspawn parent and adding it to the
  child process instead, without depending on O_CLOEXEC? Appears much
  simpler to as it avoids keeping two fdsets around...

 fdset_close_others() iterates on the open file descriptor found in
 /proc/self/fd/* at the time of the call, so I would need to make sure
 it does not harvest the newly opened file descriptors such as the ones
 used by the barrier, one end of the kmsg socket pair, one end of the
 rtnl socket pair, and possibly others. I would need to use fdset_put()
 on each of those fds. Although the fds used by the barrier are
 exported in struct Barrier, it is kind of internal structure.

 Well, we could just invoke it after the barrier stuff has done its
 deed, right before we invoke exec(), no?

Right. Sorry for the noise, I'll send another patch shortly, after I
finish testing it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH v2] hostname: Allow comments in /etc/hostname

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 12:36, Martin Pitt (martin.p...@ubuntu.com) wrote:

  static int read_and_strip_hostname(const char *path, char **hn) {
 -char *s;
 -int r;
 +_cleanup_fclose_ FILE *f = NULL;
 +char l[LINE_MAX];
 +char *s = NULL;
  
  assert(path);
  assert(hn);
  
 -r = read_one_line_file(path, s);
 -if (r  0)
 -return r;
 +/* may have comments, ignore them */
 +f = fopen(/etc/hostname, re);
 +if (!f)
 +return -errno;
 +FOREACH_LINE(l, f, return -errno) {
 +truncate_nl(l);
 +if (l[0] != '\0'  l[0] != '#') {
 +s = strdup(l);
 +break;

This code will result in ENOENT being returned on OOM... That's not right...

Also consider using strstrip() here.

 -r = read_one_line_file(/etc/hostname, 
 c-data[PROP_STATIC_HOSTNAME]);
 -if (r  0  r != -ENOENT)
 -return r;
 +/* /etc/hostname may have comments, ignore them */
 +f = fopen(/etc/hostname, re);
 +if (!f)
 +return -errno;
 +FOREACH_LINE(l, f, return -errno) {
 +truncate_nl(l);
 +if (l[0] != '\0'  l[0] != '#') {
 +c-data[PROP_STATIC_HOSTNAME] = strdup(l);
 +break;
 +}
 +}

Given that this same code is needed twice in different components,
please add a new call read_etc_hostname() to
src/shared/hostname-util.c (which I just added to git). It should then
also do hostname_cleanup() on the name, and thus pretty much replace
read_and_strip_hostname() entirely in hostname-setup.c.

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 1/3] core: Add LISTEN_NAMES environment variable

2015-05-18 Thread Krzysztof Opasiak



On 05/16/2015 11:28 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, May 15, 2015 at 05:35:48PM +0200, Lennart Poettering wrote:

On Fri, 15.05.15 17:09, Krzysztof Opasiak (k.opas...@samsung.com) wrote:


When passing file descriptors to service systemd
pass also two environment variable:
- LISTEN_PID - PID of service
- LISTEN_FDS - Number of file descriptors passed to service

Passed fds may have different types: socket, fifo etc.
To distinguish them sd-daemon library provides a set of
sd_is_*() functions which does stat on given fd and path
and check if this fd is relaten with this path.

This commit adds third environment variable:
- LISTEN_NAMES - paths/addresses of passed fds

this variable consist of fds names separated by :.
Each fd name consist of two parts:
fd_type=fd_address


Why do we need the type at all? It can always be derived from the fd
anyway, so why specify?


Why it the motivation? Patch description talks tabout passing the
path/address in LISTEN_NAMES. Isn't this something that can be queried
already? TODO talks about identifiers. Is identifier the same thing,
or did the TODO item about have some different meaning?



Not exactly. As far as I know it is not possible to get for example fifo 
path when you have only file descriptor.  So it is not possible to ask 
what is fifo path for this fd? but you may only ask if this path related 
with this fd? Currently it is done by doing stat on fd and stat on path 
and compare the results.


If we pass this data in env we don't need to do stat on path but only do 
strcmp() (path cmp exactly, because /a/b/c is equal to /ab///c).


As far as I understood Lenart doing last hackfest paths are understood 
as identifiers but Lenart please correct me if I misunderstood something.


--
Krzysztof Opasiak
Samsung RD Institute Poland
Samsung Electronics
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] nspawn: close extra fds before execing init

2015-05-18 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431960330-19357-1-git-send-email-alban%40endocode.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 2/3] sd-daemon: Use LISTEN_NAMES env when available

2015-05-18 Thread Krzysztof Opasiak



On 05/15/2015 05:40 PM, Lennart Poettering wrote:

On Fri, 15.05.15 17:09, Krzysztof Opasiak (k.opas...@samsung.com) wrote:


LISTEN_NAMES environment variable contains details
about received file descriptors. Let's try to use it
instead of doing always two stats.


I am really not convinced that it is a good idea to store redundant
information in LISTEN_NAMES, especially if we don't have this
information in all cases anyway.


We also don't always have informations about paths as all descriptors 
from fd store have unknown path and type (as far as I know and 
understand systemd code but I may be wrong)




Please, let's keep this simple: LISTEN_NAMES should only carry actual
names, nothing else, and let's query the kernel for the actual fd
types.


I'm not sure if doing stat() to determine how he should interpret 
content of field in env is simpler and easier but of course you are the 
maintainer so you decide how things should be done;)




There's really no point in storing the types in $LISTEN_NAMEs, since
this code is no way performance senstive...



Matching between fds and list of expected paths is done in n^2 so it has 
no performance impact as long as number of passed fds isn't big. I know 
that it is usually done only once during service startup but it increase 
latency between event occurrence and it processing.



+static const char *sd_get_fd_name(int fd) {


The sd_ prefix we add for exported functions, don't bother with it
for internal calls.


Ok. Will fix this.




+static const char sep = ':';
+static const char escape = '\\';
+const char *env = NULL;
+const char *e = NULL;
+int i;

-assert_return(fd = 0, -EINVAL);
+assert_return(fd = 3, NULL);


assert_return() we use for verifiying parameters passed in from
external users to check for programming errors. Since this function is
static this generally doesn't apply. See CODING_STYLE for details...



will replace with traditional if.

--
Krzysztof Opasiak
Samsung RD Institute Poland
Samsung Electronics
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] nspawn: close extra fds before execing init

2015-05-18 Thread Alban Crequy
From: Alban Crequy al...@endocode.com

When systemd-nspawn gets exec*()ed, it inherits the followings file
descriptors:
- 0, 1, 2: stdin, stdout, stderr
- SD_LISTEN_FDS_START, ... SD_LISTEN_FDS_START+LISTEN_FDS: file
  descriptors passed by the system manager (useful for socket
  activation). They are passed to the child process (process leader).
- extra lock fd: rkt passes a locked directory as an extra fd, so the
  directory remains locked as long as the container is alive.

systemd-nspawn used to close all open fds except 0, 1, 2 and the
SD_LISTEN_FDS_START..SD_LISTEN_FDS_START+LISTEN_FDS. This patch delays
the close just before the exec so the nspawn process (parent) keeps the
extra fds open.

This patch supersedes the previous attempt (cloexec extraneous fds):
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031608.html
---
 src/nspawn/nspawn.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 8aa7b45..85a7bad 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -3998,7 +3998,6 @@ int main(int argc, char *argv[]) {
 goto finish;
 }
 }
-fdset_close_others(fds);
 log_open();
 
 if (arg_directory) {
@@ -4509,6 +4508,8 @@ int main(int argc, char *argv[]) {
  * setup, too... */
 (void) barrier_place_and_sync(barrier); /* #5 */
 
+(void) fdset_close_others(fds);
+
 if (arg_boot) {
 char **a;
 size_t l;
-- 
2.1.4

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


Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 07:51, Igor Bukanov (i...@mir2.org) wrote:

 On 18 May 2015 at 05:35, Andrei Borzenkov arvidj...@gmail.com wrote:
 
 
  What exactly do you mean? It has RefuseManualStart set?
 
 I meant that, for example, A is enabled and contains Requires=B and
 this is the only dependency that causes B to run and then B alters or
 even disables A and calls systemctl daemon-reload.
 
  I'm not entirely sure what systemd can sensibly do in this case though.
 
 What I would like to know is what is the exact behavior of systemctl
 daemon-reload. I am writing a service that creates/modifies other
 units by placing files under /run and I would like to know what are
 the limitations. In my case I cannot use a systemd.generator as the
 service depends on a mounted directory.

Well, my recommendation is to avoid daemon-reloads during the normal
boot process if possible, since there are some unresolved issues:

If you run a service with multiple ExecStart= lines, we currently do
not remember at which one we are while doing a daemon reload (simply
because it's not clear how to solve this comprehensively: should we go
by line number or should we search for the same command line? -- after
all the precise set of ExecStart= lines might have changed due to the
reload).

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] Fwd: [wiki systemd] systemd French doc

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 17:43, Jiel Beaumadier (beaumad...@gmail.com) wrote:

 Hi,
 
 A French documentation was written about systemd :
 http://lea-linux.org/documentations/Systemd
 
 Its main scope is the general public. The documentation tends to be as
 pedagogic as possible. I think that it could be interesting for French
 speaking users to put a link towards this doc at the official page of
 systemd (http://www.freedesktop.org/wiki/Software/systemd/) in the chapter
 'Manuals and Documentation for Users and Administrators'. What do you think
 about this ?

I added a link there 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] Fwd: [wiki systemd] systemd French doc

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 22:18, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Sat, May 16, 2015 at 05:43:13PM +0200, Jiel Beaumadier wrote:
  Hi,
  
  A French documentation was written about systemd :
  http://lea-linux.org/documentations/Systemd
  
  Its main scope is the general public. The documentation tends to be as
  pedagogic as possible. I think that it could be interesting for French
  speaking users to put a link towards this doc at the official page of
  systemd (http://www.freedesktop.org/wiki/Software/systemd/) in the chapter
  'Manuals and Documentation for Users and Administrators'. What do you think
  about this ?
 
 I still think you should cut systemadm entirely out. Unfortunately it's not
 only unstable, but also there's little hope of it improving.

Yeah, I agree, it would be wise not to point anyone to that tool anymore.

Lennart

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


Re: [systemd-devel] dev-root.device is not active, results in an umount spree

2015-05-18 Thread Martin Pitt
Lennart Poettering [2015-05-18 14:10 +0200]:
 The whole point of the tentative state is that devices showing up in
 /proc/self/mountinfo but not in /sys are put in it. Are you saying
 that does not work?

Simple demonstration with some bind mount:

  # systemd-nspawn -b -D /tmp/myroot --bind /etc/cron.daily/

with current systemd you'll get

  dev-sda3.device loaded inactive dead dev-sda3.device

and with the v2 patch you get

  dev-sda3.device loaded activating tentative dev-sda3.device

which is what's intended, right? (This simple setup doesn't reproduce
the overzealous unmounting yet, but it shows the wrong state)

Thanks,

Martin

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


Re: [systemd-devel] tentative state and unmount on mapper

2015-05-18 Thread Martin Pitt
Hey Umut,

Umut Tezduyar Lindskog [2015-05-18 15:59 +0200]:
 I have 2 mounts (one is bind mount) on mapper device.
 
 /proc/self/mountinfo:
 47 37 254:0 / /var/spool/storage/SD_DISK
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
 49 37 254:0 / /var/spool/storage/areas/SD_DISK/root
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
 
 systemctl -t device --all | grep map:
 dev-mapper-mmcblk0p1.device   loaded activating tentative 
 /dev/mapper/mmcblk0p1
 
 As soon as I unmount the bind mount, systemd picks up the change in
 /proc/self/mountinfo and changes the tentative device to dead and
 due to that all file systems BindsTo to the device are being
 unmounted. Application which mounted the partitions is not getting a
 chance to unmount the fs.

I stumbled over this as well. This is fixed in the 0002-* patch in

  http://lists.freedesktop.org/archives/systemd-devel/2015-May/031953.html

Direct link:
  
http://lists.freedesktop.org/archives/systemd-devel/attachments/20150518/09d36e6f/attachment-0001.patch

This is caused by the device_update_found_one() state transition from
tentative to dead which we must never do as there is no way to
know when a tentative device is actually dead. We must only transition
to dead from plugged.

Testing/feedback appreciated!

Martin

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


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


Re: [systemd-devel] dev-root.device is not active, results in an umount spree

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 06:41, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Lennart Poettering [2015-05-17 18:06 +0200]:
  More specifically, they should follow the second item in the
  Execution Environment section: pre-mount /sys read-only in the
  container.
 
 That's the default indeed, but you can configure it otherwise. While
 that might be questionable, it's just one way to exhibit the bugs, as
 Dimitri's plan9 example shows there are other cases where file systems
 aren't on a real /dev/ device.

I don't really grok what the problem you are experencing is supposed
to be: note that a device showing up in /proc/self/mountinfo means it
will be set to tentative state, and thus will not resolve in an
unmount. What more do you need?

The whole point of the tentative state is that devices showing up in
/proc/self/mountinfo but not in /sys are put in it. Are you saying
that does not work?

Generally, dependencies should not be generated depending on
state. Dependencies should be static as much as possible, and
sometimes augmented as we load in more units, but the very clear focus
needs to be to keep them as static as possible. Acting on them should
be dynamic however, and hence our state engines for the units should
be optimized to reflect the unit state as fine-grained as necessary.

I don't understand your patch I must say, but from what I grok it
appears to make deps dynamic, based on state, and that's something I
really don't like.

Lennart

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


Re: [systemd-devel] [PATCH/resend] Use reflinking to copy kernel

2015-05-18 Thread Simon McVittie
On 18/05/15 13:15, Lennart Poettering wrote:
 --reflink=auto is the default in cp since a while.

I think you're thinking of recent mv versions, or a patched coreutils?

cp in current coreutils git never reflinks

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cp.c#n785

unless explictly requested

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cp.c#n957

(line numbers valid as of today's git master)

I believe the rationale is that people invoking cp(1) might expect to
have two entirely independent copies of all the file's disk blocks
afterwards, such that a kernel- or hardware-level bit-flip in one would
leave the other untouched - as opposed to reflinking, in which
*user-space* changes to one leave the other untouched. I don't
personally think that rationale is sufficiently convincing to outweigh
the simplicity of reflinking by default, but I don't maintain coreutils,
and perhaps I'd think differently if I did.

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

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


Re: [systemd-devel] [PATCH 1/3] core: Add LISTEN_NAMES environment variable

2015-05-18 Thread Krzysztof Opasiak


Hi,

On 05/15/2015 05:35 PM, Lennart Poettering wrote:

On Fri, 15.05.15 17:09, Krzysztof Opasiak (k.opas...@samsung.com) wrote:


When passing file descriptors to service systemd
pass also two environment variable:
- LISTEN_PID - PID of service
- LISTEN_FDS - Number of file descriptors passed to service

Passed fds may have different types: socket, fifo etc.
To distinguish them sd-daemon library provides a set of
sd_is_*() functions which does stat on given fd and path
and check if this fd is relaten with this path.

This commit adds third environment variable:
- LISTEN_NAMES - paths/addresses of passed fds

this variable consist of fds names separated by :.
Each fd name consist of two parts:
fd_type=fd_address


Why do we need the type at all? It can always be derived from the fd
anyway, so why specify?


Passing both type and path allows us to determine type of socket without 
any syscall. For example sd_is_fifo() function is reduced to three 
simple steps:

- find nth field in env
- do strncmp(field, fifo=, length)
- do path cmp with value received from user

It is much faster as there is no context switch and consistent if we 
take both type and path from env instead of doing stat to determine type 
and then take path from env for comparsion. It doesn't add much more 
complexity but eliminates stat on fd in most functions so why not to do 
this?





@@ -1171,9 +1171,55 @@ static void do_idle_pipe_dance(int idle_pipe[4]) {
  safe_close(idle_pipe[3]);
  }

+static int build_listen_names(const char **fds_names, unsigned n_fds, char 
**env)
+{


We generally place the opening bracket in the same line as the
function name...


I tried but it was stronger than me;) Will fix in v2.




+unsigned i, j;
+unsigned pos;
+int size;
+char *names = NULL;
+static const char separator = ':';
+static const char escape = '\\';
+static const char *prefix = LISTEN_NAMES=;


Hmm, why not just use the literl strings/chars wherever we need
them. It sounds needlessly complex to use constants for this, after
all we only use this within this one function...

Also the last constant declares both a pointer and an array of string,
which appears unnecessary...


In may opinion this improves readability of the code. It simply 
indicates that you are looking for a separator and not for some unnamed 
semicolon. You don't need to look in documentation what does : means, as 
you see descriptive variable name.


Moreover I have used this in more than one place and I know that it is 
convenient to use compiler to check your typos instead of wasting half 
an hour to find out that you made a typo when writing string constant 
for nth time. If I write prefux compiler will complain about undefined 
identifier but if I write LISTEN_NANES= compilation will be clear and 
I will have to look it for this while testing.


I have no strong opinion, in C both defines and static const are good 
enough in this use case. I may replace those with defines if you like?





+
+assert(fds_names);
+assert(env);
+
+size = strlen(prefix);
+for (i = 0; i  n_fds; ++i) {
+size += 1; /* for separator */
+if (!fds_names[i])
+continue;
+
+for (j = 0; fds_names[i][j]; ++j)
+if (fds_names[i][j] == separator)
+size += 2;
+else
+size += 1;
+}
+
+names = malloc(size);
+if (!names)
+return -ENOMEM;
+
+strcpy(names, prefix);
+pos = strlen(prefix);
+for (i = 0; i  n_fds; ++i) {
+for (j = 0; fds_names[i]  fds_names[i][j]; ++j) {
+if (fds_names[i][j] == separator)
+names[pos++] = escape;
+names[pos++] = fds_names[i][j];
+}
+names[pos++] = separator;
+}
+names[pos - 1] = '\0';
+*env = names;
+return 0;
+}


I am not entirely sure I grok this function, but doesn't this do what
strv_join() does anyway?


Well, not exactly it does a little bit more.

As use colons to separate paths in LISTEN_NAMES variable and we cannot 
guarantee that socket, fifo etc path doesn't contain colons (: is a 
valid path character in linux) we have to escape them. What this 
function does is merging all the paths, escape semicolons in paths using 
\ and place colons to separate paths. Example:


take:

socket=/run/my_test/func::other_func.socket
fifo=/run/other::test/myfifo
special=/dev/mydevice

produce:
socket=/run/my_test/func\:\:other_func.socket:fifo=/run/other\:\:test/myfifo:special=/dev/mydevice




+
+if (fds_names) {
+r = build_listen_names(fds_names, n_fds, x);
+if (r)
+return r;


We usually 

Re: [systemd-devel] [PATCH/resend] Use reflinking to copy kernel

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 22:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Fri, May 08, 2015 at 05:11:15PM -0400, Josh Boyer wrote:
  On May 8, 2015 11:38 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
  wrote:
  
   On Thu, May 07, 2015 at 10:08:56PM -0400, Matthew Miller wrote:
On Thu, May 07, 2015 at 04:29:11PM -0500, Ian Pilcher wrote:
 Hmm.  If don't know off the top of my head if Fedora cloud images
  have a
 separate /boot or not, but disk space is a big concern in such
 environments.
   
They don't have a separate boot, fwiw.
   What about amending the patch to use
  
  cp --reflink=auto ...
  
   ?
  
  The kernel-install tool is what would need to be patched. It is what is
  doing the copying at install time.  Doing it in the spec is pointless as
  we're mucking around in the build root not the actual system.
 Strictly speaking, using --reflink=auto would be useful in the spec
 too, to avoid copying the files. In a build root it is very likely to
 succeed too.
 
 But you're right of course, it's kernel-install that counts.
 
 Patches for kernel-install and dracut attached.
 
 [Since this patch is for systemd, resending it to systemd-devel. I should
 have done in the first place. If intend to push it in a few days if nobody
 objects.]

--reflink=auto is the default in cp since a while. Instead of
cluttering systemd's or dracut's trees with it, I'd rather recommend
upgrading coreutils as necessary.

I don't think this should go in,

Lennart

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


[systemd-devel] tentative state and unmount on mapper

2015-05-18 Thread Umut Tezduyar Lindskog
Hi,

There have been few discussions about tentative state and unmounting
and I am experiencing different problem in the same device logic.

I am at 219 + 628c89cc + 496068a8 + 5259bcf6

I have 2 mounts (one is bind mount) on mapper device.

/proc/self/mountinfo:
47 37 254:0 / /var/spool/storage/SD_DISK
rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
/dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
49 37 254:0 / /var/spool/storage/areas/SD_DISK/root
rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
/dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered

systemctl -t device --all | grep map:
dev-mapper-mmcblk0p1.device   loaded activating tentative /dev/mapper/mmcblk0p1

As soon as I unmount the bind mount, systemd picks up the change in
/proc/self/mountinfo and changes the tentative device to dead and
due to that all file systems BindsTo to the device are being
unmounted. Application which mounted the partitions is not getting a
chance to unmount the fs.

Should I enumerate available mount units to see if anyone else has
been mounted on the device that is about to be set as DEVICE_DEAD in
device_update_found_one()?

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


Re: [systemd-devel] [PATCH] nspawn: cloexec extraneous fds

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 10:34, Alban Crequy (al...@endocode.com) wrote:

 On Wed, May 13, 2015 at 6:14 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Mon, 11.05.15 16:41, Alban Crequy (alban.cre...@gmail.com) wrote:
 
   src/nspawn/nspawn.c | 9 -
   1 file changed, 8 insertions(+), 1 deletion(-)
 
  diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
  index 71a6239..2e45c3b 100644
  --- a/src/nspawn/nspawn.c
  +++ b/src/nspawn/nspawn.c
  @@ -3739,6 +3739,9 @@ int main(int argc, char *argv[]) {
   bool root_device_rw = true, home_device_rw = true, srv_device_rw 
  = true;
   _cleanup_close_ int master = -1, image_fd = -1;
   _cleanup_fdset_free_ FDSet *fds = NULL;
  +_cleanup_fdset_free_ FDSet *misc_fds = NULL;
  +int fd;
  +Iterator i;
   int r, n_fd_passed, loop_nr = -1;
   char veth_name[IFNAMSIZ];
   bool secondary = false, remove_subvol = false;
  @@ -3775,7 +3778,11 @@ int main(int argc, char *argv[]) {
   goto finish;
   }
   }
  -fdset_close_others(fds);
  +fdset_new_fill(misc_fds);
  +FDSET_FOREACH(fd, fds, i) {
  +fdset_remove(misc_fds, fd);
  +}
  +fdset_cloexec(misc_fds, true);
   log_open();
 
  Do we really need an extra FDSet object for this? Why not just remove
  the fdset_close_others() from the nspawn parent and adding it to the
  child process instead, without depending on O_CLOEXEC? Appears much
  simpler to as it avoids keeping two fdsets around...
 
 fdset_close_others() iterates on the open file descriptor found in
 /proc/self/fd/* at the time of the call, so I would need to make sure
 it does not harvest the newly opened file descriptors such as the ones
 used by the barrier, one end of the kmsg socket pair, one end of the
 rtnl socket pair, and possibly others. I would need to use fdset_put()
 on each of those fds. Although the fds used by the barrier are
 exported in struct Barrier, it is kind of internal structure.

Well, we could just invoke it after the barrier stuff has done its
deed, right before we invoke exec(), no?

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] shared/json: JSON parser + number tokenizer bugfix

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 10:45, Pavel Odvody (podv...@redhat.com) wrote:

   Yes, it could be handled, but I wouldn't call it nicely :)
   Since there's a lot of nested objects / arrays I guess that you'd need
   to do the syntactic analysis anyway. It'd be even worse in case some
   values would shadow the key names, or some part of the document were
   re-ordered.
  
  Well, what I really don't like about object parsers is that they might
  take unbounded memory, which is much less a problem with stream
  parsers...
  
  If we do object model parsing we really need to be careful with
  enforcing limits on everything...
  
  Lennart
  
 
 Hmm, I could add a function measuring the size of the resulting object.
 
   int json_parse_check(const char* data, size_t *size);
 
 Which accepts a JSON string and outputs the final size on success.
 
 What do you think?

Thinking about it I suspect we are OK without additional checks, as
long as we strictly enforce size limits on the JSON text we download
(and we do so comprehensively afaics). The parsed structures' memory
use is a linear function of the JSON text size, hence this should be
safe already, hence I ignore my earlier comments on this. 

Lennart

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


[systemd-devel] Setting UseDomains=yes by default DHCP

2015-05-18 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Aug 14, 2014 at 01:27:19PM +0200, Tom Gundersen wrote:
 On Thu, Aug 14, 2014 at 1:11 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 
  UseDomain= should have the effect of adding the domains from dhcp option
  15 and 119 to the list of domains for the interface. And
  sd_network_get_link_domains() should then return a single list, of
  deduplicated entries, with the domains specified in Domains= first, and
  then the dhcp domains possible added in at the end.
 
  Zbigniew, I think this simplification would be beneficial, as I really
  don't see the need to make the search vs. route domain thing
  configurable
 
  Tom, what's your take on all of this?
 
 
 Sorry for taking forever to answer to this thread. I have been going
 back and forth in my mind about how this should look.
 
 I think in the end I essentially agree with Lennart's last suggestion.
 Let's make this dead-simple and collapse the search/route domains for
 each link into a single list. I think this is fine given that we
 restrict the search behaviour to single-labels.

Sorry for taking forever to answer to this thread. I have been going
back and forth in my mind about how this should look. ;)

I now agree with what Lennart proposed too. This is partially implemented
now, and with UseDomains=yes, option 15 is used to to set 'search' field.

I think we should go a step further, and set UseDomains=yes by default,
to have 'search' populated in /etc/resolv.conf. I think the security
reservations are overstated:
iiuc, the concern was that multi-level domain names (i.e. those with at least
one dot) could be spoofed by controlling the search suffix. But for
names with at least two levels glibc only uses the search list as a fallback.
So to mount a successful spoof, the attacker needs to
a) control the dhcp server domain option to return a domain under attacker 
control
b) arrange for the user to resolve an invalid domain name

Considering that the attack can only work for domain names which would
not resolve otherwise, and requires either a misconfigured dhcp server
or control of some dns server, this doesn't seem very serious. After all,
there are more direct avenues of attack if one controls dhcp or dns traffic.

(Above was about traditional libc resolver. For systemd-resolved clients
I don't think we should ever suffix non-single-level domain names with 
anything.)

The story is sligthly different for single-level names. By setting 
UseDomains=yes
we allow the dhcp server some control over the resolution of those names.
But that seems natural too. If we want to allow LLMR or avahi, allowing
the dhcp server to also control local name resolution seems a natural extension.

Any reservations for making UseDomains=yes the default?

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

 My only hesitation has been that I can imagine someone wanting to add
 search domains that do not imply anything about routing. However, I
 think in this case it does not make much sense to make this per-link,
 but it should rather be a global SearchDomains= option (in
 resolved.conf) or something to that effect.
 
 Zbigniew, Michael, what do you think?
 
 Cheers,
 
 Tom

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


Re: [systemd-devel] Fwd: [wiki systemd] systemd French doc

2015-05-18 Thread Jiel A. Beaumadier



Hi,

A French documentation was written about systemd :
http://lea-linux.org/documentations/Systemd




I still think you should cut systemadm entirely out. Unfortunately it's not
only unstable, but also there's little hope of it improving.

Zbyszek



Done. Thanks !


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


Re: [systemd-devel] dev-root.device is not active, results in an umount spree

2015-05-18 Thread Martin Pitt
Hello Lennart,

Lennart Poettering [2015-05-18 14:10 +0200]:
 I don't really grok what the problem you are experencing is supposed
 to be: note that a device showing up in /proc/self/mountinfo means it
 will be set to tentative state, and thus will not resolve in an
 unmount. What more do you need?

Exactly, that's what these patches do.

 The whole point of the tentative state is that devices showing up in
 /proc/self/mountinfo but not in /sys are put in it. Are you saying
 that does not work?

Right. As I said, the problem is that when /mountinfo is being read,
.device units (with state tentative/found == MOUNT) are not actually
being created, despite the comment saying so. They are created later,
rather unintentionally, in unit_add_node_link() which calls
manager_load_unit(); but the latter always just creates stubs with
state dead, and never sets any proper state.

 Generally, dependencies should not be generated depending on state.
 Dependencies should be static as much as possible, and sometimes
 augmented as we load in more units, but the very clear focus needs
 to be to keep them as static as possible. Acting on them should be
 dynamic however, and hence our state engines for the units should be
 optimized to reflect the unit state as fine-grained as necessary.

Fully agreed.

 I don't understand your patch I must say, but from what I grok it
 appears to make deps dynamic, based on state, and that's something I
 really don't like.

No, it just fixes the creation of the .device units to happen at the
right and intended time (when we actually have a proper state), and
thus have the intended state tentative instead of dead.

Martin

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


Re: [systemd-devel] [PATCH/resend] Use reflinking to copy kernel

2015-05-18 Thread Zbigniew Jędrzejewski-Szmek
On Mon, May 18, 2015 at 02:15:09PM +0200, Lennart Poettering wrote:
 On Sat, 16.05.15 22:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
  On Fri, May 08, 2015 at 05:11:15PM -0400, Josh Boyer wrote:
   On May 8, 2015 11:38 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
   wrote:
   
On Thu, May 07, 2015 at 10:08:56PM -0400, Matthew Miller wrote:
 On Thu, May 07, 2015 at 04:29:11PM -0500, Ian Pilcher wrote:
  Hmm.  If don't know off the top of my head if Fedora cloud images
   have a
  separate /boot or not, but disk space is a big concern in such
  environments.

 They don't have a separate boot, fwiw.
What about amending the patch to use
   
   cp --reflink=auto ...
   
?
   
   The kernel-install tool is what would need to be patched. It is what is
   doing the copying at install time.  Doing it in the spec is pointless as
   we're mucking around in the build root not the actual system.
  Strictly speaking, using --reflink=auto would be useful in the spec
  too, to avoid copying the files. In a build root it is very likely to
  succeed too.
  
  But you're right of course, it's kernel-install that counts.
  
  Patches for kernel-install and dracut attached.
  
  [Since this patch is for systemd, resending it to systemd-devel. I should
  have done in the first place. If intend to push it in a few days if nobody
  objects.]
 
 --reflink=auto is the default in cp since a while. Instead of
 cluttering systemd's or dracut's trees with it, I'd rather recommend
 upgrading coreutils as necessary.
I don't think that's true. With today's git, without --reflink=auto,
cp does a normal read() + write(). I think the default for mv is to use
reflink though.

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


Re: [systemd-devel] [PATCH] fstab-generator: add x-systemd.requires and x-systemd.requires-mounts-for

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 12:30, Karel Zak (k...@redhat.com) wrote:

 Currently we have no way how to specify dependencies between fstab
 entries (or another units) in the /etc/fstab. It means that users are
 forced to bypass fstab and write .mount units manually.
 
 The patch introduces new systemd fstab options:
 
 x-systemd.requires=PATH

Applied! Thanks!

(Made one OOM fix though, in case strv_push() fails.)

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] [correct PATCH v2] dev-root.device is not active, results in an umount spree

2015-05-18 Thread Martin Pitt
Martin Pitt [2015-05-17 15:54 +0200]:
 This fixes the original systemd immediately unmounts my mounts bug,
 but not for very long: If you remount or unmount just one mount on a
 tentative device, mountinfo changes, and device_found_node() now calls
 device_update_found_one() with add == 0. Then
 
 n = add ? (d-found | found) : (d-found  ~found);
 
 would unset the previous DEVICE_FOUND_MOUNT flag, leaving 0 (i. e.
 DEVICE_NOT_FOUND). Thus the previously tentative device would once
 again be set to dead, and systemd would unmount all other mounts
 from it. This must never happen, we simply can't declare tentative
 devices as dead and clean up their unmounts, this only works for
 plugged ones that we know via udev.

Eek, I attached the wrong 0002- patch, sorry about that. The above is
fixed by the attached patch, please ignore 0002- from the previous
mail. For completeness I also re-attach 0001- again (unchanged).

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From bc080c3a0ddd24fabd94d11dc609967d557d044d Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Sun, 17 May 2015 15:07:47 +0200
Subject: [PATCH 1/3] device: create units with intended found value

Change device_found_node() to also create a .device unit if a device is not
known by udev; this is the case for tentative devices picked up by mountinfo
(DEVICE_FOUND_MOUNT).  With that we can record the found attribute on the
unit.

Change device_setup_unit() to also accept a NULL udev_device, and don't
add the extra udev information in that case.

Previously device_found_node() would not create a .device unit, and
unit_add_node_link() would then create a dead stub one via
manager_load_unit(), so we lost the found attribute and unmounted everything
from that device.

https://launchpad.net/bugs/102
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031658.html
---
 src/core/device.c | 53 ++---
 1 file changed, 26 insertions(+), 27 deletions(-)

diff --git a/src/core/device.c b/src/core/device.c
index 8eca4c2..3fddc62 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -292,26 +292,28 @@ static int device_add_udev_wants(Unit *u, struct udev_device *dev) {
 
 static int device_setup_unit(Manager *m, struct udev_device *dev, const char *path, bool main) {
 _cleanup_free_ char *e = NULL;
-const char *sysfs;
+const char *sysfs = NULL;
 Unit *u = NULL;
 bool delete;
 int r;
 
 assert(m);
-assert(dev);
 assert(path);
 
-sysfs = udev_device_get_syspath(dev);
-if (!sysfs)
-return 0;
-
 r = unit_name_from_path(path, .device, e);
 if (r  0)
 return log_error_errno(r, Failed to generate unit name from device path: %m);
 
 u = manager_get_unit(m, e);
 
+if (dev) {
+sysfs = udev_device_get_syspath(dev);
+if (!sysfs)
+return 0;
+}
+
 if (u 
+sysfs 
 DEVICE(u)-sysfs 
 !path_equal(DEVICE(u)-sysfs, sysfs)) {
 log_unit_debug(u, Device %s appeared twice with different sysfs paths %s and %s, e, DEVICE(u)-sysfs, sysfs);
@@ -336,17 +338,19 @@ static int device_setup_unit(Manager *m, struct udev_device *dev, const char *pa
 /* If this was created via some dependency and has not
  * actually been seen yet -sysfs will not be
  * initialized. Hence initialize it if necessary. */
+if (sysfs) {
+r = device_set_sysfs(DEVICE(u), sysfs);
+if (r  0)
+goto fail;
 
-r = device_set_sysfs(DEVICE(u), sysfs);
-if (r  0)
-goto fail;
+(void) device_update_description(u, dev, path);
 
-(void) device_update_description(u, dev, path);
+/* The additional systemd udev properties we only interpret
+ * for the main object */
+if (main)
+(void) device_add_udev_wants(u, dev);
+}
 
-/* The additional systemd udev properties we only interpret
- * for the main object */
-if (main)
-(void) device_add_udev_wants(u, dev);
 
 /* Note that this won't dispatch the load queue, the caller
  * has to do that if needed and appropriate */
@@ -788,22 +792,17 @@ int device_found_node(Manager *m, const char *node, bool add, DeviceFound found,
  * will still have a device node even when the medium
  * is not there... */
 
-if (stat(node, st)  0) {
-if (errno == ENOENT)
+if (stat(node, st) = 0) {
+if (!S_ISBLK(st.st_mode)  !S_ISCHR(st.st_mode))
 

Re: [systemd-devel] [PATCH/resend] Use reflinking to copy kernel

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 13:56, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

 On 18/05/15 13:15, Lennart Poettering wrote:
  --reflink=auto is the default in cp since a while.
 
 I think you're thinking of recent mv versions, or a patched
 coreutils?

Oh indeed, I noticed this behaviour on mv...

 I believe the rationale is that people invoking cp(1) might expect to
 have two entirely independent copies of all the file's disk blocks
 afterwards, such that a kernel- or hardware-level bit-flip in one would
 leave the other untouched - as opposed to reflinking, in which
 *user-space* changes to one leave the other untouched. I don't
 personally think that rationale is sufficiently convincing to outweigh
 the simplicity of reflinking by default, but I don't maintain coreutils,
 and perhaps I'd think differently if I did.

Yeah, I very much disagree with that upstream decision too... I mean,
if people really want byte copies they should think in terms of dd
not cp...

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] hwdb: Add trackpoint sensitivity setting for Thinkpad X230 tablet

2015-05-18 Thread Hans de Goede
This model needs the trackpoint sensitivity to be boosted to not be too slow
to be usable, see: https://bugzilla.redhat.com/show_bug.cgi?id=1200717
---
 hwdb/70-pointingstick.hwdb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
index 72c1a3b..a8c21a2 100644
--- a/hwdb/70-pointingstick.hwdb
+++ b/hwdb/70-pointingstick.hwdb
@@ -87,6 +87,8 @@ evdev:name:*DualPoint 
Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE6400*:pvr*
 # Lenovo
 #
 
+# Lenovo Thinkpad X230 tablet
+evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX230Tablet:*
 # Lenovo Thinkpad X240
 evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX240:*
 # Lenovo Thinkpad T440s
-- 
2.4.0

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


[systemd-devel] [PATCH v2] buildsys: actually install 70-pointingstick.hwdb

2015-05-18 Thread Mantas Mikulėnas
---
*sigh* Tabs.

 Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile.am b/Makefile.am
index 4639b2f..5bcbfff 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3913,6 +3913,7 @@ dist_udevhwdb_DATA = \
hwdb/60-evdev.hwdb \
hwdb/60-keyboard.hwdb \
hwdb/70-mouse.hwdb \
+   hwdb/70-pointingstick.hwdb \
hwdb/70-touchpad.hwdb
 
 EXTRA_DIST += \
-- 
2.4.1

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


Re: [systemd-devel] [PATCH] nspawn: cloexec extraneous fds

2015-05-18 Thread Alban Crequy
On Wed, May 13, 2015 at 6:14 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 11.05.15 16:41, Alban Crequy (alban.cre...@gmail.com) wrote:

  src/nspawn/nspawn.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
 index 71a6239..2e45c3b 100644
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
 @@ -3739,6 +3739,9 @@ int main(int argc, char *argv[]) {
  bool root_device_rw = true, home_device_rw = true, srv_device_rw = 
 true;
  _cleanup_close_ int master = -1, image_fd = -1;
  _cleanup_fdset_free_ FDSet *fds = NULL;
 +_cleanup_fdset_free_ FDSet *misc_fds = NULL;
 +int fd;
 +Iterator i;
  int r, n_fd_passed, loop_nr = -1;
  char veth_name[IFNAMSIZ];
  bool secondary = false, remove_subvol = false;
 @@ -3775,7 +3778,11 @@ int main(int argc, char *argv[]) {
  goto finish;
  }
  }
 -fdset_close_others(fds);
 +fdset_new_fill(misc_fds);
 +FDSET_FOREACH(fd, fds, i) {
 +fdset_remove(misc_fds, fd);
 +}
 +fdset_cloexec(misc_fds, true);
  log_open();

 Do we really need an extra FDSet object for this? Why not just remove
 the fdset_close_others() from the nspawn parent and adding it to the
 child process instead, without depending on O_CLOEXEC? Appears much
 simpler to as it avoids keeping two fdsets around...

fdset_close_others() iterates on the open file descriptor found in
/proc/self/fd/* at the time of the call, so I would need to make sure
it does not harvest the newly opened file descriptors such as the ones
used by the barrier, one end of the kmsg socket pair, one end of the
rtnl socket pair, and possibly others. I would need to use fdset_put()
on each of those fds. Although the fds used by the barrier are
exported in struct Barrier, it is kind of internal structure.

By using fdset_cloexec() instead, I don't need to keep in sync the fds
to add in the FDSet whenever a new fd is added in systemd-nspawn.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 2/5] shared/json: JSON parser + number tokenizer bugfix

2015-05-18 Thread Pavel Odvody
On Fri, 2015-05-15 at 17:11 +0200, Lennart Poettering wrote:
 On Fri, 15.05.15 17:05, Pavel Odvody (podv...@redhat.com) wrote:
 
  On Fri, 2015-05-15 at 16:12 +0200, Lennart Poettering wrote:
   On Fri, 15.05.15 16:03, Pavel Odvody (podv...@redhat.com) wrote:
   
On Fri, 2015-05-15 at 15:23 +0200, Lennart Poettering wrote:
 On Thu, 07.05.15 17:47, Pavel Odvody (podv...@redhat.com) wrote:
 
 Hmm, so if I grok this right, then this at's a DOM-like (object
 model) parser for json, where we previously hat a SAX-like (stream)
 parser only. What's the rationale for this? Why doesn't the stream
 parser suffice?
 
 I intentionally opted for a stream parser when I wrote the code, and
 that#s actually the primary reason why i roleld my own parser here,
 instead of using some existing library
 

Hmm, I'd call it lexer/tokenizer, since the burden of syntactic analysis
is on the user. The parser is actually rather thin wrapper around
json_tokenize.

Rationale: the v2 manifest (also) contains embedded JSON documents and
is itself versioned, so it will change sooner or later.
I believe that parsing the manifest, or any decently complex JSON
document, using the stream parser would yield equal or bigger chunk of
code than generic DOM parser + few lines that consume it's API.
   
   Can you give an example of these embedded JSON documents?
   
   Couldn't this part be handled nicely by providing a call that skips
   nicely over json objects we don't want to process?
   
   Lennart
   
  
  http://pastebin.com/rrkVxHzT
  
  Yes, it could be handled, but I wouldn't call it nicely :)
  Since there's a lot of nested objects / arrays I guess that you'd need
  to do the syntactic analysis anyway. It'd be even worse in case some
  values would shadow the key names, or some part of the document were
  re-ordered.
 
 Well, what I really don't like about object parsers is that they might
 take unbounded memory, which is much less a problem with stream
 parsers...
 
 If we do object model parsing we really need to be careful with
 enforcing limits on everything...
 
 Lennart
 

Hmm, I could add a function measuring the size of the resulting object.

  int json_parse_check(const char* data, size_t *size);

Which accepts a JSON string and outputs the final size on success.

What do you think?

-- 
Pavel Odvody podv...@redhat.com
Software Engineer - EMEA ENG Developer Experience
5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno



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


Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Andrei Borzenkov
On Mon, May 18, 2015 at 8:51 AM, Igor Bukanov i...@mir2.org wrote:
 On 18 May 2015 at 05:35, Andrei Borzenkov arvidj...@gmail.com wrote:


 What exactly do you mean? It has RefuseManualStart set?

 I meant that, for example, A is enabled and contains Requires=B and
 this is the only dependency that causes B to run and then B alters or
 even disables A and calls systemctl daemon-reload.


In this case stopping B would be a bug. Requires dependency is only
ever considered when you start unit. But B could have been started
manually, so stopping it would be wrong.

 I'm not entirely sure what systemd can sensibly do in this case though.

 What I would like to know is what is the exact behavior of systemctl
 daemon-reload. I am writing a service that creates/modifies other
 units by placing files under /run and I would like to know what are
 the limitations. In my case I cannot use a systemd.generator as the
 service depends on a mounted directory.

As I already said, daemon-reload should not trigger any unit state
change itself. But I do not think it is set as documented API
anywhere.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] hwdb: Add trackpoint sensitivity setting for Thinkpad X230 tablet

2015-05-18 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431935640-3635-1-git-send-email-hdegoede%40redhat.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] buildsys: actually install 70-pointingstick.hwdb

2015-05-18 Thread Mantas Mikulėnas
---
 Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile.am b/Makefile.am
index 4639b2f..0b5b488 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3913,6 +3913,7 @@ dist_udevhwdb_DATA = \
hwdb/60-evdev.hwdb \
hwdb/60-keyboard.hwdb \
hwdb/70-mouse.hwdb \
+hwdb/70-pointingstick.hwdb \
hwdb/70-touchpad.hwdb
 
 EXTRA_DIST += \
-- 
2.4.1

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


Re: [systemd-devel] [PATCH] .gitignore: add GNU GLOBAL files

2015-05-18 Thread Łukasz Stelmach
It was 2015-05-15 pią 18:36, when Dimitri John Ledkov wrote:
 On 15 May 2015 at 17:19, Łukasz Stelmach l.stelm...@samsung.com wrote:
 It was 2015-05-15 pią 18:03, when Lennart Poettering wrote:
 On Fri, 15.05.15 17:39, Łukasz Stelmach (l.stelm...@samsung.com) wrote:

 It was 2015-05-15 pią 17:25, when Lennart Poettering wrote:
  On Fri, 15.05.15 17:12, Łukasz Stelmach (l.stelm...@samsung.com) wrote:
 
  Hmm? What is GNU GLOBAL?

 Another cscope. A quote from http://www.gnu.org/software/global/

 --8---cut here---start-8---
 GNU GLOBAL is a source code tagging system that works the same way
 across diverse environments, such as Emacs editor, Vi editor, Less
 viewer, Bash shell, various web browsers, etc.

 You can locate various objects, such as functions, macros, structs,
 classes, in your source files and move there easily. [...]
 --8---cut here---end---8---

 The index files should not appear in git status.

 And is that tool even popular?

 Admittedly not the most popular but noticable.

 https://qa.debian.org/popcon-graph.php?packages=cscope%2Cglobal%2Cexuberant-ctagsshow_installed=onwant_percent=onwant_legend=onwant_ticks=onfrom_date=2010-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1


 With my Debian Developer hat on... popcon is not a metric... We mostly
 still have it as a trap - whenever popcon used as a reason it is shot
 down as invalid =)

Let's say that I considered popcon data rather binarily:  x  ε ? 1 : 0
;-)

 [...]  Imho .gitignore should only be used to clean-up  ignore by
 products that a given project generates, the rest IDE cruft is to be
 ignored on per user cases in a global excludes file as I've shown
 earlier.

Thank you for the hint. I haven't remebered that option.

-- 
Łukasz Stelmach
Samsung RD Institute Poland
Samsung Electronics


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


Re: [systemd-devel] [PATCH v2] systemctl: introduce --now for enable, disable and mask

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 08:24, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

 On 05/15/2015 09:51 AM, Lennart Poettering wrote:
 But anyway, this is certainly a matter of taste...
 
 Or cause for confusion.
 
 I asked an noob to run systemctl enable --now unit and he immediately
 asked back if he ran systemctl enable unit if it would not be enabled
 immediately so --now seems to be implying that something is not
 happening immediately.

Well, if you have a better word for --now I am all ears. All I know
is that I want it to be *one* option, and that it should apply to
enable/disable/mask (and maybe preset). How precisely it is named, is
a different question, and if we can find something better than
--now, then i'd be totally willing to rename it!

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] Setting UseDomains=yes by default DHCP

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 12:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 I now agree with what Lennart proposed too. This is partially implemented
 now, and with UseDomains=yes, option 15 is used to to set 'search' field.
 
 I think we should go a step further, and set UseDomains=yes by default,
 to have 'search' populated in /etc/resolv.conf. I think the security
 reservations are overstated:
 iiuc, the concern was that multi-level domain names (i.e. those with at least
 one dot) could be spoofed by controlling the search suffix. But for
 names with at least two levels glibc only uses the search list as a
 fallback.

Well, sure, being able to influence things at the beginning of the
search logic is more problematic than influencing things at the end of
the search logic, but i still think it's problematic, since it still
allows you to insert home.foobar.com into a domain foobar.com that
doesn't have home.foobar.com itself but only www.bar.com...

Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure,
but it I still believe we should default to the safer options, and
allow the others.

Altering the search paths is inherently something that makes no sense
on public networks, it only makes sense if you know your network well,
and trust it to some level. Hence opt-in sounds like the better option
to me.

 The story is sligthly different for single-level names. By setting 
 UseDomains=yes
 we allow the dhcp server some control over the resolution of those names.
 But that seems natural too. If we want to allow LLMR or avahi, allowing
 the dhcp server to also control local name resolution seems a natural 
 extension.
 
 Any reservations for making UseDomains=yes the default?

I'd really prefer if this stays opt-in. That said, I think it would be
a really good idea to improve the documentation of DHCP= to suggest
people to set UseDomains=yes if they need it.

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] Basic network with Fedora conatiner

2015-05-18 Thread Lennart Poettering
On Wed, 29.04.15 15:36, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:

 After installation of Fedora 22 container, the container (poppy) boots
 but no network.
 
 # journalctl -b -M poppy
 
 
 Apr 29 14:02:20 poppy firewalld[28]: 2015-04-29 14:02:20 ERROR:
 ebtables not usable, disabling ethernet bridge firewall.

Judging by this and the other logs you posted you don't have iptables
enabled in the kernel. without that ip masquerading will not work.

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] timers always run when time changes

2015-05-18 Thread Lennart Poettering
On Fri, 01.05.15 09:35, Likang Wang (labor...@gmail.com) wrote:

 Hi all,
 
 I hava a timer with the fellowing setting:
 
 # cat /lib/systemd/system/updateimage.timer
 
 [Unit]
 Description=Update image
 DefaultDependencies=false
 
 [Timer]
 OnCalendar=*-*-* 02:00:00
 Persistent=false
 
 [Install]
 WantedBy=multi-user.target
 
 And I want the timer call the same-name service only on 02:00:00 daily.
 
 The entire system is running on an embedded box, and the system time will
 be set to 2008-01-01 00:00:00 after every reboot. My app running on the box
 will get the real time from my server and update time on the box after
 every booting.(I could not use NTP or systemd-timesyncd for some other
 reason)
 
 Here is my problem.
 When my app set the system time to real time, systemd will wake up the
 updateimage.timer and run the updateimage.service no matter what time it it
 now.The log looks like this:
 
 Jan  1 08:14:00 systemd[1]: xx.service: cgroup is empty
 Apr 30 21:04:00 systemd[1]: Time has been changed
 Apr 30 21:04:00 systemd[1]: Set up TFD_TIMER_CANCEL_ON_SET timerfd.
 Apr 30 21:04:00 systemd[1]: Timer elapsed on updateimage.timer
 Apr 30 21:04:00 systemd[1]: Trying to enqueue job
 updateimage.service/start/replace
 Apr 30 21:04:00 systemd[1]: Installed new job updateimage.service/start as
 9269
 
 What I want is the timer and the same-name service only run exactly on
 02:00:00 daily, but not when time changes. What should I do?

Well, the way this works is that when the timer unit is started
systemd determines the next time the unit shall elapse. Given that
your clock is initialized to 2008-01-01 00:00:00 this means it will
calculated 2008-01-02 02:00:00. Then, when you make the clock jump,
and it becomes 2015-04-30 21:04:00 systemd notes that the calculated
elapsing time is now already in the past and immediately dispatch the
timer unit.

In most cases this is arguably what you want since it gives you the
guarantee that your service is always run less time ago than the
interval you specified -- on the wallclock.

Now I can see that in you case this behaviour might not be
advisable. Two suggestions:

- consider using systemd-timesyncd for time synchronization. It
  implements sNTP and will sync the last known time to disk every time
  it gets an sNTP sync or the system is shut down. At boot it uses
  that time to reinitialize the clock, as early as possible, before
  NTP is done. THis will give you monotonic time which should solve
  your probelm.

- Introduce some flag file to conditionalize your service with
  ConditionPathExists= or so, so that it is only started when the
  clock was set at least once... Each time you sync the clock, create
  that file. if it is missing you hence know that the clock is not
  ready for syncing on...

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] Fall back to shell and still see failure

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 13:23, Chris Morin (chris.mor...@gmail.com) wrote:

 Hi
 
   During a normal boot on my system, the last service to launch starts
 a special shell which isn't your standard linux shell. Unfortunately,
 before getting to that service, there is a long chain of dependencies
 which have to run. I want to drop to a normal linux shell when any of
 these dependencies fail to be able to jump right into debugging it.
 
 I set the OnFailure option of the last service to
 emergency.target. This works great. The only issue is that the shell
 appears before systemd has a chance to display which service actually
 failed.
 
  I can obviously check which service failed with systemctl --failed
 but I'd like to have it displayed during boot as it normally is.
 
 I'm assuming I can't see the failure message because emergency.service
 grabs control of the console before systemd can print out it's
 message. Is this the case? Is there any way to get what I'm looking
 for?

Type=idle is for cases like this. See systemd.service(5) for details.

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] 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file

2015-05-18 Thread Lennart Poettering
On Wed, 29.04.15 19:34, nusenu (nus...@openmailbox.org) wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Hi,
 
 I'm running into a problem with systemd's hardening features
 ReadOnlyDirectories and ReadWriteDirectories *when* using them in
 multi-instance service files - temp. workaround was to disable them [1].
 
 - - that the service works fine *with* these hardening features enabled
 in a single instance service file
 - - I'm not using the %i placeholder in the ReadWriteDirectories paths
 
 Error message:
 
 Failed at step NAMESPACE spawning /usr/bin/tor: No such file or directory
 service: main process exited, code=exited, status=226/NAMESPACE

Any chance you can retry to reproduce this with strace -p1 -o
/tmp/log -f -s500 so that we can see what precisely is failing there?

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 1/3] core: Add LISTEN_NAMES environment variable

2015-05-18 Thread Zbigniew Jędrzejewski-Szmek
On Mon, May 18, 2015 at 06:01:10PM +0200, Lennart Poettering wrote:
 Being able to attach a name to the fds is hence really useful. logind
 could use this to attach the session identifier to the fds, and would
 hence be able to safely map the fds back to their sessions after
 coming back from a restart...
Yeah, that makes sense. But currently there's no proposal how to specify
those identifiers. Would be nice discuss both sides of the proposal at
the same time.

sd_pid_notify_with_fds() would probably have to be extended to be
sd_pid_notify_with_fds2(pid_t pid, int unset_environment, const char *state, 
const int *fds, const char* const *names, unsigned n_fds)

And what about socket units: we could automatically generate identifiers
like blah.socket-1, foo.socket-1, foo.socket-2 to allow sockets from multiple
socket files be distinguished. In principle this could be made configurable
through a new option, but I don't think it's worth the trouble.

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


[systemd-devel] Fall back to shell and still see failure

2015-05-18 Thread Chris Morin
Hi

  During a normal boot on my system, the last service to launch starts
a special shell which isn't your standard linux shell. Unfortunately,
before getting to that service, there is a long chain of dependencies
which have to run. I want to drop to a normal linux shell when any of
these dependencies fail to be able to jump right into debugging it.

I set the OnFailure option of the last service to
emergency.target. This works great. The only issue is that the shell
appears before systemd has a chance to display which service actually
failed.

 I can obviously check which service failed with systemctl --failed
but I'd like to have it displayed during boot as it normally is.

I'm assuming I can't see the failure message because emergency.service
grabs control of the console before systemd can print out it's
message. Is this the case? Is there any way to get what I'm looking
for?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Reduce unit-loading time

2015-05-18 Thread cee1
Hi Martin,

At the first glance, I find ureadahead has some difference compared
with the readahead once in systemd, IIRC:

1. ureadahead.service is in default.target, which means ureadahead
starts later than systemd's?
2. The original systemd readahead has collect and replay two
services, and these are done in ureadahead.service?
3. IIRC, The original systemd readahead uses madvise(); ureadahead
uses readahead()
4. The original systemd readahead uses fanotify() to get the list of
accessed files; ureadahead use fsnotify
5. ureadahead has different readahead strategies for ssd and hhd:
5.1 For the former, initiate multi-threads to perform readahead, and
they are running at the lowest IO priority.
5.2 For the later, perform readahead for both inode and file content
at a very high CPU/IO priority (and only support extN filesystem ?)


2015-05-18 18:40 GMT+08:00 Martin Pitt martin.p...@ubuntu.com:
 Hello cee1,

 cee1 [2015-05-18 18:24 +0800]:
 Does the readahead-*.service shipped with systemd work for you?

 systemd dropped the builtin readahead in 217. It's reasonably easy to
 get back by reverting the drop readahead patches, but carrying that
 patch in packages is fairly intrusive. In Ubuntu we've had
 ureadahead [1] for many years which is good enough for things like
 phones or other ARM boards with slow MMC storage, so I just added
 systemd units to that. It's a separate project so that we don't need
 to install ureadahead everywhere, just where/when we actually need it.

 Martin

 [1] https://launchpad.net/ubuntu/+source/ureadahead
 --
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



-- 
Regards,

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


Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Igor Bukanov
On 18 May 2015 at 17:18, Lennart Poettering lenn...@poettering.net wrote:
 Well, my recommendation is to avoid daemon-reloads during the normal
 boot process if possible, since there are some unresolved issues:

What is then a canonical way to implement initialization when the
configuration comes from a drive that is not available during early
boot like virtio mount or uploaded from a network connection? Clearly
I can write a new persistent config and reboot the system for the new
changes to take an affect, but I would prefer to keep all the config
changes under /run so reboot always brings the system into a clean
state. I.e. how one should implement a staged boot when the system
performs a minimal initialization like mounting some paths or
initializing a minimal networking, gets the rest of the config via
that and then run the rest of initialization?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 17:53, Igor Bukanov (i...@mir2.org) wrote:

 On 18 May 2015 at 17:18, Lennart Poettering lenn...@poettering.net wrote:
  Well, my recommendation is to avoid daemon-reloads during the normal
  boot process if possible, since there are some unresolved issues:
 
 What is then a canonical way to implement initialization when the
 configuration comes from a drive that is not available during early
 boot like virtio mount or uploaded from a network connection? Clearly
 I can write a new persistent config and reboot the system for the new
 changes to take an affect, but I would prefer to keep all the config
 changes under /run so reboot always brings the system into a clean
 state. I.e. how one should implement a staged boot when the system
 performs a minimal initialization like mounting some paths or
 initializing a minimal networking, gets the rest of the config via
 that and then run the rest of initialization?

One option is to do this from the initrd: mount your alternative
config source from there, and then when doing the full root transition
already have all the data you need around.

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 1/3] core: Add LISTEN_NAMES environment variable

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 16:37, Krzysztof Opasiak (k.opas...@samsung.com) wrote:

 Why it the motivation? Patch description talks tabout passing the
 path/address in LISTEN_NAMES. Isn't this something that can be queried
 already? TODO talks about identifiers. Is identifier the same thing,
 or did the TODO item about have some different meaning?
 
 Not exactly. As far as I know it is not possible to get for example fifo
 path when you have only file descriptor.  

 So it is not possible to ask what
 is fifo path for this fd? but you may only ask if this path related with
 this fd? Currently it is done by doing stat on fd and stat on path and
 compare the results.
 
 If we pass this data in env we don't need to do stat on path but only do
 strcmp() (path cmp exactly, because /a/b/c is equal to /ab///c).
 
 As far as I understood Lennart doing last hackfest paths are understood as
 identifiers but Lenart please correct me if I misunderstood something.

Well, I don't think it's a good idea to include paths in the ids,
since they are so problematic in a namespaced world. Instead, we
should just define our own namespace for the ids, and just require
them to be short strings, independent from any fs path, fd type or so...

Lennart

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


Re: [systemd-devel] Automatic user ACL management

2015-05-18 Thread Lennart Poettering
On Sun, 17.05.15 14:20, Mikhail Morfikov (mmorfi...@gmail.com) wrote:

 allow-module-loading = no
 allow-exit = no
 system-instance = yes
 enable-shm = no
 exit-idle-time = -20
 
 then I started pulseaudio in the system mode and I was able to play
 sound all the time. But there's another question -- is there any
 difference between pulseaudio in system mode and pulseaudio in user
 mode + adding specific users to the audio group? I mean in the link I
 had given in the previous post, you can read something like this: By
 the way, you don't want users permanently added to groups like audio or
 video. Such user would be able to ssh into the machine while you are
 using it and spy on you using webcam, microphone etc. Access to such
 critical peripherals should only be granted for active user. Does this
 concern pulseaudio in the system mode with users added to the
 pulse-access group?

pulseaudio does not implementd a user identity framework, it will not
track which user is on which seat. Hence you should not use system
mode, since it gives everybody with access to it, complete access to
everything it manageds, without any further restrictions.

PA system mode is for devices that have no sessions, and not for
multi-user PCs, even if some people misuse it for that.

Lennart

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


Re: [systemd-devel] Will *.network replace resolv.conf? What about Options single-request?

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 15:52, Alexander E. Patrakov (patra...@gmail.com) wrote:

 16.05.2015 02:01, Christian Brunotte wrote:
 The resolver can send one DNS request packet (IPv4 or IPv6 doesn't matter) 
 that
 contains
 queries for both the A and  entries and the resolver may answer them in
 separate packets.
 
 I would be very much interested in seeing such successful conversation in a
 pcap file. Here is the reason why I don't really belive you: Unbound
 contains code that marks all DNS packets with multiple records in the query
 section as invalid. The code is in ./daemon/worker.c, function
 worker_check_request():
 
 if(LDNS_QDCOUNT(sldns_buffer_begin(pkt)) != 1) {
 verbose(VERB_QUERY, request wrong nr qd=%d,
 LDNS_QDCOUNT(sldns_buffer_begin(pkt)));
 return LDNS_RCODE_FORMERR;
 }

Yes, the DNS protocol does not allow query sections with more than one
question. (mDNS does allow this however).

Also note that doing an ANY query instead of A or  will not work
either, since ANY actually means just give me any RR you have, but
not actually give me all you have that match the rest of the
query... An ANY query might hence yield a response with just the A RR,
with just the  RR or with both, it's up to the server, and the
server has the complete freedom to choose between the three cases...

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 user ACL management

2015-05-18 Thread Mikhail Morfikov
On Mon, 18 May 2015 17:38:33 +0200
Lennart Poettering lenn...@poettering.net wrote:

 On Sun, 17.05.15 12:46, Mikhail Morfikov (mmorfi...@gmail.com) wrote:
 
  As you can read, for instance here
  ( 
  http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/
  ), logind, which is a part of systemd, can set permissions to some
  devices for user sessions. There's also a vid showing how this kind
  of behavior works in practice
  ( https://www.youtube.com/watch?v=qcD4Qr5ldbI ). In short, if you
  start, let's say, amarok, and you play some song, you will hear the
  sound till you switch to another user or TTY where you have only the
  login prompt. That's because the active session became inactive.
  
  I know that you can simply add a user (or users) to a specific
  group, in this case audio, and that will 'fix' this issue, but
  I'm wondering if there's another solution. What I really want is to
  set some permissions for the process so it could use the sound card
  all the time, even when all users have their sessions locked.
  
  Is that possible? I'm asking because I often listen to the music
  and I don't really need my monitor to be on most of the time, so I
  just lock the screen. But when I lock the screen, the active
  session becomes inactive and amarok stops playing. And yes, the
  screen should be locked, and not just turned off.
 
 To my knowledge GNOME runs the screen lock from the same session, and
 thus does not suffer by the problem...
 
 Generally, making your process member of the audio group is the way
 to go, if you want to forego the per-session device access control
 logic logind implements. You can use /usr/bin/newgrp to join a group
 for some of your processes only.
 
 Lennart
 

Something is wrong. I did the following steps:

$ newgrp audio

In the log I have the following message:

May 18 18:02:19 morfikownia newgrp[80543]: user 'morfik' (login 'morfik' on 
pts/7) switched to group 'audio'

Then I started amarok (in the same terminal):

$ amarok
$ ps -eo user,group,args | grep amarok
morfik   audioamarok

So it says the process has the audio group, but the sound disappears
when I switch to TTY, so nothing has changed. Should this happen, or am I
supposed to do something else in order to make it work?




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


Re: [systemd-devel] socket-activated containers with domain sockets

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 16:01, Simon Peeters (peeters.si...@gmail.com) wrote:

 hej all.
 
 I have a kind off weird setup using socket-activated containers:
 
 nginx on the host listens on port 80 and has a 'proxy_pass
 http://unix:/run/http/$host;' directive.
 
 then I have webserver@.socket listening on 'ListenStream=/run/http/%I'
 which in turn activates a container.
 
 this works fine with the following 'nginx-container@.service'
 [Service]
 ExecStart=/usr/bin/systemd-nspawn --private-network
 --bind=/srv/%i:/srv/http -D /var/lib/machines/nginx_base -x -M
 nginx_%i /usr/bin/nginx -g 'daemon off;'
 
 [Install]
 Also=webserver@%i.socket
 Alias=webserver@%i.service
 
 witch runs a (patched) nginx as only binary in that container.
 
 now I want to run systemd in such a container to run both nginx and nodejs.
 the problem is, what should be in my 'nginx.socket' in order to pass
 on that first socket systemd gets, which is a UDS outside of the
 container?

The way how daemons usually recognize the AF_UNIX fds passed to them during
socket activation is that they stat() the paths of the sockets
that could match and then compare that with fstat() of the fd they
have. If inode and device match they assume its the same socket.

This of course makes things difficult in an nspawn container, if the
AF_UNIX socket is bound on the host, since you cannot stat() it by
path then. 

A possible fix is to use --bind= on the AF_UNIX socket node, and thus
make it available in the container. Then if the container runs stat()
on the node, and comapres it with the fstat() of the fd it got, all
should be good.

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] [PATCH v4] core: Private*/Protect* options with RootDirectory

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 12:20, Alban Crequy (alban.cre...@gmail.com) wrote:

 From: Alban Crequy al...@endocode.com
 
 When a service is chrooted with the option RootDirectory=/opt/..., then
 the options PrivateDevices, PrivateTmp, ProtectHome, ProtectSystem must
 mount the directories under $RootDirectory/{dev,tmp,home,usr,boot}.

Applied with two changes:

 -r = append_mounts(m, STRV_MAKE(-/home, 
 -/run/user, -/root), protect_home == PROTECT_HOME_READ_ONLY ? READONLY : 
 INACCESSIBLE);
 +char *home_dir, *run_user_dir, *root_dir;
 +
 +home_dir = prefix_roota(root_directory, /home);
 +home_dir = strjoina(-, home_dir);
 +run_user_dir = prefix_roota(root_directory, 
 /run/user);
 +run_user_dir = strjoina(-, run_user_dir);
 +root_dir = prefix_roota(root_directory, /root);
 +root_dir = strjoina(-, root_dir);

prefix_roota() returns a const char*. hence home_dir and friends
should be const char* too.

The compiler warns about this loudly...

I figure eventually we should fix the - handling in a ncier way, and
parse them away and store them in a proper bool rather than this weird
prefix thing...

 +
 +log_info(Usage:);
 +log_info(  sudo TEST_NS_PROJECTS=/home/lennart/projects 
 ./test-ns);
 +log_info(  sudo TEST_NS_CHROOT=/home/alban/debian-tree 
 TEST_NS_PROJECTS=/home/alban/debian-tree/home/alban/Documents ./test-ns);

log_info() and friends is happy with newlines in log messages, please
use them instead of using multiple log log_info() invocations.

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] Will *.network replace resolv.conf? What about Options single-request?

2015-05-18 Thread Lennart Poettering
On Fri, 15.05.15 23:01, Christian Brunotte (c...@lathspell.de) wrote:

  Lennart Poettering lenn...@poettering.net hat am 15. Mai 2015 um 21:59
  geschrieben:
  
  
  On Mon, 04.05.15 14:57, Christian Brunotte (c...@lathspell.de) wrote:
  
   Hello
   
   systemd.network(5) with Options like DNS= and Domains= looks like
   /etc/resolv.conf will soon be superfluous.
   
   If that's the plan, I wonder what happens to options single-request
   which I had to use on all IPv6 enabled devices. Is ResolveOptions just
   missing in Systemd or considered so special that will stay in libc's 
   resolv.conf?
  
  What kind of bugs does this really solve?
  DNS servers that can only process one request per client at a time?
 
 Firewalls notice outgoing UDP packets and allow response packets only within a
 configured UDP session timeout time span. They need this timeout as UDP has
 no opening and closing handshake like TCP. Some firewalls with application
 layer 
 gateways try to be especially clever and understand that a DNS request 
 packet
 only gets exactly one DNS response packet after which they can safely close 
 this
 port. In the case of a IPv4+IPv6 dual stack system that is no longer the case,
 though.
 The resolver can send one DNS request packet (IPv4 or IPv6 doesn't matter) 
 that
 contains 
 queries for both the A and  entries and the resolver may answer them in
 separate packets.
 Once the first one passes the firewall, the port is closed though. The 
 requestor
 now has to wait
 some seconds in the hope that he gets the second packet - which
 never happens.

Well, this is not possible with DNS (see other mail). But maybe this
really is about doing multiple parallel DNS queries from the same source IP +
port. 

Right now all queries resolved does originate from the same IP
port. It has been requested to change this and use a new port number
for every single request, so that the 16 bit of the port can add to
the entropy when attackers want to guess DNS transaction credentials.

I wonder if we implement that if this might as side-effect also make
us more compatible with such firewalls, since unlike glibc we'd then
also have the A and  requests come from a different IP/port pair...

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 user ACL management

2015-05-18 Thread Lennart Poettering
On Sun, 17.05.15 12:46, Mikhail Morfikov (mmorfi...@gmail.com) wrote:

 As you can read, for instance here
 ( http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/
 ), logind, which is a part of systemd, can set permissions to some
 devices for user sessions. There's also a vid showing how this kind of
 behavior works in practice
 ( https://www.youtube.com/watch?v=qcD4Qr5ldbI ). In short, if you
 start, let's say, amarok, and you play some song, you will hear the
 sound till you switch to another user or TTY where you have only the
 login prompt. That's because the active session became inactive.
 
 I know that you can simply add a user (or users) to a specific group,
 in this case audio, and that will 'fix' this issue, but I'm wondering
 if there's another solution. What I really want is to set some
 permissions for the process so it could use the sound card all the
 time, even when all users have their sessions locked.
 
 Is that possible? I'm asking because I often listen to the music and I
 don't really need my monitor to be on most of the time, so I just lock
 the screen. But when I lock the screen, the active session becomes
 inactive and amarok stops playing. And yes, the screen should be
 locked, and not just turned off.

To my knowledge GNOME runs the screen lock from the same session, and
thus does not suffer by the problem...

Generally, making your process member of the audio group is the way
to go, if you want to forego the per-session device access control
logic logind implements. You can use /usr/bin/newgrp to join a group
for some of your processes only.

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 1/3] core: Add LISTEN_NAMES environment variable

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 10:19, Richard Maw (richard@codethink.co.uk) wrote:

 On Sat, May 16, 2015 at 09:28:22PM +, Zbigniew Jędrzejewski-Szmek wrote:
  Why it the motivation? Patch description talks tabout passing the
  path/address in LISTEN_NAMES. Isn't this something that can be queried
  already? TODO talks about identifiers. Is identifier the same thing,
  or did the TODO item about have some different meaning?
 
 I assumed that since the TODO came about at roughly the same time that systemd
 gained the ability to hold onto fds for services while they restarted, that
 this would be a way to identify the purpose of returned file descriptors
 without having to store a mapping of the inode number and device number to fd
 purpose into /run.
 
 The provided patch doesn't add a way to pass an identifier for a fd to systemd
 though so if that were the motivation, then this patch wouldn't be
 sufficient.

The TODO list item is purely about adding manual identifiers to fds,
it's not about adding type information to them: the kernel already
carries enough type information for us, the only problem is that
sometimes the type alone is not enough, we want to properly give the
fds a label.

This has a number of usecases. One of them is this: logind wants to
store fds referring to DRM or input devices in PID 1, so that it can
be restarted at any time without losing access to the DRM/input
devices it manages. Now, if you have multiple sessions that access the
same devices, then each of the fds referring to these DRM/input device
nodes look pretty much the same: their fstat() data is identical,
their /proc/self/fd/fd symlink is the same, hence it's impossible to
figure out which fd belongs to which session simply by looking at them
with fstat() and /proc.

Being able to attach a name to the fds is hence really useful. logind
could use this to attach the session identifier to the fds, and would
hence be able to safely map the fds back to their sessions after
coming back from a restart...

The names are useful in other cases too: if you have a daemon that
listens on two protocols at the same time (let's say POP3 and IMAP4)
on different ports, but not necessarily use the standard ports. hence
you need a nice way during actviation to let your daemon know which
one to use for which... (so far this was solved by having
configuration also for the daemon that then maps the ports back to the
protocol, but using ids for this is nicer, as it requires only one set
of configuration).

I hope that makes sense as rationale. The TODO list item is really
about labelling fds, not about attaching type info to the fds.

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] Reduce unit-loading time

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 18:24, cee1 (fykc...@gmail.com) wrote:

 2015-05-17 17:45 GMT+08:00 Martin Pitt martin.p...@ubuntu.com:
  Hello cee,
 
  cee1 [2015-05-16  0:46 +0800]:
  Thanks for the suggestion, it was other processes running in parallel
  which presumably consuming lots of IO, after sending SIGSTOP at the
  first (and SIGCONT later), the unit loading time is decreased to
  ~100ms.
 
  You probably want to use some readahead solution. We found that it
  makes a significant improvement on ARM boards with slow MMC cards.
 
  Martin
  --
  Martin Pitt| http://www.piware.de
  Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
 
 Hey,
 
 Thanks for the suggestion, IIRC, sequential read is also beneficial
 for flash storage.
 
 Does the readahead-*.service shipped with systemd work for you?

We removed the readahead logic from systemd a while back, since it had
no maintainer, and nobody wanted to pick it up.

 Question:
 How does systemd schedule two services that can be launched in
 parallel?

It's not defined. systemd will fork things of in an undefined order if
ther are multiple units runnable at the same time.

As mentioned elsewhere, I'd be willing to merge a patchat that changes
this and allows control of what service is forked off first, via some
per-unit Priority= setting or so.

Lennart

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


Re: [systemd-devel] [PATCH v2] networkd: do not change kernel forwarding parameters when IPForwarding is unset

2015-05-18 Thread Lennart Poettering
On Fri, 15.05.15 22:49, Tom Gundersen (t...@jklm.no) wrote:

 On Fri, May 15, 2015 at 10:02 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Fri, 15.05.15 12:56, Michael Marineau (michael.marin...@coreos.com) 
  wrote:
 
  (build time option to ./configure that is)
 
  I guess I'd be OK with that...
 
 It would be a shame if we started diverging on the defaults I think.
 Would be nice if we could come up with some scheme that would work for
 everyone. Would an option be to use a script to append
 IPForward='kernel' to your network files on upgrades? Pretty dirty,
 but I don't know how you usually deal with config changes...

Well, I think it is fine if downstream departs from our defaults... 

Another idea would be to add DefaultIPForward= to
/etc/systemd/networkd.conf that alters defaults for networks, the same
way as we have DefaultXYZ= in /etc/systemd/system.conf that affects
unit defaults?

Tom?

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] Will *.network replace resolv.conf? What about Options single-request?

2015-05-18 Thread Lennart Poettering
On Sat, 16.05.15 14:30, Mantas Mikulėnas (graw...@gmail.com) wrote:

  And I think that glibc does something similar. If it receives a truncated
  packet, it tries to get the full packet over TCP and only if the DNS server
  does not support TCP, it delivers the truncated data.
 
 Hmm, what happens when the server supports neither? (Retry with 8.8.8.8 or
 another fallback?)

I'd be very careful with such fallbacks: DNS servers (especially in
companies) tend to define their own local hostnames, and if we'd
automatically fall back to 8.8.8.8 in such cases, those hostnames
would suddently vanish from view.

8.8.8.8 is fine as fallback if no other DNS servers are known, but if
we know one we better do our best to talk to it.

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 user ACL management

2015-05-18 Thread Mikhail Morfikov
On Mon, 18 May 2015 18:18:57 +0200
Lennart Poettering lenn...@poettering.net wrote:

 On Mon, 18.05.15 18:16, Mikhail Morfikov (mmorfi...@gmail.com) wrote:
 
  Something is wrong. I did the following steps:
  
  $ newgrp audio
  
  In the log I have the following message:
  
  May 18 18:02:19 morfikownia newgrp[80543]: user 'morfik' (login
  'morfik' on pts/7) switched to group 'audio'
  
  Then I started amarok (in the same terminal):
  
  $ amarok
  $ ps -eo user,group,args | grep amarok
  morfik   audioamarok
  
  So it says the process has the audio group, but the sound disappears
  when I switch to TTY, so nothing has changed. Should this happen,
  or am I supposed to do something else in order to make it work?
 
 you need to run PA with those privs, not your media player. it's pa
 that needs the access rights to the device nodes, not your media
 player.
 
 Lennart
 

And now it works as expected! :)


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


Re: [systemd-devel] [PATCH 1/3] core: Add LISTEN_NAMES environment variable

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 15:36, Krzysztof Opasiak (k.opas...@samsung.com) wrote:

 Passing both type and path allows us to determine type of socket without any
 syscall. 

But how is that beneficial? THese sycalls are not slow, and this is
not perfoimance sensitive anyway...

 It is much faster as there is no context switch and consistent if we take
 both type and path from env instead of doing stat to determine type and then
 take path from env for comparsion. It doesn't add much more complexity but
 eliminates stat on fd in most functions so why not to do this?

Well, I disagree. It *does* add considerable complexity, especially
since it doesn't cover namespaced environments...

I am very sure $LISTEN_NAMES should only carry identifier strings
chosen by humans, and not duplicate what you can already do with
fstat() and /proc.

 Hmm, why not just use the literl strings/chars wherever we need
 them. It sounds needlessly complex to use constants for this, after
 all we only use this within this one function...
 
 Also the last constant declares both a pointer and an array of string,
 which appears unnecessary...
 
 In may opinion this improves readability of the code. It simply indicates
 that you are looking for a separator and not for some unnamed semicolon. You
 don't need to look in documentation what does : means, as you see
 descriptive variable name.

Well, so far we preferred short code over unnecessary verbose code, as
that helps readability too...

 Well, not exactly it does a little bit more.
 
 As use colons to separate paths in LISTEN_NAMES variable and we cannot
 guarantee that socket, fifo etc path doesn't contain colons (: is a valid
 path character in linux) we have to escape them. What this function does is
 merging all the paths, escape semicolons in paths using \ and place colons
 to separate paths. Example:

I'd simply dictate that the names included in $LISTEN_NAMES are not
allowed to contain colons. We should make this easy for
implementors. Escaping schemes are good if we need to be universal
but if we don't have to because we define our own namespace, then we
should avoid requiring them.

Lennart

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


Re: [systemd-devel] 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file

2015-05-18 Thread nusenu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

 I'm running into a problem with systemd's hardening features 
 ReadOnlyDirectories and ReadWriteDirectories *when* using them
 in multi-instance service files - temp. workaround was to disable
 them [1].
 
 - - that the service works fine *with* these hardening features
 enabled in a single instance service file - - I'm not using the
 %i placeholder in the ReadWriteDirectories paths
 
 Error message:
 
 Failed at step NAMESPACE spawning /usr/bin/tor: No such file or
 directory service: main process exited, code=exited,
 status=226/NAMESPACE
 
 Any chance you can retry to reproduce this with strace -p1 -o 
 /tmp/log -f -s500 so that we can see what precisely is failing
 there?

looks like it works out of the box now! :)

Since then systemd got updated, but I didn't see anything related in
debians changelog:
http://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_215-17_changelog

Should I downgrade to see if it breaks again?
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVWi/tAAoJEFv7XvVCELh0EvgQAKKQv2eIN3T2IQSt4J/0UaVs
kYduV9yS3fD/PB5WdVvKng8pDLZ9YjO6fHiFKJPHumHkOxD4GupyC1vXOttiNbaA
t+FfSI+cITGShK/EkR9EoBZpQdA/IbQrrABWR4x/0q1GMGS+6UwCgUjwVw7ibLpL
n9ZPNNib/gMLsFlArRbhAZ9DpcSMisKFTkvISL8UtRM3lyzSvVEMHyT5bBI74hic
GVzhga1gMXpvxnRX95jU245NzDWh1VzrtN44vVvrwYhlgU29uf0KYAgilX3VmyQS
qMAY9jBK6eQ2PJQTu0saUJRxv3i4obYXCobLnka0QHEcfS7zt1O0GfBe9bSctfwE
9qwEaFkVBbuCgtLrlApPGNfABKtKss+cyvp1oTt7qPE4+KgQ7z80rGUWHcG4QKiu
k1A6kYOJ793qwCxc9mIiBuYivzphCB1H5Yh9UuAjh2M0Yjg18JI2rdUBw/j8+gKa
wqoKZFA5NPeAgKcJQj+7dsJRzfbWPj2253wUt2neQDTHZ5k4hcTTYVSudovOOhcd
4+SmoUFFfe1rSUYft5MjfZbKVM0BUgKUNX98yP6nH8cS1BAszLZOglq7NzFOIaZc
Q1sIS8mXuZFkPDVY0fLnCUrEr1p6rjBO4DQFNahKyuhwvPSiErzHkl0XnBUR7QVx
CP7GBf2TQjueWJoSsfUs
=tcbx
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Fall back to shell and still see failure

2015-05-18 Thread Chris Morin
I was hoping that was it, but it turns out that emergency.service is
already of type idle.
I know the console port is very slow on my device. Could this be
caused by some kind of buffer flushing?
This is the output on the console port:
==
[  OK  ] Started Chasfs Flashutil.
[  OK  ] Reached target ChWelcome to emergency mode! After logging in,
type journalctl -xsu
login-4.2#
==

Notice the spaces between the su and the login-4.2.
Also, the string Reached target Chasfs Flashutil doesn't get to complete.

On Mon, May 18, 2015 at 1:35 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 18.05.15 13:23, Chris Morin (chris.mor...@gmail.com) wrote:

 Hi

   During a normal boot on my system, the last service to launch starts
 a special shell which isn't your standard linux shell. Unfortunately,
 before getting to that service, there is a long chain of dependencies
 which have to run. I want to drop to a normal linux shell when any of
 these dependencies fail to be able to jump right into debugging it.

 I set the OnFailure option of the last service to
 emergency.target. This works great. The only issue is that the shell
 appears before systemd has a chance to display which service actually
 failed.

  I can obviously check which service failed with systemctl --failed
 but I'd like to have it displayed during boot as it normally is.

 I'm assuming I can't see the failure message because emergency.service
 grabs control of the console before systemd can print out it's
 message. Is this the case? Is there any way to get what I'm looking
 for?

 Type=idle is for cases like this. See systemd.service(5) for details.

 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 1/3] core: Add LISTEN_NAMES environment variable

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 17:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Mon, May 18, 2015 at 06:01:10PM +0200, Lennart Poettering wrote:
  Being able to attach a name to the fds is hence really useful. logind
  could use this to attach the session identifier to the fds, and would
  hence be able to safely map the fds back to their sessions after
  coming back from a restart...
 Yeah, that makes sense. But currently there's no proposal how to specify
 those identifiers. Would be nice discuss both sides of the proposal at
 the same time.
 
 sd_pid_notify_with_fds() would probably have to be extended to be
 sd_pid_notify_with_fds2(pid_t pid, int unset_environment, const char
 *state, const int *fds, const char* const *names, unsigned n_fds)

Hmm, nah. I think we can avoid adding a new call. Instead we should
explicitly allow non-unique names, and then simply pass the name to
use in a normal sd_notify_with_fds() text field, so that it is applied
to all fds pushed the same way. If you want to send multiple fds with
different ids, then one would do this with multiple
sd_pid_notify_with_fds() invocations.

Example:

sd_pid_notify_with_fds(0, false, FDSTORE=1\nFDNAME=foobar, (int[]) { 
STDIN_FILENO, STDOUT_FILENO }, 2);

This would push stdin and stdout of the client into PID 1 and label
both of them foobar. On next invocation the process would then see:

LISTEN_FDS=2
LISTEN_NAMES=foobar:foobar

 And what about socket units: we could automatically generate identifiers
 like blah.socket-1, foo.socket-1, foo.socket-2 to allow sockets from multiple
 socket files be distinguished. In principle this could be made configurable
 through a new option, but I don't think it's worth the trouble.

I'd add a new option for this:

FileDescriptorName=waldi

would apply to all fds declared with a .socket unit. If you want to
apply distinct names to multiple fds, you should define them in two
seperate .socket units.

Hope that makes sense?

Lennart

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


Re: [systemd-devel] 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 18:31, nusenu (nus...@openmailbox.org) wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
  I'm running into a problem with systemd's hardening features 
  ReadOnlyDirectories and ReadWriteDirectories *when* using them
  in multi-instance service files - temp. workaround was to disable
  them [1].
  
  - - that the service works fine *with* these hardening features
  enabled in a single instance service file - - I'm not using the
  %i placeholder in the ReadWriteDirectories paths
  
  Error message:
  
  Failed at step NAMESPACE spawning /usr/bin/tor: No such file or
  directory service: main process exited, code=exited,
  status=226/NAMESPACE
  
  Any chance you can retry to reproduce this with strace -p1 -o 
  /tmp/log -f -s500 so that we can see what precisely is failing
  there?
 
 looks like it works out of the box now! :)
 
 Since then systemd got updated, but I didn't see anything related in
 debians changelog:
 http://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_215-17_changelog

If it works now I would let it rest. Feel free to raise this here
again should it reappear.

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] Fall back to shell and still see failure

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 15:23, Chris Morin (chris.mor...@gmail.com) wrote:

 I was hoping that was it, but it turns out that emergency.service is
 already of type idle.
 I know the console port is very slow on my device. Could this be
 caused by some kind of buffer flushing?
 This is the output on the console port:
 ==
 [  OK  ] Started Chasfs Flashutil.
 [  OK  ] Reached target ChWelcome to emergency mode! After logging in,
 type journalctl -xsu
 login-4.2#
 ==
 
 Notice the spaces between the su and the login-4.2.
 Also, the string Reached target Chasfs Flashutil doesn't get to
 complete.

We do not delay output forever, to not block boot, after all this is
mostly just cosmetical...

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] [correct PATCH v2] dev-root.device is not active, results in an umount spree

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 16:08, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Change device_found_node() to also create a .device unit if a device is not
 known by udev; this is the case for tentative devices picked up by mountinfo
 (DEVICE_FOUND_MOUNT).  With that we can record the found attribute on the
 unit.

Ah, I see now. This makes sense!

  static int device_setup_unit(Manager *m, struct udev_device *dev, const char 
 *path, bool main) {
  _cleanup_free_ char *e = NULL;
 -const char *sysfs;
 +const char *sysfs = NULL;
  Unit *u = NULL;
  bool delete;
  int r;
  
  assert(m);
 -assert(dev);
  assert(path);
  
 -sysfs = udev_device_get_syspath(dev);
 -if (!sysfs)
 -return 0;
 -
  r = unit_name_from_path(path, .device, e);
  if (r  0)
  return log_error_errno(r, Failed to generate unit name from 
 device path: %m);
  
  u = manager_get_unit(m, e);
  
 +if (dev) {
 +sysfs = udev_device_get_syspath(dev);
 +if (!sysfs)
 +return 0;
 +}

Why move this down? In order to keep the patch small and easy to grok,
can this stay up where it was, but simply be enclosed in the if (dev) {} 
check?

  
 -if (stat(node, st)  0) {
 -if (errno == ENOENT)
 +if (stat(node, st) = 0) {
 +if (!S_ISBLK(st.st_mode)  !S_ISCHR(st.st_mode))
  return 0;
  
 -return log_error_errno(errno, Failed to stat device 
 node file %s: %m, node);
 -}
 -
 -if (!S_ISBLK(st.st_mode)  !S_ISCHR(st.st_mode))
 -return 0;
 +dev = udev_device_new_from_devnum(m-udev, 
 S_ISBLK(st.st_mode) ? 'b' : 'c', st.st_rdev);
 +if (!dev  errno != ENOENT)
 +return log_oom();

Hmm, why are all these errors supposed to be OOM?
udev_device_new_from_devnum sets errno correctly, hence we should just
print what it really is set to with log_error_errno(), unless of
course it is ENOENT.

 -dev = udev_device_new_from_devnum(m-udev, 
 S_ISBLK(st.st_mode) ? 'b' : 'c', st.st_rdev);
 -if (!dev) {
 -if (errno == ENOENT)
 -return 0;
 -
 -return log_oom();
 +} else {
 +if (errno != ENOENT)
 +return log_error_errno(errno, Failed to 
 stat device node file %s: %m, node);

The if else { and if (errn... lines could be merged into one 
else if (errno != ..., no?

 From c18dbd432ecd16c57123b5fc04313d625e8a8e88 Mon Sep 17 00:00:00 2001
 From: Martin Pitt martin.p...@ubuntu.com
 Date: Sun, 17 May 2015 15:17:58 +0200
 Subject: [PATCH 2/3] device: never transition from tentative to dead
 
 Only set a device to state dead if it was previously plugged through udev. 
 We
 must never transition from tentative to dead, as there is no way to be 
 sure
 that this is actually true.
 
 This fixes systemd unmounting everything from a tentative device as soon as
 mountinfo changes.

Not following on this patch: what's the rationale here? your patch
basically means we would never ever clean up tentative devices, if
they once were referenced in mountinfo or /proc/swaps, but no longer
are.

Can you elaborate on what this patch is supposed to achieve? How could
it be problematic to deactivate device units that are neither
announced anywhere in /proc nor in udev?

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] [correct PATCH v2] dev-root.device is not active, results in an umount spree

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 16:08, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Martin Pitt [2015-05-17 15:54 +0200]:
  This fixes the original systemd immediately unmounts my mounts bug,
  but not for very long: If you remount or unmount just one mount on a
  tentative device, mountinfo changes, and device_found_node() now calls
  device_update_found_one() with add == 0. Then
  
  n = add ? (d-found | found) : (d-found  ~found);
  
  would unset the previous DEVICE_FOUND_MOUNT flag, leaving 0 (i. e.
  DEVICE_NOT_FOUND). Thus the previously tentative device would once
  again be set to dead, and systemd would unmount all other mounts
  from it. This must never happen, we simply can't declare tentative
  devices as dead and clean up their unmounts, this only works for
  plugged ones that we know via udev.
 
 Eek, I attached the wrong 0002- patch, sorry about that. The above is
 fixed by the attached patch, please ignore 0002- from the previous
 mail. For completeness I also re-attach 0001- again (unchanged).

Still not getting what the purpose of the 0002 patch is, even in this
revision...

Please elaborate!

 --- a/src/core/device.c
 +++ b/src/core/device.c
 @@ -465,12 +465,13 @@ static void device_update_found_one(Device *d, bool 
 add, DeviceFound found, bool
   * now referenced by the kernel, then we assume the
   * kernel knows it now, and udev might soon too. */
  device_set_state(d, DEVICE_TENTATIVE);
 -else
 -/* If nobody sees the device, or if the device was
 - * previously seen by udev and now is only referenced
 - * from the kernel, then we consider the device is
 +else if (previous  DEVICE_FOUND_UDEV)
 +/* If the device was previously seen by udev and now is only
 + * referenced from the kernel, then we consider the device is
   * gone, the kernel just hasn't noticed it yet. */
  device_set_state(d, DEVICE_DEAD);
 +/* We never move from TENTATIVE to DEAD, as we can only determine 
 this
 + * status update with udev, not with mountinfo */
  }

Devices that show up in /proc/self/mountinfo or /proc/swap, and then
disappear again, without ever showing up in udev, need to be cleaned
up.

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 v4] nvme_id utility + support in 60-persistent-storage.rules

2015-05-18 Thread Per Bergqvist
---
 Makefile.am   |  11 +++
 rules/60-persistent-storage.rules |   5 ++
 src/udev/nvme_id/nvme_id.c| 147 ++
 3 files changed, 163 insertions(+)
 create mode 100644 src/udev/nvme_id/nvme_id.c

diff --git a/Makefile.am b/Makefile.am
index bf04d31..0de0d18 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3904,6 +3904,17 @@ dist_udevrules_DATA += \
rules/60-persistent-v4l.rules
 
 # 
--
+nvme_id_SOURCES = \
+   src/udev/nvme_id/nvme_id.c
+
+nvme_id_LDADD = \
+   libudev-internal.la \
+   libsystemd-shared.la
+
+udevlibexec_PROGRAMS += \
+   nvme_id
+
+# 
--
 accelerometer_SOURCES = \
src/udev/accelerometer/accelerometer.c
 
diff --git a/rules/60-persistent-storage.rules 
b/rules/60-persistent-storage.rules
index 25b44a5..d3368a5 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -42,6 +42,11 @@ KERNEL==cciss*, ENV{DEVTYPE}==disk, 
ENV{ID_SERIAL}!=?*, IMPORT{program}=s
 KERNEL==sd*|sr*|cciss*, ENV{DEVTYPE}==disk, ENV{ID_SERIAL}==?*, 
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}
 KERNEL==sd*|cciss*, ENV{DEVTYPE}==partition, ENV{ID_SERIAL}==?*, 
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n
 
+# NVMe
+KERNEL==nvme*, ENV{ID_SERIAL}!=?*, IMPORT{program}=nvme_id --export 
$devnode
+KERNEL==nvme*, ENV{DEVTYPE}==disk, ENV{ID_SERIAL}==?*, 
SYMLINK+=disk/by-id/nvme-$env{ID_SERIAL}
+KERNEL==nvme*, ENV{DEVTYPE}==partition, ENV{ID_SERIAL}==?*, 
SYMLINK+=disk/by-id/nvme-$env{ID_SERIAL}-part%n
+
 # firewire
 KERNEL==sd*[!0-9]|sr*, ATTRS{ieee1394_id}==?*, 
SYMLINK+=disk/by-id/ieee1394-$attr{ieee1394_id}
 KERNEL==sd*[0-9], ATTRS{ieee1394_id}==?*, 
SYMLINK+=disk/by-id/ieee1394-$attr{ieee1394_id}-part%n
diff --git a/src/udev/nvme_id/nvme_id.c b/src/udev/nvme_id/nvme_id.c
new file mode 100644
index 000..c61b0b8
--- /dev/null
+++ b/src/udev/nvme_id/nvme_id.c
@@ -0,0 +1,147 @@
+/* -*- mode:c; tab-width:8; intent-tabs-mode:nil;  -*-
+ *
+ * nvme_id - reads model/serial/firmware revision numbers from nvme drives
+ *
+ * Copyright (C) 2015 Per Bergqvist p...@bst.lu
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include stdint.h
+#include unistd.h
+#include fcntl.h
+#include ctype.h
+#include string.h
+#include errno.h
+#include getopt.h
+#include linux/nvme.h
+#include sys/ioctl.h
+#include sys/types.h
+#include sys/stat.h
+
+#include libudev.h
+#include libudev-private.h
+#include udev-util.h
+#include log.h
+
+static int nvme_identify(struct udev *udev, int fd, void *buf, size_t buf_len) 
{
+struct nvme_admin_cmd command = {
+.opcode   = nvme_admin_identify,
+.addr = (unsigned long)buf,
+.data_len = buf_len,
+.cdw10= 1 };
+
+if (ioctl(fd, NVME_IOCTL_ADMIN_CMD, command)  0)
+return -errno;
+
+return 0;
+}
+
+int main(int argc, char *argv[]) {
+_cleanup_udev_unref_ struct udev *udev = NULL;
+
+struct nvme_id_ctrl nvme_id_ctrl = {};
+
+char model[sizeof(nvme_id_ctrl.mn)+1];
+char model_enc[4*sizeof(nvme_id_ctrl.mn)+1];
+char serial[sizeof(nvme_id_ctrl.sn)+1];
+char revision[sizeof(nvme_id_ctrl.fr)+1];
+
+const char *node = NULL;
+int export = 0;
+
+_cleanup_close_ int fd = -1;
+
+static const struct option options[] = {
+{ export, no_argument, NULL, 'x' },
+{ help, no_argument, NULL, 'h' },
+{}
+};
+
+log_parse_environment();
+log_open();
+
+udev = udev_new();
+if (udev == NULL)
+return EXIT_SUCCESS;
+
+while (1) {
+int option;
+
+option = getopt_long(argc, argv, xh, options, NULL);
+if (option == -1)
+break;
+
+switch (option) {
+case 'x':
+export = 1;
+break;
+case 'h':
+printf(Usage: nvme_id [--export] [--help] device\n
+ -x,--exportprint values as environment 

Re: [systemd-devel] [PATCH 2/3] sd-daemon: Use LISTEN_NAMES env when available

2015-05-18 Thread Filipe Brandenburger
Hi,

On Mon, May 18, 2015 at 7:26 AM, Krzysztof Opasiak
k.opas...@samsung.com wrote:
 Matching between fds and list of expected paths is done in n^2

I don't think that's the case, because you can just stat() all the
names and fstat() all the fds, then sort both lists on inode numbers
and then traverse both in order matching inode orders on each list, so
it's actually O(n * log n).

Not that it matters that much, I don't expect this scheme to be used
for a very large number of fds/labels...

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


Re: [systemd-devel] [PATCH v3] journalctl: Improve boot ID lookup

2015-05-18 Thread Lennart Poettering
On Fri, 01.05.15 15:15, Jan Janssen (medhe...@web.de) wrote:

 This method should greatly improve offset based lookup, by simply jumping
 from one boot to the next boot. It starts at the journal head to get the
 a boot ID, makes a _BOOT_ID match and then comes from the opposite
 journal direction (tail) to get to the end that boot. After flushing the 
 matches
 and advancing the journal from that exact position, we arrive at the start
 of next boot. Rinse and repeat.
 
 This is faster than the old method of aggregating the full boot listing just
 so we can jump to a specific boot, which can be a real pain on big journals
 just for a mere -b -1 case.
 
 As an additional benefit --list-boots should improve slightly too, because
 it does less seeking.
 
 Note that there can be a change in boot order with this lookup method
 because it will use the order of boots in the journal, not the realtime stamp
 stored in them. That's arguably better, though.
 Another deficiency is that it will get confused with boots interleaving in the
 journal, therefore, it will refuse operation in --merge, --file and
 --directory mode.

I have now applied this. Afterwards I added a couple of (mostly
unrelated) clean-ups to journalctl.

Would be nice if you could verify that things still work as intended!

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/3] sd-daemon: Use LISTEN_NAMES env when available

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 16:26, Krzysztof Opasiak (k.opas...@samsung.com) wrote:

 Please, let's keep this simple: LISTEN_NAMES should only carry actual
 names, nothing else, and let's query the kernel for the actual fd
 types.
 
 I'm not sure if doing stat() to determine how he should interpret content of
 field in env is simpler and easier but of course you are the maintainer so
 you decide how things should be done;)

Well, we have relatively nice wrappers in sd-daemon.h that simplify
these stat() checks...

 There's really no point in storing the types in $LISTEN_NAMEs, since
 this code is no way performance senstive...
 
 Matching between fds and list of expected paths is done in n^2 so it has no
 performance impact as long as number of passed fds isn't big. I know that it
 is usually done only once during service startup but it increase latency
 between event occurrence and it processing.

Well, the n^2 is pretty theoretic, as using fixed paths in the fs is
kinda the antithesis to using a variable number of fds. If people write
daemons that take a variable number of fds they will probably not
expect them to be mapped to fixed names in the fs, but would
discriminate them by other keys, for example whether they are IP or
AF_UNIX sockets, or whether they are stream or datagram, and so
on. But to do such checks we already have the right APIs from the
kernel... 

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] zsh-completion: fix completion of --user services

2015-05-18 Thread Eric Cook
By the time __systemctl is called, --user/--system are shifted out of
`words' by _arguments. This patch queries the array sooner. 

In the case that both --user and --system are on the line when compsys runs,
_sys_service_mgr is set to the latter. Which is seemingly how systemctl behaves.

If neither are on the line, --system is set; for system services to be 
completed.
---
 shell-completion/zsh/_systemctl.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/shell-completion/zsh/_systemctl.in 
b/shell-completion/zsh/_systemctl.in
index 1dc6406..bd5eece 100644
--- a/shell-completion/zsh/_systemctl.in
+++ b/shell-completion/zsh/_systemctl.in
@@ -93,9 +93,7 @@
 
 __systemctl()
 {
-  local -a _modes
-  _modes=(--user --system)
-  systemctl ${words:*_modes} --full --no-legend --no-pager $@
+  systemctl $_sys_service_mgr --full --no-legend --no-pager $@
 }
 
 
@@ -355,6 +353,8 @@ _job_modes() {
 _values -s , ${_modes[@]}
 }
 
+local -a _modes; _modes=(--user --system)
+local _sys_service_mgr=${${words:*_modes}[(R)(${(j.|.)_modes})]:---system}
 _arguments -s \
 {-h,--help}'[Show help]' \
 '--version[Show package version]' \
-- 
2.1.4

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


Re: [systemd-devel] Fwd: [systemd-208][PATCH] Force machined to dispatch messages

2015-05-18 Thread Lennart Poettering
On Wed, 29.04.15 10:06, solganik (solga...@gmail.com) wrote:

 From: Alexander Solganik solga...@gmail.com
 
 Fixes  https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=1172387.
 
 Machined works in the follwing way :

Hmm, is that an issue with current systemd? AFAICs it really isn't as
our event loop works quite differently now.

The upstream mailing list is mostly a forum to discuss bugs in recent
upstream versions, would be cool to check if this is still an issue
with 219 or suchlike.

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] resolved crashes on SIGTERM

2015-05-18 Thread Lennart Poettering
On Mon, 11.05.15 22:00, Cristian Rodríguez (cristian.rodrig...@opensuse.org) 
wrote:

 resolved crashes on SIGTERM with ...

Fixed in git. Please verify.

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] resolved: Assertion 'n 0' failed

2015-05-18 Thread Lennart Poettering
On Sat, 18.04.15 17:38, Kai Krakow (hurikha...@gmail.com) wrote:

 Hello!
 
 Sometimes I'm seeing messages like this:
 
 [ 5780.379921] systemd-resolved[685]: Assertion 'n  0' failed at 
 /var/tmp/portage/sys-apps/systemd-219-
 r2/work/systemd-219/src/resolve/resolved-dns-answer.c:28, function 
 dns_answer_new(). Aborting.
 [ 5780.621865] systemd-resolved[7396]: Assertion 'n  0' failed at 
 /var/tmp/portage/sys-apps/systemd-219-
 r2/work/systemd-219/src/resolve/resolved-dns-answer.c:28, function 
 dns_answer_new(). Aborting.

Should be fixed in git. Please verify!

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] [RFC] exec: introduce StandardOutputFile/StandardErrorFile option

2015-05-18 Thread WaLyong Cho
On 2015년 05월 19일 12:53, Andrei Borzenkov wrote:
 В Tue, 19 May 2015 11:49:45 +0900
 WaLyong Cho walyong@samsung.com пишет:
 
 On 2015년 05월 19일 11:44, WaLyong Cho wrote:
 To redirect stdout/stderr to file add 'file' option to
 StandardOutput/StandardError. And to specify the file path, add
 StandardOutputFile/StandardErrorFile option.
 If only set StandardOutput/StandardError to 'file' without set of
 StandardOutputFile/StandardErrorFile option, then it will be
 redirected to '/dev/null'.

 I think this patch is not complete yet. But I'd like to check you think
 this facility is useful or not.
 
 You should start with describing your use case and what is missing in
 current logging. You can fetch all unit output from journal already.
 
journal is already good logging infrastructure under systemd system. But
the centralized logging is very heavy if there are many logging
messages. I know, we should reduce the log messages. But it is really
hard on short development lifecycle product. We should fix many problems
with many logging message. I think, this can correspond to many of
embedded system. By this reason, in Tizen, dlog is still main logging
system.

I'd never want to blame systemd journal logging. That just does not suit
on our system(Tizen).

Anyway, I think text file logging itself can be useful even if we can
see the log from systemd journal for debugging or many other purpose
such like shell redirecting.

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


Re: [systemd-devel] [RFC] exec: introduce StandardOutputFile/StandardErrorFile option

2015-05-18 Thread WaLyong Cho
On 2015년 05월 19일 11:44, WaLyong Cho wrote:
 To redirect stdout/stderr to file add 'file' option to
 StandardOutput/StandardError. And to specify the file path, add
 StandardOutputFile/StandardErrorFile option.
 If only set StandardOutput/StandardError to 'file' without set of
 StandardOutputFile/StandardErrorFile option, then it will be
 redirected to '/dev/null'.

I think this patch is not complete yet. But I'd like to check you think
this facility is useful or not.
If you agree then I'd like to add
StandardOutputFileMode/StandardErrorFileMode and
StandardOutputFlag/StandardErrorFlag option.
StandardOutputFileMode/StandardErrorFileMode will able to set the file
mode such like 0644 and StandardOutputFlag/StandardErrorFlag will able
to set the file open flag such like append or trunc.

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


Re: [systemd-devel] [RFC] exec: introduce StandardOutputFile/StandardErrorFile option

2015-05-18 Thread Andrei Borzenkov
В Tue, 19 May 2015 11:49:45 +0900
WaLyong Cho walyong@samsung.com пишет:

 On 2015년 05월 19일 11:44, WaLyong Cho wrote:
  To redirect stdout/stderr to file add 'file' option to
  StandardOutput/StandardError. And to specify the file path, add
  StandardOutputFile/StandardErrorFile option.
  If only set StandardOutput/StandardError to 'file' without set of
  StandardOutputFile/StandardErrorFile option, then it will be
  redirected to '/dev/null'.
 
 I think this patch is not complete yet. But I'd like to check you think
 this facility is useful or not.

You should start with describing your use case and what is missing in
current logging. You can fetch all unit output from journal already.

 If you agree then I'd like to add
 StandardOutputFileMode/StandardErrorFileMode and
 StandardOutputFlag/StandardErrorFlag option.
 StandardOutputFileMode/StandardErrorFileMode will able to set the file
 mode such like 0644 and StandardOutputFlag/StandardErrorFlag will able
 to set the file open flag such like append or trunc.
 
 WaLyong
 ___
 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] [RFC] exec: introduce StandardOutputFile/StandardErrorFile option

2015-05-18 Thread WaLyong Cho
To redirect stdout/stderr to file add 'file' option to
StandardOutput/StandardError. And to specify the file path, add
StandardOutputFile/StandardErrorFile option.
If only set StandardOutput/StandardError to 'file' without set of
StandardOutputFile/StandardErrorFile option, then it will be
redirected to '/dev/null'.
---
 src/core/execute.c| 22 ++
 src/core/execute.h|  3 +++
 src/core/load-fragment-gperf.gperf.m4 |  2 ++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/src/core/execute.c b/src/core/execute.c
index 0cca481..a1408e0 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -197,12 +197,12 @@ static bool is_terminal_output(ExecOutput o) {
 o == EXEC_OUTPUT_JOURNAL_AND_CONSOLE;
 }
 
-static int open_null_as(int flags, int nfd) {
+static int open_file_as(int flags, const char *file, int nfd) {
 int fd, r;
 
 assert(nfd = 0);
 
-fd = open(/dev/null, flags|O_NOCTTY);
+fd = open(file ? file : /dev/null, flags|O_NOCTTY);
 if (fd  0)
 return -errno;
 
@@ -215,6 +215,10 @@ static int open_null_as(int flags, int nfd) {
 return r;
 }
 
+static int open_null_as(int flags, int nfd) {
+return open_file_as(flags, /dev/null, nfd);
+}
+
 static int connect_journal_socket(int fd, uid_t uid, gid_t gid) {
 union sockaddr_union sa = {
 .un.sun_family = AF_UNIX,
@@ -420,7 +424,8 @@ static int setup_output(Unit *unit, const ExecContext 
*context, int fileno, int
 return fileno;
 
 /* Duplicate from stdout if possible */
-if (e == o || e == EXEC_OUTPUT_INHERIT)
+if ((e == o || e == EXEC_OUTPUT_INHERIT) 
+e != EXEC_OUTPUT_FILE)
 return dup2(STDOUT_FILENO, fileno)  0 ? -errno : 
fileno;
 
 o = e;
@@ -444,6 +449,9 @@ static int setup_output(Unit *unit, const ExecContext 
*context, int fileno, int
 
 switch (o) {
 
+case EXEC_OUTPUT_FILE:
+return open_file_as(O_WRONLY|O_CREAT|O_APPEND, fileno == 
STDOUT_FILENO ? context-std_output_file : context-std_error_file, fileno);
+
 case EXEC_OUTPUT_NULL:
 return open_null_as(O_WRONLY, fileno);
 
@@ -1967,6 +1975,11 @@ void exec_context_done(ExecContext *c) {
 free(c-root_directory);
 c-root_directory = NULL;
 
+free(c-std_output_file);
+c-std_output_file = NULL;
+free(c-std_error_file);
+c-std_error_file = NULL;
+
 free(c-tty_path);
 c-tty_path = NULL;
 
@@ -2933,7 +2946,8 @@ static const char* const 
exec_output_table[_EXEC_OUTPUT_MAX] = {
 [EXEC_OUTPUT_KMSG_AND_CONSOLE] = kmsg+console,
 [EXEC_OUTPUT_JOURNAL] = journal,
 [EXEC_OUTPUT_JOURNAL_AND_CONSOLE] = journal+console,
-[EXEC_OUTPUT_SOCKET] = socket
+[EXEC_OUTPUT_SOCKET] = socket,
+[EXEC_OUTPUT_FILE] = file
 };
 
 DEFINE_STRING_TABLE_LOOKUP(exec_output, ExecOutput);
diff --git a/src/core/execute.h b/src/core/execute.h
index f5d5c1d..327d711 100644
--- a/src/core/execute.h
+++ b/src/core/execute.h
@@ -59,6 +59,7 @@ typedef enum ExecOutput {
 EXEC_OUTPUT_JOURNAL,
 EXEC_OUTPUT_JOURNAL_AND_CONSOLE,
 EXEC_OUTPUT_SOCKET,
+EXEC_OUTPUT_FILE,
 _EXEC_OUTPUT_MAX,
 _EXEC_OUTPUT_INVALID = -1
 } ExecOutput;
@@ -108,7 +109,9 @@ struct ExecContext {
 
 ExecInput std_input;
 ExecOutput std_output;
+char *std_output_file;
 ExecOutput std_error;
+char *std_error_file;
 
 nsec_t timer_slack_nsec;
 
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index 66c9145..fbcaa95 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -35,7 +35,9 @@ $1.Environment,  config_parse_environ,
   0,
 $1.EnvironmentFile,  config_parse_unit_env_file, 0,
 offsetof($1, exec_context.environment_files)
 $1.StandardInput,config_parse_input, 0,
 offsetof($1, exec_context.std_input)
 $1.StandardOutput,   config_parse_output,0,
 offsetof($1, exec_context.std_output)
+$1.StandardOutputFile,   config_parse_string,0,
 offsetof($1, exec_context.std_output_file)
 $1.StandardError,config_parse_output,0,
 offsetof($1, exec_context.std_error)
+$1.StandardErrorFile,config_parse_string,0,
 offsetof($1, exec_context.std_error_file)
 $1.TTYPath,  config_parse_unit_path_printf,  0,
 offsetof($1, exec_context.tty_path)
 

[systemd-devel] [PATCH v3] hostname: Allow comments in /etc/hostname

2015-05-18 Thread Martin Pitt
Hey Lennart,

Lennart Poettering [2015-05-18 17:12 +0200]:
 This code will result in ENOENT being returned on OOM... That's not right...

Fixed.

 Also consider using strstrip() here.

hostname_cleanup() already filters out whitespace, so I don't think
that's needed?

 Given that this same code is needed twice in different components,
 please add a new call read_etc_hostname() to
 src/shared/hostname-util.c (which I just added to git). It should then
 also do hostname_cleanup() on the name, and thus pretty much replace
 read_and_strip_hostname() entirely in hostname-setup.c.

Done. However, I called the function read_hostname_config() and give
it a path argument. This is mostly so that we can write tests for it,
but maybe one of these days we actually want to use it for other
purposes (reading hostnames from container root fs).

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From ef807f60409b26ab1168cef9df5f5de553e4259c Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Tue, 19 May 2015 07:49:56 +0200
Subject: [PATCH] hostname: Allow comments in /etc/hostname

The hostname(1) tool allows comments in /etc/hostname. Introduce a new
read_hostname_config() in hostname-util which reads a hostname configuration
file like /etc/hostname, strips out comments, whitespace, and cleans the
hostname. Use it in hostname-setup.c and hostnamed and remove duplicated code.

Update hostname manpage. Add tests.

https://launchpad.net/bugs/1053048
---
 man/hostname.xml   | 11 ++-
 src/core/hostname-setup.c  | 24 +--
 src/hostname/hostnamed.c   |  2 +-
 src/shared/hostname-util.c | 33 
 src/shared/hostname-util.h |  2 ++
 src/test/test-util.c   | 47 ++
 6 files changed, 90 insertions(+), 29 deletions(-)

diff --git a/man/hostname.xml b/man/hostname.xml
index 5d3d46d..9688450 100644
--- a/man/hostname.xml
+++ b/man/hostname.xml
@@ -57,11 +57,12 @@
 name of the local system that is set during boot using the
 citerefentryrefentrytitlesethostname/refentrytitlemanvolnum2/manvolnum/citerefentry
 system call. It should contain a single newline-terminated
-hostname string. The hostname may be a free-form string up to 64
-characters in length; however, it is recommended that it consists
-only of 7-bit ASCII lower-case characters and no spaces or dots,
-and limits itself to the format allowed for DNS domain name
-labels, even though this is not a strict requirement./para
+hostname string.  Comments (lines starting with a `#') are ignored.
+The hostname may be a free-form string up to 64 characters in length;
+however, it is recommended that it consists only of 7-bit ASCII lower-case
+characters and no spaces or dots, and limits itself to the format allowed
+for DNS domain name labels, even though this is not a strict
+requirement./para
 
 paraDepending on the operating system, other configuration files
 might be checked for configuration of the hostname as well,
diff --git a/src/core/hostname-setup.c b/src/core/hostname-setup.c
index 217f201..932ddbf 100644
--- a/src/core/hostname-setup.c
+++ b/src/core/hostname-setup.c
@@ -30,35 +30,13 @@
 #include hostname-util.h
 #include hostname-setup.h
 
-static int read_and_strip_hostname(const char *path, char **hn) {
-char *s;
-int r;
-
-assert(path);
-assert(hn);
-
-r = read_one_line_file(path, s);
-if (r  0)
-return r;
-
-hostname_cleanup(s, false);
-
-if (isempty(s)) {
-free(s);
-return -ENOENT;
-}
-
-*hn = s;
-return 0;
-}
-
 int hostname_setup(void) {
 int r;
 _cleanup_free_ char *b = NULL;
 const char *hn;
 bool enoent = false;
 
-r = read_and_strip_hostname(/etc/hostname, b);
+r = read_hostname_config(/etc/hostname, b);
 if (r  0) {
 if (r == -ENOENT)
 enoent = true;
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index ab9ddc7..7ff3a4e 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -96,7 +96,7 @@ static int context_read_data(Context *c) {
 if (!c-data[PROP_HOSTNAME])
 return -ENOMEM;
 
-r = read_one_line_file(/etc/hostname, c-data[PROP_STATIC_HOSTNAME]);
+r = read_hostname_config(/etc/hostname, c-data[PROP_STATIC_HOSTNAME]);
 if (r  0  r != -ENOENT)
 return r;
 
diff --git a/src/shared/hostname-util.c b/src/shared/hostname-util.c
index 2998fdf..e336f26 100644
--- a/src/shared/hostname-util.c
+++ b/src/shared/hostname-util.c
@@ -158,3 +158,36 @@ int sethostname_idempotent(const char *s) {
 
 return 1;
 }
+
+int read_hostname_config(const char *path, char 

Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf

2015-05-18 Thread Lennart Poettering
On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote:

 Hi,
 
 According to the systemd documentation, Requisite disallows starting a
 unit unless the specified unit has been started. This seems to work
 fine, however, if the specified unit has been restarted, this unit will
 be started too!
 This is not what should happen and it doesn't happen with a stop and
 start of the specified unit, so clearly, restart behaves different than
 stop followed by start.

Hmm, I figure this is a bug in systemd.

Whenever you have a unit A declare a Requisite= on a unit B then this
will actually create two dependencies: the actual Requisite= one plus
one in the opposite direction, of type RequiredBy=. Dependencies of
type RequiredBy= are mostly internal to systemd, you cannot
configure them directly (though you can query them using systemctl
show). They are used to track down what to stop when we get
systemctl stop by the user. Now, as a special shortcut we currently map
Requisite= and Required= to a reverse dependency of
RequiredBy=, which is problematichere, since we'll hence make no
distinction between the two when processing systemctl stop.

I figure we need to split up the reverse dep here, and introduce a
seperate RequisiteBy= dependency so that we can avoid this problem...

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-218 - Requisite implies TriggeredByRestartOf

2015-05-18 Thread Lennart Poettering
On Tue, 19.05.15 00:55, Lennart Poettering (lenn...@poettering.net) wrote:

 On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote:
 
  Hi,
  
  According to the systemd documentation, Requisite disallows starting a
  unit unless the specified unit has been started. This seems to work
  fine, however, if the specified unit has been restarted, this unit will
  be started too!
  This is not what should happen and it doesn't happen with a stop and
  start of the specified unit, so clearly, restart behaves different than
  stop followed by start.
 
 Hmm, I figure this is a bug in systemd.
 
 Whenever you have a unit A declare a Requisite= on a unit B then this
 will actually create two dependencies: the actual Requisite= one plus
 one in the opposite direction, of type RequiredBy=. Dependencies of
 type RequiredBy= are mostly internal to systemd, you cannot
 configure them directly (though you can query them using systemctl
 show). They are used to track down what to stop when we get
 systemctl stop by the user. Now, as a special shortcut we currently map
 Requisite= and Required= to a reverse dependency of
 RequiredBy=, which is problematichere, since we'll hence make no
 distinction between the two when processing systemctl stop.
 
 I figure we need to split up the reverse dep here, and introduce a
 seperate RequisiteBy= dependency so that we can avoid this problem...

Fixed in git. Please verify.

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] nspawn: close extra fds before execing init

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 16:45, Alban Crequy (alban.cre...@gmail.com) wrote:

 From: Alban Crequy al...@endocode.com
 
 When systemd-nspawn gets exec*()ed, it inherits the followings file
 descriptors:
 - 0, 1, 2: stdin, stdout, stderr
 - SD_LISTEN_FDS_START, ... SD_LISTEN_FDS_START+LISTEN_FDS: file
   descriptors passed by the system manager (useful for socket
   activation). They are passed to the child process (process leader).
 - extra lock fd: rkt passes a locked directory as an extra fd, so the
   directory remains locked as long as the container is alive.
 
 systemd-nspawn used to close all open fds except 0, 1, 2 and the
 SD_LISTEN_FDS_START..SD_LISTEN_FDS_START+LISTEN_FDS. This patch delays
 the close just before the exec so the nspawn process (parent) keeps the
 extra fds open.

Applied, but made some changes to it before. 

The log_close() + log_open() calls around fdeset_close_others() were
in place only to ensure that the fd used for logging internally by the
logging subsystem is cleanly closed, so that the logging subsystem
knows about it, and doesn't get confused by an abruptly closed
fd. This code of course needed to be moved down, as well.

 ---
  src/nspawn/nspawn.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
 index 8aa7b45..85a7bad 100644
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
 @@ -3998,7 +3998,6 @@ int main(int argc, char *argv[]) {
  goto finish;
  }
  }
 -fdset_close_others(fds);
  log_open();
  
  if (arg_directory) {
 @@ -4509,6 +4508,8 @@ int main(int argc, char *argv[]) {
   * setup, too... */
  (void) barrier_place_and_sync(barrier); /* #5 */
  
 +(void) fdset_close_others(fds);
 +
  if (arg_boot) {
  char **a;
  size_t l;
 -- 
 2.1.4
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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


Re: [systemd-devel] tentative state and unmount on mapper

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 15:59, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,
 
 There have been few discussions about tentative state and unmounting
 and I am experiencing different problem in the same device logic.
 
 I am at 219 + 628c89cc + 496068a8 + 5259bcf6
 
 I have 2 mounts (one is bind mount) on mapper device.
 
 /proc/self/mountinfo:
 47 37 254:0 / /var/spool/storage/SD_DISK
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
 49 37 254:0 / /var/spool/storage/areas/SD_DISK/root
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
 
 systemctl -t device --all | grep map:
 dev-mapper-mmcblk0p1.device   loaded activating tentative 
 /dev/mapper/mmcblk0p1
 
 As soon as I unmount the bind mount, systemd picks up the change in
 /proc/self/mountinfo and changes the tentative device to dead and
 due to that all file systems BindsTo to the device are being
 unmounted. Application which mounted the partitions is not getting a
 chance to unmount the fs.
 
 Should I enumerate available mount units to see if anyone else has
 been mounted on the device that is about to be set as DEVICE_DEAD in
 device_update_found_one()?

The right fix is to ensure you ship the right udev rules for your DM
setup, so that the devices are properly announced by udev. Note that
DM/LVM/... might require compile switches to be specified to enable
proper udev support.

The tentative state is nothing the system should continously leave
devices in. It's a state only used for very short time windows, before
udev is up, or when a pseudo device (like a loopback block device) is
created and immediately mounted. If you have booted up and see a
device in tentative state, then something is really *wrong*.

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] resolved crashes on SIGTERM

2015-05-18 Thread Cristian Rodríguez
On Mon, May 18, 2015 at 6:25 PM, Lennart Poettering
lenn...@poettering.net wrote:

 Fixed in git. Please verify.

It is OK now.. Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] zsh-completion: fix completion of --user services

2015-05-18 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431989131-25145-1-git-send-email-llua%40gmx.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Alexandre Detiste
Le lundi 18 mai 2015, 07:51:18 Igor Bukanov a écrit :
 What I would like to know is what is the exact behavior of systemctl
 daemon-reload. I am writing a service that creates/modifies other
 units by placing files under /run and I would like to know what are
 the limitations. In my case I cannot use a systemd.generator as the
 service depends on a mounted directory.

You could have a generator that first create a one-shot .service
if it's directory is not mounted at boot.

This one-shot .service looks like that:
| [Unit]
| RequiresMountsFor=/directory
| After= 
|
| [Service]
| Type=oneshot
| ExecStart=/bin/sh -c /usr/bin/systemctl daemon-reload ; /usr/bin/systemctl 
try-restart your-service

At it's second run (when called by daemon-reload), the generator does the right 
thing.

The /bin-sh -c ... is needed to encapsulate the try-restart;
if it's not there, as this .service file doesn't exist anymore; the try-restart 
is never run.

It's ugly, but it works reliably.

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


Re: [systemd-devel] [PATCH 6/6] zsh-completion: make the arrays _sys_active_units, _sys_startable_units and _sys_restartable_units local to the completer.

2015-05-18 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431925363-8526-6-git-send-email-llua%40gmx.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH v2 5/6] zsh-completion: removing more pointless forks

2015-05-18 Thread Eric Cook
I seem to have forgot about _systemctl_active_units().

---
 shell-completion/zsh/_systemctl.in | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/shell-completion/zsh/_systemctl.in 
b/shell-completion/zsh/_systemctl.in
index a4db563..d3e7ee2 100644
--- a/shell-completion/zsh/_systemctl.in
+++ b/shell-completion/zsh/_systemctl.in
@@ -105,7 +105,7 @@ _systemctl_all_units()
   if ( [[ ${+_sys_all_units} -eq 0 ]] || _cache_invalid SYS_ALL_UNITS ) 
 ! _retrieve_cache SYS_ALL_UNITS;
   then
-_sys_all_units=( $(__systemctl list-units --all | { while read -r a b; do 
echo -E -  $a; done; }) )
+_sys_all_units=( ${${(f)$(__systemctl list-units --all)}%% *} )
 _store_cache SYS_ALL_UNITS _sys_all_units
   fi
 }
@@ -118,7 +118,7 @@ _systemctl_really_all_units()
   if ( [[ ${+_sys_really_all_units} -eq 0 ]] || _cache_invalid 
SYS_REALLY_ALL_UNITS ) 
 ! _retrieve_cache SYS_REALLY_ALL_UNITS;
   then
-all_unit_files=( $(__systemctl list-unit-files | { while read -r a b; do 
echo -E -  $a; done; }) )
+all_unit_files=( ${${(f)$(__systemctl list-unit-files)}%% *} )
 _systemctl_all_units
 really_all_units=($_sys_all_units $all_unit_files)
 _sys_really_all_units=(${(u)really_all_units})
@@ -146,7 +146,7 @@ _filter_units_by_property() {
 _systemctl_get_template_names() { echo -E - ${^${(M)${(f)$(__systemctl 
list-unit-files)}##*@.[^[:space:]]##}%%@.*}\@ }
 
 
-_systemctl_active_units()  {_sys_active_units=(  $(__systemctl list-units  
| { while read -r a b; do echo -E -  $a; done; }) )}
+_systemctl_active_units()  {_sys_active_units=(  ${${(f)$(__systemctl 
list-units)}%% *} )}
 
 _systemctl_startable_units(){
 _sys_startable_units=( $( _filter_units_by_property ActiveState inactive $(
@@ -259,22 +259,22 @@ done
 # Completion functions for JOBS
 (( $+functions[_systemctl_cancel] )) || _systemctl_cancel()
 {
-  compadd $@ - $(__systemctl list-jobs \
-| cut -d' ' -f1  2/dev/null ) || _message no jobs found
+  compadd $@ - ${${(f)$(__systemctl list-jobs)}%% *} ||
+_message no jobs found
 }
 
 # Completion functions for SNAPSHOTS
 (( $+functions[_systemctl_delete] )) || _systemctl_delete()
 {
-  compadd $@ - $(__systemctl list-units --type snapshot --all \
-| cut -d' ' -f1  2/dev/null ) || _message no snapshots found
+  compadd $@ - ${${(f)$(__systemctl list-units --type snapshot --all)}%% 
*} ||
+_message no snapshots found
 }
 
 # Completion functions for TARGETS
 (( $+functions[_systemctl_set-default] )) || _systemctl_set-default()
 {
-  compadd $@ - $(__systemctl list-unit-files --type target --all \
-| cut -d' ' -f1  2/dev/null ) || _message no targets found
+  compadd $@ - ${${(f)$(__systemctl list-unit-files --type target 
--all)}%% *} ||
+_message no targets found
 }
 
 # Completion functions for ENVS
@@ -287,8 +287,7 @@ for fun in set-environment unset-environment ; do
   suf='-S='
 fi
 
-compadd $@ ${suf} - $(systemctl show-environment \
-  | while read line; do echo  ${line%%\=};done )
+compadd $@ ${suf} - ${${(f)$(systemctl show-environment)}%%=*}
   }
 done
 
@@ -315,7 +314,7 @@ _systemctl_caching_policy()
   oldcache=( $1(mh+1) )
   (( $#oldcache ))  return 0
 
-  _sysunits=($(__systemctl --all | cut -d' ' -f1))
+  _sysunits=(${${(f)$(__systemctl --all)}%% *})
 
   if (( $#_sysunits )); then
 for unit in $_sysunits; do
@@ -342,10 +341,9 @@ _unit_properties() {
   if ( [[ ${+_sys_all_properties} -eq 0 ]] || _cache_invalid 
SYS_ALL_PROPERTIES ) 
 ! _retrieve_cache SYS_ALL_PROPERTIES;
   then
-_sys_all_properties=( $( {__systemctl show --all;
-   @rootlibexecdir@/systemd --dump-configuration-items; } | {
-   while IFS='=' read -r a b; do [ -n $b ]  echo $a; done
-}) )
+_sys_all_properties=( ${${(M)${(f)$(__systemctl show --all;
+@rootlibexecdir@/systemd 
--dump-configuration-items)}##[[:alnum:]]##=*}%%=*}
+)
 _store_cache SYS_ALL_PROPRTIES _sys_all_properties
   fi
   _values -s , ${_sys_all_properties[@]}
-- 
2.1.4

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


Re: [systemd-devel] [PATCH 3/5] test/test-json: Tests for the JSON parser and the tokenizer bugfix

2015-05-18 Thread Pavel Odvody
On Fri, 2015-05-15 at 17:24 +0200, Lennart Poettering wrote:
 On Thu, 07.05.15 17:47, Pavel Odvody (podv...@redhat.com) wrote:
 
  Signed-off-by: Pavel Odvody podv...@redhat.com
  ---
   src/test/test-json.c | 16 
   1 file changed, 16 insertions(+)
  
  diff --git a/src/test/test-json.c b/src/test/test-json.c
  index 24dc700..745eeb0 100644
  --- a/src/test/test-json.c
  +++ b/src/test/test-json.c
  @@ -72,6 +72,17 @@ static void test_one(const char *data, ...) {
   va_end(ap);
   }
   
  +static void test_file(const char *data) {
  +json_variant *v = NULL;
  +int r = json_parse(data, v);
  +
  +assert_se(r == 0);
  +assert_se(v != NULL);
  +assert_se(v-type == JSON_VARIANT_OBJECT);
  +
  +json_variant_unref(v);
  +}
  +
   int main(int argc, char *argv[]) {
   
   test_one(x, -EINVAL);
  @@ -102,5 +113,10 @@ int main(int argc, char *argv[]) {
   test_one(\\\udc00\\udc00\, -EINVAL);
   test_one(\\\ud801\\udc37\, JSON_STRING, \xf0\x90\x90\xb7, 
  JSON_END);
   
  +test_one([1, 2], JSON_ARRAY_OPEN, JSON_INTEGER, 1, JSON_COMMA, 
  JSON_INTEGER, 2, JSON_ARRAY_CLOSE, JSON_END);
  +
  +test_file({\k\: \v\, \foo\: [1, 2, 3], \bar\: {\zap\: 
  null}});
  +test_file({\mutant\: [1, null, \1\, {\1\: [1, \1\]}], 
  \blah\: 1.27});
  +
 
 Any chance you can extend the test to check the structure of the of
 the object parsed for validity here?
 
 Lennart
 

Yes, though I wonder how to write down the test specs.

Something like this for the first test case?

JSON_SCOPE, 
 JSON_KEY, k, JSON_VALUE, v,
 JSON_KEY, foo, JSON_VALUE, 
 JSON_SCOPE, 
  JSON_VALUE, 1, JSON_VALUE, 2, JSON_VALUE, 3,
 JSON_ENDSCOPE, 
 JSON_KEY, bar, JSON_VALUE,
 JSON_SCOPE,
  JSON_KEY, zap, JSON_VALUE, NULL
 JSON_ENDSCOPE.
JSON_ENDSCOPE


-- 
Pavel Odvody podv...@redhat.com
Software Engineer - EMEA ENG Developer Experience
5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno



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


Re: [systemd-devel] [PATCH 1/6] zsh-completion: actually run _filter_units_by_property when creating the arrays _sys_(re|)startable_units

2015-05-18 Thread Zbigniew Jędrzejewski-Szmek
Applied all 6.

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


[systemd-devel] [PATCH] hostname: Allow comments in /etc/hostname

2015-05-18 Thread Martin Pitt
Hello all,

We got a report [1] that systemd doesn't allow comments in
/etc/hostname. If there is a comment, your host name ends up being
# comment. But the original hostname(1) tool documents that comments
are allowed, thus in the sysvinit/upstart world these worked fine.
Earlier versions of cloud-init also produced a comment there.

This currently uses read_full_file() and strv_split_newlines() which
is relatively expensive (although, in most cases there will only be
one line). In cases like these should we rather use an fgets() loop?
Given that host names are limited to 64 bytes (HOST_NAME_MAX) this
could be written more efficiently.

Thanks,

Martin

[1] https://launchpad.net/bugs/1053048
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From 0d5195a617df34abcd200a49c5560f46337e5e74 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Mon, 18 May 2015 11:25:20 +0200
Subject: [PATCH] hostname: Allow comments in /etc/hostname

The hostname(1) tool allows comments in /etc/hostname. For compatibility, allow
them in hostname-setup.c and hostnamed.

https://launchpad.net/bugs/1053048
---
 man/hostname.xml  |  3 ++-
 src/core/hostname-setup.c | 18 --
 src/hostname/hostnamed.c  | 13 -
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/man/hostname.xml b/man/hostname.xml
index 5d3d46d..5c68d3d 100644
--- a/man/hostname.xml
+++ b/man/hostname.xml
@@ -57,7 +57,8 @@
 name of the local system that is set during boot using the
 citerefentryrefentrytitlesethostname/refentrytitlemanvolnum2/manvolnum/citerefentry
 system call. It should contain a single newline-terminated
-hostname string. The hostname may be a free-form string up to 64
+hostname string. Comments (lines starting with a `#') are ignored.
+The hostname may be a free-form string up to 64
 characters in length; however, it is recommended that it consists
 only of 7-bit ASCII lower-case characters and no spaces or dots,
 and limits itself to the format allowed for DNS domain name
diff --git a/src/core/hostname-setup.c b/src/core/hostname-setup.c
index 03b0ce3..72a002a 100644
--- a/src/core/hostname-setup.c
+++ b/src/core/hostname-setup.c
@@ -28,17 +28,31 @@
 #include util.h
 #include log.h
 #include fileio.h
+#include strv.h
 
 static int read_and_strip_hostname(const char *path, char **hn) {
-char *s;
+_cleanup_free_ char *contents = NULL;
+_cleanup_strv_free_ char **lines = NULL;
+char **l;
+char *s = NULL;
 int r;
 
 assert(path);
 assert(hn);
 
-r = read_one_line_file(path, s);
+/* may have comments, ignore them */
+r = read_full_file(/etc/hostname, contents, NULL);
 if (r  0)
 return r;
+lines = strv_split_newlines(contents);
+STRV_FOREACH(l, lines) {
+if (*l[0] != '\0'  *l[0] != '#') {
+s = strdup(*l);
+break;
+}
+}
+if (!s)
+return -ENOENT;
 
 hostname_cleanup(s, false);
 
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index ddf7b8f..24abf58 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -78,6 +78,9 @@ static void context_free(Context *c) {
 static int context_read_data(Context *c) {
 int r;
 struct utsname u;
+_cleanup_free_ char *contents = NULL;
+_cleanup_strv_free_ char **lines = NULL;
+char **l;
 
 assert(c);
 
@@ -95,9 +98,17 @@ static int context_read_data(Context *c) {
 if (!c-data[PROP_HOSTNAME])
 return -ENOMEM;
 
-r = read_one_line_file(/etc/hostname, c-data[PROP_STATIC_HOSTNAME]);
+/* may have comments, ignore them */
+r = read_full_file(/etc/hostname, contents, NULL);
 if (r  0  r != -ENOENT)
 return r;
+lines = strv_split_newlines(contents);
+STRV_FOREACH(l, lines) {
+if (*l[0] != '\0'  *l[0] != '#') {
+c-data[PROP_STATIC_HOSTNAME] = strdup(*l);
+break;
+}
+}
 
 r = parse_env_file(/etc/machine-info, NEWLINE,
PRETTY_HOSTNAME, c-data[PROP_PRETTY_HOSTNAME],
-- 
2.1.4



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


Re: [systemd-devel] [PATCH] hostname: Allow comments in /etc/hostname

2015-05-18 Thread Thomas H.P. Andersen
On Mon, May 18, 2015 at 11:33 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello all,

 We got a report [1] that systemd doesn't allow comments in
 /etc/hostname. If there is a comment, your host name ends up being
 # comment. But the original hostname(1) tool documents that comments
 are allowed, thus in the sysvinit/upstart world these worked fine.
 Earlier versions of cloud-init also produced a comment there.

 This currently uses read_full_file() and strv_split_newlines() which
 is relatively expensive (although, in most cases there will only be
 one line). In cases like these should we rather use an fgets() loop?

I think FOREACH_LINE would make this more readable.

 Given that host names are limited to 64 bytes (HOST_NAME_MAX) this
 could be written more efficiently.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] dev-root.device is not active, results in an umount spree

2015-05-18 Thread Martin Pitt
Andrei Borzenkov [2015-05-14 14:24 +0300]:
 Will it be rebound when device appears? Otherwise any mount that
 happens before udev is started/happens to notice device will not be
 associated with device. Most common case is probably mounts inherited
 from initrd.

Not with the first patch (the one you replied to). The v2 patches do
create the .device right from the start in state tentative (that was
the intention judging by the comments, it just doesn't actually behave
that way) and thus .mounts do get bound to the .devices.

Martin

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


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


Re: [systemd-devel] [PATCH] hostname: Allow comments in /etc/hostname

2015-05-18 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150518093303.GF4392%40piware.de

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-nspawn trouble

2015-05-18 Thread Tom Gundersen
On Sun, May 17, 2015 at 5:30 PM, Michael Biebl mbi...@gmail.com wrote:
 2015-05-15 22:16 GMT+02:00 Tom Gundersen t...@jklm.no:
 on-demand I agree with Lennart that it makes the most sense to simply
 unconditionally load the modules. If this is undesirable the solution
 should be to teach the kernel to auto-load the modules, not to expect
 the admin to figure out that explicit loading is required, IMHO.

 And now we expect that the admin figures out how to disable loading of
 the iptables module, which isn't anymore obvious.

Out of interest, what is the 'regression' users would experience by
having the iptables module loaded? Or is it just about the principle
of not wanting to load a module unless it is actually used?

 What I was suggesting was, that the iptables modules should only be
 loaded on demand, i.e. when the firewalling functionality is actually
 used.

If so, this should be done by the kernel.

 Lennart did argue, that he didn't want to do that within
 networkd, since he didn't want to grant networkd that capability to
 load modules and therefor to load the module unconditionally in PID 1.
 But moving the modules loading out of networkd doesn't mean, it has to
 be done unconditonally, see how we did it for
 udev/kmod-static-nodes.service

Hm, this is all about letting the kernel do the module loading lazily
on-demand, so I'd be all for that, but then the kernel would need to
learn how to do that for iptables first...

Cheers,

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


Re: [systemd-devel] [PATCH] hwdb: Add trackpoint sensitivity setting for Thinkpad X230 tablet

2015-05-18 Thread Zbigniew Jędrzejewski-Szmek
On Mon, May 18, 2015 at 09:54:00AM +0200, Hans de Goede wrote:
 This model needs the trackpoint sensitivity to be boosted to not be too slow
 to be usable, see: https://bugzilla.redhat.com/show_bug.cgi?id=1200717
 ---
  hwdb/70-pointingstick.hwdb | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
 index 72c1a3b..a8c21a2 100644
 --- a/hwdb/70-pointingstick.hwdb
 +++ b/hwdb/70-pointingstick.hwdb
 @@ -87,6 +87,8 @@ evdev:name:*DualPoint 
 Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE6400*:pvr*
  # Lenovo
  #
  
 +# Lenovo Thinkpad X230 tablet
 +evdev:name:TPPS/2 IBM 
 TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX230Tablet:*
  # Lenovo Thinkpad X240
  evdev:name:TPPS/2 IBM 
 TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX240:*
  # Lenovo Thinkpad T440s

Applied.

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


Re: [systemd-devel] [PATCH] buildsys: actually install 70-pointingstick.hwdb

2015-05-18 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431936845-354327-1-git-send-email-grawity%40gmail.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


  1   2   >