date:20141120

On Thu, 20.11.14 10:32, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello all,

heya,

> we just got a bug report [1] about the systemd-nspawn@.service not
> working very well by default:
> 
> First, /var/lib/containers/ does not exist by default. To guard
> against information leaks or hard link attacks by users, this
> directory should be 0700 by default. LXC does the same (/var/lib/lxc
> is 0700 for these reasons). What do you think about adding
> 
> d /var/lib/containers 0700 - - -
> 
> to tmpfiles.d/var.conf? I can also add this to the Debian tmpfiles.d
> file, but it's not really Debian specific.

Sounds resonable. But first, can you elaborate on the reason for 0700
rather than 0755?

> Second, systemd-nspawn@.service uses --link-journal=guest. If you
> don't have a persistant journal, and /var/log/journal/ does not exist,
> then containers fail to start in a rather unfriendly way:
> 
>   Spawning container c on /tmp/c.
>   Press ^] three times within 1s to kill container.
>   Container c failed with error code 1.
> 
> I. e. they don't tell you what's wrong. (SYSTEMD_LOG_LEVEL=debug
> doesn't help at all). But --link-journal=auto isn't right either as
> this then won't create the /var/log/journal/ symlink if you
> do have a persistant journal.
> 
> I don't quite like creating /var/log/journal by default in the
> package, as that would create persistant journals on the host (for the
> guests) even though the admin disabled/didn't enable persistant
> journalling.
> 
>  - Option 1: Change the unit to use "guest" if /var/log/journal
>exists, and not use --link-journal at all if it doesn't. (This
>can't be directly expressed on the nspawn CLI, thus would need some
>Exec=/bin/sh -c 'if [ -d ... ]' shell commands)
> 
>  - Option 2: Make --link-journal=guest nonfatal and just print out a
>warning if /var/log/journal/ does not exist.
> 
>  - Any others?

Hmm, another option would be to introduce --link-journal=try-guest
which is identical to --link-journal=guest except that it becomes a
NOP if /var/log/journal doesn't exist and doesn't even generate an
error or warning. Then, we could change "-j" to mean
--link-journal=try-guest and make that the default to use in the unit
file. I think that would be the best option really.

Lennart

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

[systemd-devel] Hackfest at FOSDEM 2015?

Heya,

Marco D'Itri was asking about a potential hackfest at FOSDEM 2015 in
Brussels. I am all for it, but we'd really need somebody to organize
it, i.e. find a room for us. 

Anyone volunteering for this?

Harald, any chance you can pick this up?

Last time we met at a hackcenter in Brussels which had no heating. It
was frickin' cold and I'd rather not repeat that exact experience,
hence I was wondering if we could try to find a room at the uni
instead.

And when shall we do the hackfest? We could:

a) do it one day before FOSDEM, i.e. Fri 27th Jan 2015
b) do it one day after FOSDEM, i.e. Mon 2nd Feb 2015
c) during FOSDEM?

I think c) would not be a good option given how packed the FOSDEM
schedule anyway is. I have a slight preference for a) given that at
that point people won't be under the effect of Beglian Beer that much
yet.

Opinions?

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] udev: Do not try to start worker if it cannot not recieve events

2014-11-20 Thread David Herrmann

Hi

On Tue, Nov 18, 2014 at 12:17 PM,   wrote:
> From: Philippe De Swert 
>
> udev_monitor_enable_receiving() enables a udev_monitor to recieve
> events. If this fails, the worker here created most likely won't
> recieve any events and will probably not be very useful. So now
> we check if the event recieving is activated before creating the
> new worker.
>
> Found with Coverity: CID#996477
> ---
>  src/udev/udevd.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/udev/udevd.c b/src/udev/udevd.c
> index 3c3de76..d46ddcc 100644
> --- a/src/udev/udevd.c
> +++ b/src/udev/udevd.c
> @@ -183,7 +183,8 @@ static void worker_new(struct event *event) {
>  return;
>  /* allow the main daemon netlink address to send devices to the 
> worker */
>  udev_monitor_allow_unicast_sender(worker_monitor, monitor);
> -udev_monitor_enable_receiving(worker_monitor);
> +if(!udev_monitor_enable_receiving(worker_monitor))
> +return;

udev_monitor_enable_receiving() returns 0 on success, negative error
code on failure. This patch would bail out on success, which is
probably not what you want.

Thanks
David

>  worker = new0(struct worker, 1);
>  if (worker == NULL) {
> --
> 1.8.3.2
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn /dev/pts/multi/user missing with centos7

On Wed, 19.11.14 14:31, Florian Koch (florian.koch1...@gmail.com) wrote:

> Hi,
> 
> i try to  a centos7 (bootstrapped with yum) system with systemd-nspawn
> (systemd-nspawn -D centos7 -b) on opensuse 13.2
> This works basically, but there are some problems:
> 
> 1. remove pam_loginuid from /etc/pam.d/login
> 2. add 
> https://github.com/systemd/systemd/blob/master/units/container-ge...@.service.m4.in
> to the centos system to  get machinectl login workinh
> 3. remove /etc/securetty to get *working* ssh access (without after
> some seconds, a login screen was displayed)
> 
> 
> now i only have this[1] error message which spams the journal, any
> ideas how to solve?

For some reason you appear to have enabled
container-getty@multi-user.service. Which would run a getty on the tty
"multi-user" which doesn't really exist. The templated unit
container-getty@.service really just needs to be there, it doesn't
need to be enabled, and certainly not with "multi-user" for instance
id...

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] plans/roadmap for mdns support in resolved

On Wed, 19.11.14 15:57, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:

> > Note that link-local ipv6 addresses for the name resolution stuff
> > aren't fun to use in Linux right now, as the glibc NSS eats up the
> > scopeid, when a client wants to resolve a hostname and specifies an
> > address family. THis has the effect that resolving to link-local IPv6
> > addresses via "ssh" will just work (since ssh makes no restrictions on
> > the address family when resolving the hostname), but via "ping6" will
> > actually fail (since ping6 specifies AF_INET6 as address family...).
> 
> Hm I need very specific use-case. I have eth0, eth1, dummy0 with ipv6
> addresses in different nets and i need to assign hostname to dummy0
> address, that can be reacheable via eth0 or eth1 =).
> Does this possible?

Both LLMNR and mDNS are strictly per-link, they will not announce IP
addresses that are not on the very link that is used for traffic. That
means if you have eth0 then the hostname will be announced with eth0's
set of addersses on it. If you have eth1, then the hostname will be
announced with only eth1's addresses. And similar for dummy0's
addresses, or any other interface's.

Also note that LLMNR/mDNS only works on interfaces that provide
multicasting, i.e. only those which appear in "ip link" with the
MULTICAST flag set.

I am not sure I grok what you are trying to do, but do note that you
can easily add an additional address to any interface you like,
including the same address to multiple links. This means to make
resolved announce a specific address via LLMNR/mDNS is just a matter
of adding it to the interface via "ip addr add".

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] Hosts without /etc/machine-id on boot

On Wed, 19.11.14 09:45, Didier Roche (didro...@ubuntu.com) wrote:

> Hey,
> 
> Some other topic related to "empty /etc" discussions: when preparing some
> generic distro images, we are have the desire to ensure that all new
> instances will get a different /etc/machine-id file.
> As part of the empty /etc at boot, we first thought that removing
> /etc/machine-id would be sufficient, however, the instance then doesn't
> generate a new machine-id file and complain heavily.
> 
> The new debug message of systemd 216+ helped shading some lights on it: 
> http://cgit.freedesktop.org/systemd/systemd-stable/diff/src/core/machine-id-setup.c?h=v216-stable&id=896050eeb3acbf4106d71204a5173b4984cf1675,
> and adding debug statement in machine_id_setup() from
> src/core/machine-id-setup.c just before "open(etc_machine_id,
> O_RDWR|O_CREAT|O_CLOEXEC|O_NOCTTY, 0444)" explains what happens with
> /proc/mounts:
> 
> [2.119041] systemd[1]: rootfs / rootfs rw
> [2.126775] systemd[1]: 
> /dev/disk/by-uuid/ec8166e5-d5ed-45ec-b350-6cf5773904ac / ext4 
> ro,relatime,data=ordered
> 
> 
> It's clear then that at this stage of the boot process / is readonly.
> The error message (and code) will say that in this case, what is supported
> is an empty /etc/machine-id. After reboot, the consequence is that
> /etc/machine-id is mounted as a tmpfs:

Yes, generation of the machine ID is done very very early at boot,
before we fork off the first non-PID1 userspace process, and hence
before any file system could be remounted writable.

> tmpfs on /etc/machine-id type tmpfs (ro,relatime,size=204948k,mode=755)
> 
> However, this means is that each boot of this instance will result in a
> different machine-id, which isn't what is desired in the empty /etc case
> after a factory reset. I know that there is the utility
> systemd-machine-id-setup that we are running on systemd postinst in
> debian/ubuntu, but that doesn't cover the factory reset one.
> 
> Is there anything obvious that I'm missing to cover that case or anything in
> the pipe?

You have a couple of options:

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

b) pre-initialize the machine ID before you boot, at build time.

c) live with random ids

d) pass in the id to use via $container_uuid (if you use a container
   manager), or via the DMI uuid field (if you use kvm). Then, create
   /etc/machine-id as an empty file, and systemd will initialize it to
   this ID rather than a random one.

Usually, option d) is preferable in cloud setups I guess since it
allows seeding the machine id from some externally used UUID, the way
many container/virtualization managers define one anyway.

I'd be open to add another option on top of this:

e) boot up with /etc read-only and /etc/machine-id empty, so that the
   usualy logic of c) generates a random machine id and overmounts
   /etc/machine-id with it. But then, add a tiny new bootup service,
   that runs shortly after local-fs.target (i.e. the point where /etc/
   has been made writable if it's supposed to be made writable
   according to fstab), and that syncs the random one used so far back
   to disk, so that at the next boot-up it is fully initialized. This
   tiny service should be properly conditioned so that it only runs if
   /etc/machine-id is overmounted and /etc writable
   (i.e. ConditionPathIsMountPoint=/etc/machine-id and
   ConditionPathIsReadWrite=/etc). Special care should be taken so
   that replacement of the mount by the normal file is
   race-free. (This probably means the tool should open a new ount
   namespace temporarily, unmount /etc/machine-id there, update the
   file undearneath and then return to the original mount namespace
   and unmount the file there too, so that at no time the filw is
   invalid).

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

Hope this 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] [BUG] too many rfkill services

On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote:

> Hi.
> 
> Recently, after I had found an update for my BIOS, my desktop started to
> resume properly (before I could only suspend it). Kernel and systemd do
> their jobs fine. But they seem to have problem cooperating.
> 
> For the record I use systemd 215, which means that the issue I describe
> here may have been fixed already.
> 
> After several suspend/resumes systemctl shows more than three dozens of
> rfkill devices even though I've got only one BT and one WLAN.
> 
> --8<---cut here---start->8---
> systemd-rfkill@rfkill0.service   loaded active exitedLoad/Save RF Kill 
> Switch Status of rfkill0
> systemd-rfkill@rfkill1.service   loaded active exitedLoad/Save RF Kill 
> Switch Status of rfkill1
> systemd-rfkill@rfkill2.service  loaded active exitedLoad/Save RF Kill 
> Switch Status of rfkill4
> systemd-rfkill@rfkill3.service  loaded active exitedLoad/Save RF Kill 
> Switch Status of rfkill4
> 
> [...]

This really smells like a kernel bug. systemd gets the device names
via udev from the kernel, hence it's probably some driver bug that
creates these devices incorrectly.

> Nov 18 18:24:02 kotik systemd[1]: Stopping Load/Save RF Kill Switch Status of 
> rfkill9...
> Nov 18 18:24:02 kotik systemd[1]: systemd-rfkill@rfkill9.service: control 
> process exited, code=exited status=1
> Nov 18 18:24:02 kotik systemd[1]: Stopped Load/Save RF Kill Switch Status of 
> rfkill9.
> Nov 18 18:24:02 kotik systemd[1]: Unit systemd-rfkill@rfkill9.service entered 
> failed state.
> --8<---cut here---end--->8---
> 
> The actual issue as I see it is that systemd does not stop and remove
> rfkill services that refer to nonexistent devices.

Yes, we do not flush out information about failed services by default
so that the admin can have a look and figure out what's going on. If
this is not desired, then the binary path in ExecStart= should be
prefixed with "-"...

I think in this case (and by default) we should keep track of errors
though, even if it is annoying. But systemd is really not the place to
work around all possible kernel bugs...

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] [BUG] too many rfkill services

On Thu, 20.11.14 06:40, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> В Tue, 18 Nov 2014 18:37:03 +0100
> Łukasz Stelmach  пишет:
> 
> > 
> > After several suspend/resumes systemctl shows more than three dozens of
> > rfkill devices even though I've got only one BT and one WLAN.
> > 
> > --8<---cut here---start->8---
> > systemd-rfkill@rfkill0.service   loaded active exitedLoad/Save RF Kill 
> > Switch Status of rfkill0
> > systemd-rfkill@rfkill1.service   loaded active exitedLoad/Save RF Kill 
> > Switch Status of rfkill1
> > systemd-rfkill@rfkill2.service  loaded active exitedLoad/Save RF Kill 
> > Switch Status of rfkill4
> > systemd-rfkill@rfkill3.service  loaded active exitedLoad/Save RF Kill 
> > Switch Status of rfkill4
> > 
> 
> I confirm it.
> 
> [...]
> > 
> > The actual issue as I see it is that systemd does not stop and remove
> > rfkill services that refer to nonexistent devices.
> > 
> 
> The problem is, there no easy way to build device name from rfkillN for
> BindsTo. May be additional format specifier that would query udev
> database. Alternatively systemd-rfkill can be changed to accept sysfs
> path directly.

BindsTo= does not cause an exited-but-failed service to be flushed
out. It just stops running services when another service is ending,
that's all.

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/4] util: add functions getting proc status, maps, limits, cgroup

On Wed, 19.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:

> ---
>  src/shared/util.c| 13 +
>  src/shared/util.h|  4 
>  src/test/test-util.c | 17 +
>  3 files changed, 34 insertions(+)
> 
> diff --git a/src/shared/util.c b/src/shared/util.c
> index 0166052..d62d90c 100644
> --- a/src/shared/util.c
> +++ b/src/shared/util.c
> @@ -892,6 +892,19 @@ int get_process_root(pid_t pid, char **root) {
>  return get_process_link_contents(p, root);
>  }
>  
> +#define DEFINE_FN_GET_PROCESS_FULL_FILE(name) \
> +int get_process_##name(pid_t pid, char **name) { \
> +const char *p; \
> +assert(pid >= 0); \
> +p = procfs_file_alloca(pid, #name); \
> +return read_full_file(p, name, /*size*/NULL); \
> +}
> +
> +DEFINE_FN_GET_PROCESS_FULL_FILE(status)
> +DEFINE_FN_GET_PROCESS_FULL_FILE(maps)
> +DEFINE_FN_GET_PROCESS_FULL_FILE(limits)
> +DEFINE_FN_GET_PROCESS_FULL_FILE(cgroup)
> +

Please use functions instead of macros wherever that works. 

Maybe it is sufficient to just provide a single function for all four
cases that takes an extra argument for the file name to read?

Maybe:

int get_process_proc_file(pid_t pid, const char *filename, char **ret)

Or so? Given that the files in question are generally just read and
passed on as is without processing them any further I think it is Ok
to just provide a single "bulk" call that covers all four cases
instead of four individual ones.

Hope that makes sense?

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/4] util: add functions getting proc cwd and root

On Wed, 19.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:

> /proc/[pid]/cwd and /proc/[pid]/root are symliks to corresponding
> directories

Looks good! Applied this one already! Thanks!

> 
> The added functions returns values of that symlinks.
> ---
>  src/shared/util.c| 39 +++
>  src/shared/util.h|  2 ++
>  src/test/test-util.c | 13 -
>  3 files changed, 49 insertions(+), 5 deletions(-)
> 
> diff --git a/src/shared/util.c b/src/shared/util.c
> index eeced47..0166052 100644
> --- a/src/shared/util.c
> +++ b/src/shared/util.c
> @@ -797,19 +797,30 @@ int get_process_capeff(pid_t pid, char **capeff) {
>  return get_status_field(p, "\nCapEff:", capeff);
>  }
>  
> +static int get_process_link_contents(const char *proc_file, char **name) {
> +int r;
> +
> +assert(proc_file);
> +assert(name);
> +
> +r = readlink_malloc(proc_file, name);
> +if (r < 0)
> +return r == -ENOENT ? -ESRCH : r;
> +
> +return 0;
> +}
> +
>  int get_process_exe(pid_t pid, char **name) {
>  const char *p;
>  char *d;
>  int r;
>  
>  assert(pid >= 0);
> -assert(name);
>  
>  p = procfs_file_alloca(pid, "exe");
> -
> -r = readlink_malloc(p, name);
> +r = get_process_link_contents(p, name);
>  if (r < 0)
> -return r == -ENOENT ? -ESRCH : r;
> +return r;
>  
>  d = endswith(*name, " (deleted)");
>  if (d)
> @@ -861,6 +872,26 @@ int get_process_gid(pid_t pid, gid_t *gid) {
>  return get_process_id(pid, "Gid:", gid);
>  }
>  
> +int get_process_cwd(pid_t pid, char **cwd) {
> +const char *p;
> +
> +assert(pid >= 0);
> +
> +p = procfs_file_alloca(pid, "cwd");
> +
> +return get_process_link_contents(p, cwd);
> +}
> +
> +int get_process_root(pid_t pid, char **root) {
> +const char *p;
> +
> +assert(pid >= 0);
> +
> +p = procfs_file_alloca(pid, "root");
> +
> +return get_process_link_contents(p, root);
> +}
> +
>  char *strnappend(const char *s, const char *suffix, size_t b) {
>  size_t a;
>  char *r;
> diff --git a/src/shared/util.h b/src/shared/util.h
> index 835fee4..fc59481 100644
> --- a/src/shared/util.h
> +++ b/src/shared/util.h
> @@ -295,6 +295,8 @@ int get_process_exe(pid_t pid, char **name);
>  int get_process_uid(pid_t pid, uid_t *uid);
>  int get_process_gid(pid_t pid, gid_t *gid);
>  int get_process_capeff(pid_t pid, char **capeff);
> +int get_process_cwd(pid_t pid, char **cwd);
> +int get_process_root(pid_t pid, char **root);
>  
>  char hexchar(int x) _const_;
>  int unhexchar(char c) _const_;
> diff --git a/src/test/test-util.c b/src/test/test-util.c
> index 01b0192..7bf8ff6 100644
> --- a/src/test/test-util.c
> +++ b/src/test/test-util.c
> @@ -490,13 +490,14 @@ static void test_u64log2(void) {
>  
>  static void test_get_process_comm(void) {
>  struct stat st;
> -_cleanup_free_ char *a = NULL, *c = NULL, *d = NULL, *f = NULL, *i = 
> NULL;
> +_cleanup_free_ char *a = NULL, *c = NULL, *d = NULL, *f = NULL, *i = 
> NULL, *cwd = NULL, *root = NULL;
>  unsigned long long b;
>  pid_t e;
>  uid_t u;
>  gid_t g;
>  dev_t h;
>  int r;
> +pid_t me;
>  
>  if (stat("/proc/1/comm", &st) == 0) {
>  assert_se(get_process_comm(1, &a) >= 0);
> @@ -532,6 +533,16 @@ static void test_get_process_comm(void) {
>  log_info("pid1 gid: "GID_FMT, g);
>  assert_se(g == 0);
>  
> +me = getpid();
> +
> +r = get_process_cwd(me, &cwd);
> +assert_se(r >= 0 || r == -EACCES);
> +log_info("pid1 cwd: '%s'", cwd);
> +
> +r = get_process_root(me, &root);
> +assert_se(r >= 0 || r == -EACCES);
> +log_info("pid1 root: '%s'", root);
> +
>  assert_se(get_ctty_devnr(1, &h) == -ENOENT);
>  
>  getenv_for_pid(1, "PATH", &i);
> -- 
> 1.8.3.1
> 
> ___
> 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] [PATCH 3/4] util: add function getting proc environ

On Wed, 19.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:

>  
> +int get_process_environ(pid_t pid, char **environ) {

If this is really just about pushing this into the journal: the
journal is actually binary safe, we could just drop the data there
without escaping it. That said, it certainly doesn't help readability,
and processability if fields are unnecesarily binary, hence it's
probably a good idea to escape things as your patch does it.

> +_cleanup_fclose_ FILE *f = NULL;
> +_cleanup_free_ char *outcome = NULL;
> +int c;
> +const char *p;
> +char escaped[4];
> +size_t allocated = 0, sz = 0, escaped_len = 0;
> +
> +assert(pid >= 0);
> +assert(environ);
> +
> +p = procfs_file_alloca(pid, "environ");
> +
> +f = fopen(p, "re");
> +if (!f)
> +return -errno;
> +
> +while ((c = fgetc(f)) != EOF) {
> +if (c == '\0') {
> +escaped[0] = '\n';
> +escaped_len = 1;
> +}
> +else
> +escaped_len = cescape_char(c, escaped);
> +
> +if (!GREEDY_REALLOC(outcome, allocated, sz + escaped_len + 
> 1))
> +return -ENOMEM;
> +
> +memcpy(outcome + sz, escaped, escaped_len);
> +sz += escaped_len;
> +}

I'd probably just always prealloc 5 chars more in each iteration and
then use cescape_char() directly on the resulting buffer instead of
copying things into a temporary buffer first, and then reallocating to
the precise length and then copying it over to the real buffer.

It not only makes the code a bit quicker but also is most likely a bit
wiser resource-wise since the extra copy and realloc is usually more
expensive than a few bytes of memory added extra.

Otherwise looks great!

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] Improving systemd-nspawn@.service (container dir/nonpersistant journal)

2014-11-20 Thread Martin Pitt

Hey,

Lennart Poettering [2014-11-20 12:29 +0100]:
> > d /var/lib/containers 0700 - - -
> > 
> > to tmpfiles.d/var.conf? I can also add this to the Debian tmpfiles.d
> > file, but it's not really Debian specific.
> 
> Sounds resonable. But first, can you elaborate on the reason for 0700
> rather than 0755?

Mostly so that users on the host can't call suid root binaries in the
container. If containers are restricted with selinux/apparmor or
started as user (both happens in Ubuntu for LXC, for example) this
would open a way to escalate root privs in a container into root privs
on the host. https://launchpad.net/bugs/1244635 has the
details/history of this.

I know that upstream systemd doesn't ship AppArmor/SELinux profiles,
and thus your stanza is that containers are inherently insecure. So if
you aren't convinced by the calling of suid root binaries, 0755 is
also ok for upstream, or we just skip this part entirely (it's really
just a small detail, after all).

Patch attached.

> > Second, systemd-nspawn@.service uses --link-journal=guest. If you
> > don't have a persistant journal, and /var/log/journal/ does not exist,
> > then containers fail to start in a rather unfriendly way:
>
> Hmm, another option would be to introduce --link-journal=try-guest
> which is identical to --link-journal=guest except that it becomes a
> NOP if /var/log/journal doesn't exist and doesn't even generate an
> error or warning. Then, we could change "-j" to mean
> --link-journal=try-guest and make that the default to use in the unit
> file. I think that would be the best option really.

Excellent, sounds good! Patch attached. I went with a new
link_journal_try flag instead of introducing
LINK_TRY_HOST/LINK_TRY_GUEST, as that would make a lot of if
statements more unwieldy, and it's easy to forget to always check for
both cases. But if you prefer that, I'm happy to change the patch
accordingly.

Thanks,

Martin

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

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

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

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

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

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

diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index b3a2d32..75db65e 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -439,7 +439,9 @@
 versa). Takes one of
 no,
 host,
+try-host,
 guest,
+try-guest,
 auto. If
 no, the journal is
 not linked. If host,
@@ -453,8 +455,11 @@
 guest file system (beneath
 /var/log/journal/machine-id)
 and the subdirectory is symlinked into the host
-at the same location. If
-auto (the default),
+at the same location. try-host
+and try-guest do the same
+but do not fail if the host does not have
+persistant journalling enabled.
+If auto (the default),
 and the right subdirectory of
 /var/log/journal
 exists, it will be bind mounted
@@ -473,7 +478,7 @@
 -j
 
 Equivalent to
---link-journal=guest.
+--link-journal=try-guest.
 
 
 
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index c2311b3..5a80cf2 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -124,6 +124,7 @@ static bool arg

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

2014-11-20 Thread Michael Biebl

2014-11-20 14:17 GMT+01:00 Lennart Poettering :
> On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote:
>
>> Hi.
>>
>> Recently, after I had found an update for my BIOS, my desktop started to
>> resume properly (before I could only suspend it). Kernel and systemd do
>> their jobs fine. But they seem to have problem cooperating.
>>
>> For the record I use systemd 215, which means that the issue I describe
>> here may have been fixed already.
>>
>> After several suspend/resumes systemctl shows more than three dozens of
>> rfkill devices even though I've got only one BT and one WLAN.
>>
>> --8<---cut here---start->8---
>> systemd-rfkill@rfkill0.service   loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill0
>> systemd-rfkill@rfkill1.service   loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill1
>> systemd-rfkill@rfkill2.service  loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill4
>> systemd-rfkill@rfkill3.service  loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill4
>>
>> [...]
>
> This really smells like a kernel bug. systemd gets the device names
> via udev from the kernel, hence it's probably some driver bug that
> creates these devices incorrectly.
>
>> Nov 18 18:24:02 kotik systemd[1]: Stopping Load/Save RF Kill Switch Status 
>> of rfkill9...
>> Nov 18 18:24:02 kotik systemd[1]: systemd-rfkill@rfkill9.service: control 
>> process exited, code=exited status=1
>> Nov 18 18:24:02 kotik systemd[1]: Stopped Load/Save RF Kill Switch Status of 
>> rfkill9.
>> Nov 18 18:24:02 kotik systemd[1]: Unit systemd-rfkill@rfkill9.service 
>> entered failed state.
>> --8<---cut here---end--->8---
>>
>> The actual issue as I see it is that systemd does not stop and remove
>> rfkill services that refer to nonexistent devices.
>
> Yes, we do not flush out information about failed services by default
> so that the admin can have a look and figure out what's going on. If
> this is not desired, then the binary path in ExecStart= should be
> prefixed with "-"...
>
> I think in this case (and by default) we should keep track of errors
> though, even if it is annoying. But systemd is really not the place to
> work around all possible kernel bugs...

I had some rather "interesting" experience with the rfkill service as well.
See [1]. Basically, running rfkill on one device, made the other device go away.
Since there is a race, systemd-rfkill failed for that device, leading
to an error message on every boot.
A BindsTo= would probably help here as well.

So while we are at that topic, would be great to have some input on [1].

Michael

[1] https://bugs.freedesktop.org/show_bug.cgi?id=83730
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] dbus: return non-zero return value in the case that prefix won't match

2014-11-20 Thread Lukas Nykryn

strv_extend returns 0 in the case of success which means that
else if (bus_track_deserialize_item(&m->deserialized_subscribed, l) == 0)
log_warning("Unknown serialization item '%s'", l);
will be printed when value is added correctly.
---
 src/core/dbus.c| 2 +-
 src/core/manager.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/core/dbus.c b/src/core/dbus.c
index 9cb198a..ec1c0d4 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -1180,7 +1180,7 @@ int bus_track_deserialize_item(char ***l, const char 
*line) {
 
 e = startswith(line, "subscribed=");
 if (!e)
-return 0;
+return -EINVAL;
 
 return strv_extend(l, e);
 }
diff --git a/src/core/manager.c b/src/core/manager.c
index 2bc1058..7abc8a9 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2408,7 +2408,7 @@ int manager_deserialize(Manager *m, FILE *f, FDSet *fds) {
 m->kdbus_fd = fdset_remove(fds, fd);
 }
 
-} else if 
(bus_track_deserialize_item(&m->deserialized_subscribed, l) == 0)
+} else if 
(bus_track_deserialize_item(&m->deserialized_subscribed, l) < 0)
 log_warning("Unknown serialization item '%s'", l);
 }
 
-- 
1.8.3.1

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

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

2014-11-20 Thread Didier Roche

Le 20/11/2014 13:45, Lennart Poettering a écrit :

On Wed, 19.11.14 09:45, Didier Roche (didro...@ubuntu.com) wrote:

Hey,

Some other topic related to "empty /etc" discussions: when preparing some
generic distro images, we are have the desire to ensure that all new
instances will get a different /etc/machine-id file.
As part of the empty /etc at boot, we first thought that removing
/etc/machine-id would be sufficient, however, the instance then doesn't
generate a new machine-id file and complain heavily.

The new debug message of systemd 216+ helped shading some lights on it:
http://cgit.freedesktop.org/systemd/systemd-stable/diff/src/core/machine-id-setup.c?h=v216-stable&id=896050eeb3acbf4106d71204a5173b4984cf1675,
and adding debug statement in machine_id_setup() from
src/core/machine-id-setup.c just before "open(etc_machine_id,
O_RDWR|O_CREAT|O_CLOEXEC|O_NOCTTY, 0444)" explains what happens with
/proc/mounts:

[2.119041] systemd[1]: rootfs / rootfs rw
[2.126775] systemd[1]:
/dev/disk/by-uuid/ec8166e5-d5ed-45ec-b350-6cf5773904ac / ext4
ro,relatime,data=ordered

It's clear then that at this stage of the boot process / is readonly.
The error message (and code) will say that in this case, what is supported
is an empty /etc/machine-id. After reboot, the consequence is that
/etc/machine-id is mounted as a tmpfs:

Yes, generation of the machine ID is done very very early at boot,
before we fork off the first non-PID1 userspace process, and hence
before any file system could be remounted writable.

That makes sense.

tmpfs on /etc/machine-id type tmpfs (ro,relatime,size=204948k,mode=755)

However, this means is that each boot of this instance will result in a
different machine-id, which isn't what is desired in the empty /etc case
after a factory reset. I know that there is the utility
systemd-machine-id-setup that we are running on systemd postinst in
debian/ubuntu, but that doesn't cover the factory reset one.

Is there anything obvious that I'm missing to cover that case or anything in
the pipe?

You have a couple of options:

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

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

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

b) pre-initialize the machine ID before you boot, at build time.

c) live with random ids

Those 2 are actually nice features, but not applying with a machine if
we factory reset it with an empty /etc.

d) pass in the id to use via $container_uuid (if you use a container
manager), or via the DMI uuid field (if you use kvm). Then, create
/etc/machine-id as an empty file, and systemd will initialize it to
this ID rather than a random one.

Usually, option d) is preferable in cloud setups I guess since it
allows seeding the machine id from some externally used UUID, the way
many container/virtualization managers define one anyway.

Fully agreed (not the case I showed up here, but nice to know we can
pass pre-generated uuid to containers/vms).

I'd be open to add another option on top of this:

e) boot up with /etc read-only and /etc/machine-id empty, so that the
usualy logic of c) generates a random machine id and overmounts
/etc/machine-id with it. But then, add a tiny new bootup service,
that runs shortly after local-fs.target (i.e. the point where /etc/
has been made writable if it's supposed to be made writable
according to fstab), and that syncs the random one used so far back
to disk, so that at the next boot-up it is fully initialized. This
tiny service should be properly conditioned so that it only runs if
/etc/machine-id is overmounted and /etc writable
(i.e. ConditionPathIsMountPoint=/etc/machine-id and
ConditionPathIsReadWrite=/etc). Special care should be taken so
that replacement of the mount by the normal file is
race-free. (This probably means the tool should open a new ount
namespace temporarily, unmount /etc/machine-id there, update the
file undearneath and then return to the original mount namespace
and unmount the file there too, so that at no time the filw is
invalid).

The guarantee with /etc/machine-id is really that it is valid at *any*
time, in early boot and late boot and all the time in between.
I think I will go that path which is an interesting one and mapping some

[systemd-devel] newer systemd for rhel7/centos7

2014-11-20 Thread Lukáš Nykrýn

Hi,

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

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

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

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

Lukas

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

Re: [systemd-devel] Hackfest at FOSDEM 2015?

2014-11-20 Thread Colin Guthrie

Lennart Poettering wrote on 20/11/14 11:44:
> Heya,
> 
> Marco D'Itri was asking about a potential hackfest at FOSDEM 2015 in
> Brussels. I am all for it, but we'd really need somebody to organize
> it, i.e. find a room for us. 
> 
> Anyone volunteering for this?
> 
> Harald, any chance you can pick this up?
> 
> Last time we met at a hackcenter in Brussels which had no heating. It
> was frickin' cold and I'd rather not repeat that exact experience,
> hence I was wondering if we could try to find a room at the uni
> instead.
> 
> And when shall we do the hackfest? We could:
> 
> a) do it one day before FOSDEM, i.e. Fri 27th Jan 2015
> b) do it one day after FOSDEM, i.e. Mon 2nd Feb 2015
> c) during FOSDEM?
> 
> I think c) would not be a good option given how packed the FOSDEM
> schedule anyway is. I have a slight preference for a) given that at
> that point people won't be under the effect of Beglian Beer that much
> yet.

I'm open to either, with a very slight preference for after FOSDEM, but
before works too.

Getting dates soon would be nice tho', so I can book flights and book
accommodation etc.

Cheers

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] Hackfest at FOSDEM 2015?

2014-11-20 Thread Simon Peeters

> Brussels. I am all for it, but we'd really need somebody to organize
> it, i.e. find a room for us.
>
> Anyone volunteering for this?
If nobody else steps up, I might do it, but I do have a very tight
schedule currently, so I would rather have someone else do it.
If somebody else does this and for some practical reasons a Belgian is
needed (they ask for a Belgian ID, keys have to be picked up in
advance,...) I am willing to help.

> I was wondering if we could try to find a room at the uni instead.
I think this could be possible, but I'm not sure about network
connectivity outside of FOSDEM (the network gets set up on Friday, and
torn down Sunday evening, so we wouldn't be able to rely on that).
Belgian universities (well at least the one in Ghent) tend to be very
careful about that since their provider (belnet) requires that it is
only used for research&education.
I also don't know whether we should do this via the FOSDEM organisers,
or contact ULB[1] directly. (In case of the later, the person doing
this might want to brush up his/her French)

> And when shall we do the hackfest? We could:
>
> a) do it one day before FOSDEM, i.e. Fri 27th Jan 2015
> b) do it one day after FOSDEM, i.e. Mon 2nd Feb 2015
> c) during FOSDEM?

I am in favour of a because I want to attend configmanagementcamp[2] on Monday.
(but b would allow me to volunteer for the set-up on Friday, so both
have advantages)

Greetings/Hilsen/Groeten

Simon


[1] just as a sidenote: there are 2 universities in Brussels: a Dutch
speaking, the VUB (NOT the one where FOSDEM takes place) and a French
speaking, the ULB (the one where FOSDEM takes place). Both mean "Free
University of Brussels", but are completely unrelated.
[2] http://cfgmgmtcamp.eu/ which takes place at my school.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hackfest at FOSDEM 2015?

2014-11-20 Thread Greg KH

On Thu, Nov 20, 2014 at 12:44:43PM +0100, Lennart Poettering wrote:
> Heya,
> 
> Marco D'Itri was asking about a potential hackfest at FOSDEM 2015 in
> Brussels. I am all for it, but we'd really need somebody to organize
> it, i.e. find a room for us. 
> 
> Anyone volunteering for this?
> 
> Harald, any chance you can pick this up?
> 
> Last time we met at a hackcenter in Brussels which had no heating. It
> was frickin' cold and I'd rather not repeat that exact experience,
> hence I was wondering if we could try to find a room at the uni
> instead.
> 
> And when shall we do the hackfest? We could:
> 
> a) do it one day before FOSDEM, i.e. Fri 27th Jan 2015

You mean "Friday, January 30, 2015", here, right?

I vote for this date, if for only the beer influnce...

As for location, what about the shared-hacking space we used two years
ago?

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

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

2014-11-20 Thread Greg KH

On Thu, Nov 20, 2014 at 12:05:23PM +0300, Andrei Borzenkov wrote:
> On Thu, Nov 20, 2014 at 11:53 AM, Mantas Mikulėnas  wrote:
> > On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov 
> > wrote:
> >>
> >> The problem is, there no easy way to build device name from rfkillN for
> >> BindsTo. May be additional format specifier that would query udev
> >> database. Alternatively systemd-rfkill can be changed to accept sysfs
> >> path directly.
> >
> >
> > You sure about that? /sys/class/rfkill/%i should work fine...
> >
> 
> I'm not before my notebook, but I'm pretty sure this device is not
> present in the "systemctl -t device" list. Actually I do not think any
> /sys/class alias is present at all.

Then something is wrong with your kernel :(

You should have something like /sys/class/rfkill/rfkill0 and such in
there.

thanks,

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

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



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

Hi,

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

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

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

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

Lukas


Wont you break your RHEL support if you run this?

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

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



Am 20.11.2014 um 19:10 schrieb Jóhann B. Guðmundsson:

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

Hi,

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

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

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

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

Lukas


Wont you break your RHEL support if you run this?


given that the OP has a @redhat.com address i guess the intention is to 
test and prepare a official RHEL update over the time


reading "and for us it is a backporting nightmare" makes that more than 
a guess




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

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



On 11/20/2014 06:12 PM, Reindl Harald wrote:


Am 20.11.2014 um 19:10 schrieb Jóhann B. Guðmundsson:

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

Hi,

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

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

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

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

Lukas


Wont you break your RHEL support if you run this?


given that the OP has a @redhat.com address i guess the intention is 
to test and prepare a official RHEL update over the time


reading "and for us it is a backporting nightmare" makes that more 
than a guess


That's a given and not what I asked.

Red Hat should be supplying it's own QA resources to test it's own and 
upcoming RHEL product releases instead of be reaching out to the 
community *to do it for them*  and leach of it + he does not mention, if 
you intend on testing this on RHEL if it breaks your RHEL support 
contract or not ( which most likely it does ) hence the question.


JBG



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

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



Am 20.11.2014 um 19:22 schrieb Jóhann B. Guðmundsson:

On 11/20/2014 06:12 PM, Reindl Harald wrote:

Am 20.11.2014 um 19:10 schrieb Jóhann B. Guðmundsson:

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

Hi,

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

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

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

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

Lukas


Wont you break your RHEL support if you run this?


given that the OP has a @redhat.com address i guess the intention is
to test and prepare a official RHEL update over the time

reading "and for us it is a backporting nightmare" makes that more
than a guess


That's a given and not what I asked.


but that's very likely true

what you asked don't matter since this is a *developer list* and so no 
place where a RHEL customer with support is expected to jump blindly and 
try unsupported packages



Red Hat should be supplying it's own QA resources to test it's own and
upcoming RHEL product releases instead of be reaching out to the
community *to do it for them*  and leach of it + he does not mention, if
you intend on testing this on RHEL if it breaks your RHEL support
contract or not ( which most likely it does ) hence the question


no idea from where your personal vendetta against Redhat is coming (not 
only in that response, over years, everywhere) but why don't you just 
ignore anything containing the company name?




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

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

2014-11-20 Thread Lukasz Stelmach

On 20.11.2014 18:57, Greg KH wrote:
> On Thu, Nov 20, 2014 at 12:05:23PM +0300, Andrei Borzenkov wrote:
>> On Thu, Nov 20, 2014 at 11:53 AM, Mantas Mikulėnas  wrote:
>>> On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov 
>>> wrote:

 The problem is, there no easy way to build device name from rfkillN for
 BindsTo. May be additional format specifier that would query udev
 database. Alternatively systemd-rfkill can be changed to accept sysfs
 path directly.
>>>
>>> You sure about that? /sys/class/rfkill/%i should work fine...
>>
>> I'm not before my notebook, but I'm pretty sure this device is not
>> present in the "systemctl -t device" list. Actually I do not think any
>> /sys/class alias is present at all.
> 
> Then something is wrong with your kernel :(
> 
> You should have something like /sys/class/rfkill/rfkill0 and such in
> there.

For the record:

$ ls /sys/class/rfkill/
rfkill41  rfkill42
$ systemctl -t device | grep rfkill
sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device
 
sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device


-- 
Było mi bardzo miło.   Twoje oczy lubią mnie
>Łukasz< i to mnie zgubi  (c)SNL

REKLAMA: http://ars-fabrica.eu/ sklep z rękodziełem



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

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



On 11/20/2014 06:27 PM, Reindl Harald wrote:



what you asked don't matter since this is a *developer list* and so no 
place where a RHEL customer with support is expected to jump blindly 
and try unsupported packages


Right which makes this not the place to ask for this either. ( should be 
asked in downstream community's surrounding RHEL and it's clones )





Red Hat should be supplying it's own QA resources to test it's own and
upcoming RHEL product releases instead of be reaching out to the
community *to do it for them*  and leach of it + he does not mention, if
you intend on testing this on RHEL if it breaks your RHEL support
contract or not ( which most likely it does ) hence the question


no idea from where your personal vendetta against Redhat is coming 
(not only in that response, over years, everywhere) but why don't you 
just ignore anything containing the company name?


My personal vendetta against Red Hat spurs from their attitude and 
repeated misuse of contributors time in projects like Fedora but that's 
irrelevant here.


Encase you somehow missed it, the systemd project has been heavinly 
criticized for being a Red Hat only project and it's members heavily 
flamed publicly due to that and it makes no wonder if people get that 
notion when RHEL employees treat it like internal company project.


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

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



Am 20.11.2014 um 19:41 schrieb Jóhann B. Guðmundsson:

On 11/20/2014 06:27 PM, Reindl Harald wrote:



what you asked don't matter since this is a *developer list* and so no
place where a RHEL customer with support is expected to jump blindly
and try unsupported packages


Right which makes this not the place to ask for this either. ( should be
asked in downstream community's surrounding RHEL and it's clones )


* if "downstream" is oudated you shout
* if "downstream" tries to change that you shout
* if a user from downstream asks something you shout


Red Hat should be supplying it's own QA resources to test it's own and
upcoming RHEL product releases instead of be reaching out to the
community *to do it for them*  and leach of it + he does not mention, if
you intend on testing this on RHEL if it breaks your RHEL support
contract or not ( which most likely it does ) hence the question


no idea from where your personal vendetta against Redhat is coming
(not only in that response, over years, everywhere) but why don't you
just ignore anything containing the company name?


My personal vendetta against Red Hat spurs from their attitude and
repeated misuse of contributors time in projects like Fedora but that's
irrelevant here.


your definition of "misuse" is just broken


Encase you somehow missed it, the systemd project has been heavinly
criticized for being a Red Hat only project


not only - also for be hostile in responses to anybody asking something 
without provide code - as you do here again



and it's members heavily
flamed publicly due to that and it makes no wonder if people get that
notion when RHEL employees treat it like internal company project


by just asking upstream developers to have a look?
really?

nobody did "treat" anything!
somebody asked and if you don#t care - well - then don't care

but at the same context hestitate if "downstream" does something not in 
*your* intention later and shout "why did they not ask us before XXX"




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

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

2014-11-20 Thread Cristian Rodríguez

El 20/11/14 a las 15:40, Lukasz Stelmach escribió:

> 
> $ ls /sys/class/rfkill/
> rfkill41  rfkill42
> $ systemctl -t device | grep rfkill
> sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device
>  
> sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device
> 

huh.. so the kernel does not preserve the device number on resume and
recreate new ones? Im not sure but that sounds like a kernel bug...


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

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

2014-11-20 Thread Lukasz Stelmach

On 20.11.2014 14:17, Lennart Poettering wrote:
> On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote:
> 
>> Recently, after I had found an update for my BIOS, my desktop started to
>> resume properly (before I could only suspend it). Kernel and systemd do
>> their jobs fine. But they seem to have problem cooperating.
>>
>> For the record I use systemd 215, which means that the issue I describe
>> here may have been fixed already.
>>
>> After several suspend/resumes systemctl shows more than three dozens of
>> rfkill devices even though I've got only one BT and one WLAN.
>>
>> --8<---cut here---start->8---
>> systemd-rfkill@rfkill0.service   loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill0
>> systemd-rfkill@rfkill1.service   loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill1
>> systemd-rfkill@rfkill2.service  loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill4
>> systemd-rfkill@rfkill3.service  loaded active exitedLoad/Save RF Kill 
>> Switch Status of rfkill4
>>
>> [...]
> 
> This really smells like a kernel bug. systemd gets the device names
> via udev from the kernel, hence it's probably some driver bug that
> creates these devices incorrectly.

I talked to the kernel guys at my office and they told me that it is
quite usual (at least for USB devices, and my wlan and bt are USB)
that devices are stopped and unregistered in the kernel before
a system is suspended end reported as completely new ones
with increased numbers after machine resumes.
 
>> Nov 18 18:24:02 kotik systemd[1]: Stopping Load/Save RF Kill Switch Status 
>> of rfkill9...
>> Nov 18 18:24:02 kotik systemd[1]: systemd-rfkill@rfkill9.service: control 
>> process exited, code=exited status=1
>> Nov 18 18:24:02 kotik systemd[1]: Stopped Load/Save RF Kill Switch Status of 
>> rfkill9.
>> Nov 18 18:24:02 kotik systemd[1]: Unit systemd-rfkill@rfkill9.service 
>> entered failed state.
>> --8<---cut here---end--->8---
>>
>> The actual issue as I see it is that systemd does not stop and remove
>> rfkill services that refer to nonexistent devices.
> 
> Yes, we do not flush out information about failed services by default
> so that the admin can have a look and figure out what's going on. If
> this is not desired, then the binary path in ExecStart= should be
> prefixed with "-"...

The above system-rfkill@rfkill9 failed because I tried to stop it
manually. Before I did it it was like all the others "loaded active
exited".

> I think in this case (and by default) we should keep track of errors
> though, even if it is annoying. But systemd is really not the place to
> work around all possible kernel bugs...

As I wrote above, this isn't necessary a "kernel bug" but it may be
... "underdesigned" feature. I mean removing devices (at least USB)
before entering STR/S3 seems reasonable. I don't find (from the
kernel perspective) anything wrong with registering them with ever
increasing numbers after resume either. However, maybe, the way it
works together with user-land needs more attention.

-- 
Było mi bardzo miło.   Twoje oczy lubią mnie
>Łukasz< i to mnie zgubi  (c)SNL

REKLAMA: http://ars-fabrica.eu/ sklep z rękodziełem



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

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

2014-11-20 Thread Dan Williams

On Thu, 2014-11-20 at 14:56 +0100, Michael Biebl wrote:
> 2014-11-20 14:17 GMT+01:00 Lennart Poettering :
> > On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote:
> >
> >> Hi.
> >>
> >> Recently, after I had found an update for my BIOS, my desktop started to
> >> resume properly (before I could only suspend it). Kernel and systemd do
> >> their jobs fine. But they seem to have problem cooperating.
> >>
> >> For the record I use systemd 215, which means that the issue I describe
> >> here may have been fixed already.
> >>
> >> After several suspend/resumes systemctl shows more than three dozens of
> >> rfkill devices even though I've got only one BT and one WLAN.
> >>
> >> --8<---cut here---start->8---
> >> systemd-rfkill@rfkill0.service   loaded active exitedLoad/Save RF Kill 
> >> Switch Status of rfkill0
> >> systemd-rfkill@rfkill1.service   loaded active exitedLoad/Save RF Kill 
> >> Switch Status of rfkill1
> >> systemd-rfkill@rfkill2.service  loaded active exitedLoad/Save RF Kill 
> >> Switch Status of rfkill4
> >> systemd-rfkill@rfkill3.service  loaded active exitedLoad/Save RF Kill 
> >> Switch Status of rfkill4
> >>
> >> [...]
> >
> > This really smells like a kernel bug. systemd gets the device names
> > via udev from the kernel, hence it's probably some driver bug that
> > creates these devices incorrectly.
> >
> >> Nov 18 18:24:02 kotik systemd[1]: Stopping Load/Save RF Kill Switch Status 
> >> of rfkill9...
> >> Nov 18 18:24:02 kotik systemd[1]: systemd-rfkill@rfkill9.service: control 
> >> process exited, code=exited status=1
> >> Nov 18 18:24:02 kotik systemd[1]: Stopped Load/Save RF Kill Switch Status 
> >> of rfkill9.
> >> Nov 18 18:24:02 kotik systemd[1]: Unit systemd-rfkill@rfkill9.service 
> >> entered failed state.
> >> --8<---cut here---end--->8---
> >>
> >> The actual issue as I see it is that systemd does not stop and remove
> >> rfkill services that refer to nonexistent devices.
> >
> > Yes, we do not flush out information about failed services by default
> > so that the admin can have a look and figure out what's going on. If
> > this is not desired, then the binary path in ExecStart= should be
> > prefixed with "-"...
> >
> > I think in this case (and by default) we should keep track of errors
> > though, even if it is annoying. But systemd is really not the place to
> > work around all possible kernel bugs...
> 
> I had some rather "interesting" experience with the rfkill service as well.
> See [1]. Basically, running rfkill on one device, made the other device go 
> away.

That's normal behavior in the case of a platform rfkill device and a
device-specific rfkill device.  The platform rfkill functionality can
sometimes (often?) cut power to the device through BIOS and GPIOs, and
it will drop off the USB or PCI bus.  But the device itself can also
expose rfkill functionality through it's own drivers, that doesn't cause
it to drop off the bus.  This is your case with the USB-based Bluetooth
device and the BIOS-based platform killswitch.

Since the routing of all these rfkills is highly model specific, there
is no way to know that the platform rfkill has an affect on any other
device in a generic way.  That would have to be hardcoded into the
kernel and would be pretty awful to maintain.

Dan

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

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

2014-11-20 Thread Greg KH

On Thu, Nov 20, 2014 at 03:50:43PM -0300, Cristian Rodríguez wrote:
> El 20/11/14 a las 15:40, Lukasz Stelmach escribió:
> 
> > 
> > $ ls /sys/class/rfkill/
> > rfkill41  rfkill42
> > $ systemctl -t device | grep rfkill
> > sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device
> >  
> > sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device
> > 
> 
> huh.. so the kernel does not preserve the device number on resume and
> recreate new ones? Im not sure but that sounds like a kernel bug...

Nope, not a bug, that's how rfkill is designed, it is an incrementing
number that keeps going up.

Now we can change this, in the kernel, to "recycle" numbers, but you
will still have the same issue where the numbers could reverse after
suspend/resume, so you can't rely on the number for anything.  You need
to follow the parent of the device to know what it controls.

thanks,

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

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



On 11/20/2014 06:48 PM, Reindl Harald wrote:


Am 20.11.2014 um 19:41 schrieb Jóhann B. Guðmundsson:

On 11/20/2014 06:27 PM, Reindl Harald wrote:



what you asked don't matter since this is a *developer list* and so no
place where a RHEL customer with support is expected to jump blindly
and try unsupported packages


Right which makes this not the place to ask for this either. ( should be
asked in downstream community's surrounding RHEL and it's clones )


* if "downstream" is oudated you shout
* if "downstream" tries to change that you shout
* if a user from downstream asks something you shout


You do realize that you are speaking of an *enterprise* distribution 
which maintains things based on their business model  ( which usually 
does not involve the latest and the greatest from upstream ) and is 
driven by their customer demands.


upstream has no business criticizing or otherwise interfere with their 
business model.





Red Hat should be supplying it's own QA resources to test it's own and
upcoming RHEL product releases instead of be reaching out to the
community *to do it for them*  and leach of it + he does not 
mention, if

you intend on testing this on RHEL if it breaks your RHEL support
contract or not ( which most likely it does ) hence the question


no idea from where your personal vendetta against Redhat is coming
(not only in that response, over years, everywhere) but why don't you
just ignore anything containing the company name?


My personal vendetta against Red Hat spurs from their attitude and
repeated misuse of contributors time in projects like Fedora but that's
irrelevant here.


your definition of "misuse" is just broken


You mean does not match yours and my vendetta with Red Hat is irrelevant 
and off topic for this list including your view on it.





Encase you somehow missed it, the systemd project has been heavinly
criticized for being a Red Hat only project


not only - also for be hostile in responses to anybody asking 
something without provide code - as you do here again


I asked Lukáš  a simple 
question if running this on your enterprises licensed distribution would 
not break the support contract with Red Hat and Lukáš 
 already has plethora of 
code in systemd.


In addition to that you do realize you as an RHEL tester not being paid 
by Red Hat or any other enterprise distribution either are spending your 
own dime paying for an licences or you are misusing your corporate 
supplied licence when doing so.


Personally I think it's illogical that Red Hat customer spending their 
time and money paying Red Hat to ask them to test and tell them if 
*their* product works.





and it's members heavily
flamed publicly due to that and it makes no wonder if people get that
notion when RHEL employees treat it like internal company project


by just asking upstream developers to have a look?
really? 


Yes really more than you can image

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

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



Am 20.11.2014 um 20:54 schrieb Jóhann B. Guðmundsson:

Personally I think it's illogical that Red Hat customer spending their
time and money paying Red Hat to ask them to test and tell them if
*their* product works


personally i think it's *the difference* between pure commercial 
software and based on opensource to have early access and the chance to 
test and speak *before* it is released


*nobody* do force anybody to spend a single second
*just ask* "if you like you can do so"

a user/customer don't want to?
so what - delete the mail and that's it

your problem is that you have a hostile attitude against anybody not 
doing like you want - that's excatly the same as your well known 
fedora-devel posts "*we* as QA" sounding like you are the "we" alone




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

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



On 11/20/2014 08:05 PM, Reindl Harald wrote:


your problem is that you have a hostile attitude against anybody not 
doing like you want 


No I dont.

- that's excatly the same as your well known fedora-devel posts "*we* 
as QA" sounding like you are the "we" alone 


Aha right like you should be getting yourself blocked on this and other 
mailinglists.


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

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



Am 20.11.2014 um 21:10 schrieb Jóhann B. Guðmundsson:

On 11/20/2014 08:05 PM, Reindl Harald wrote:


your problem is that you have a hostile attitude against anybody not
doing like you want


No I dont.


- that's excatly the same as your well known fedora-devel posts "*we*
as QA" sounding like you are the "we" alone


Aha right like you should be getting yourself blocked on this and other
mailinglists.


EOT since you are quoting out of context, anybody who is interested can 
easily verify that by himself


i just answered your question and this was for sure the last time i 
respond to anything you are saying because your hypocritical way of 
quote and respond is not worth a single second




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

[systemd-devel] [PATCH v2 2/2] update TODO

2014-11-20 Thread Iago López Galeiras

Empty environment variables in Environment= and EnvironmentFile= options
work.
---
 TODO | 2 --
 1 file changed, 2 deletions(-)

diff --git a/TODO b/TODO
index d4138fe..3e8d04c 100644
--- a/TODO
+++ b/TODO
@@ -191,8 +191,6 @@ Features:
 
 * generator that automatically discovers btrfs subvolumes, identifies their 
purpose based on some xattr on them.
 
-* support setting empty environment variables with Environment= and 
EnvironmentFile=
-
 * timer units: actually add extra delays to timer units with high AccuracySec 
values, don't start them already when we are awake...
 
 * a way for container managers to turn off getty starting via 
$container_headless= or so...
-- 
2.1.3

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

[systemd-devel] [PATCH v2 0/2] Empty environment variables in unit files work

2014-11-20 Thread Iago López Galeiras

Clarified commit message (thanks Koen Kooi)

Iago López Galeiras (2):
  test: support empty environment variables in unit files
  update TODO

 TODO  |  2 --
 src/test/test-unit-file.c | 22 ++
 2 files changed, 22 insertions(+), 2 deletions(-)

-- 
2.1.3

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

[systemd-devel] [PATCH v2 1/2] test: support empty environment variables in unit files

2014-11-20 Thread Iago López Galeiras

---
 src/test/test-unit-file.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/src/test/test-unit-file.c b/src/test/test-unit-file.c
index 03b3e25..f31a1bb 100644
--- a/src/test/test-unit-file.c
+++ b/src/test/test-unit-file.c
@@ -222,6 +222,9 @@ static void test_config_parse_exec(void) {
"MODULE_0=coretemp\n" \
"MODULE_1=f71882fg"
 
+#define env_file_5  \
+"a=\n" \
+"b="
 
 static void test_load_env_file_1(void) {
 _cleanup_strv_free_ char **data = NULL;
@@ -300,6 +303,24 @@ static void test_load_env_file_4(void) {
 unlink(name);
 }
 
+static void test_load_env_file_5(void) {
+_cleanup_strv_free_ char **data = NULL;
+int r;
+
+char name[] = "/tmp/test-load-env-file.XX";
+_cleanup_close_ int fd;
+
+fd = mkostemp_safe(name, O_RDWR|O_CLOEXEC);
+assert_se(fd >= 0);
+assert_se(write(fd, env_file_5, sizeof(env_file_5)) == 
sizeof(env_file_5));
+
+r = load_env_file(NULL, name, NULL, &data);
+assert_se(r == 0);
+assert_se(streq(data[0], "a="));
+assert_se(streq(data[1], "b="));
+assert_se(data[2] == NULL);
+unlink(name);
+}
 
 static void test_install_printf(void) {
 charname[] = "name.service",
@@ -387,6 +408,7 @@ int main(int argc, char *argv[]) {
 test_load_env_file_2();
 test_load_env_file_3();
 test_load_env_file_4();
+test_load_env_file_5();
 TEST_REQ_RUNNING_SYSTEMD(test_install_printf());
 
 return r;
-- 
2.1.3

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

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

2014-11-20 Thread Lukáš Nykrýn

"Jóhann B. Guðmundsson" píše v Čt 20. 11. 2014 v 18:10 +:
> On 11/20/2014 04:24 PM, Lukáš Nykrýn wrote:
> > Hi,
> >
> > rhel7 / centos7 is shipped with heavily patched systemd 208, which does
> > not contain new interesting features and for us it is a backporting
> > nightmare.
> >
> > I have prepared an experimental repo with newer version of systemd for
> > epel7. Currently it is based on 217 from Fedora rawhide and final goal
> > should be 218.
> >
> > If you are interested, here is a COPR build. Feedback and bug reports
> > are as always highly appreciated.
> >
> > https://copr.fedoraproject.org/coprs/lnykryn/systemd/
> >
> > Lukas
> 
> Wont you break your RHEL support if you run this?

Yes if you will use it on you rhel, it is not supported. 

But this was not my point. I am downstream maintainer and I am just
thinking if it is possible to rebase systemd in relatively conservative
distribution. So I wanted to ask upstream where can I except potential
issues. 

I thought that this could be an interesting topics for upstream because
I think that no distribution have  tried to do such huge rebase in one
major version.

An maybe this could be helpful for other distribution (is debian still
using 208? :) ).

Lukas

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

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

2014-11-20 Thread intrigeri

Lukáš Nykrýn wrote (20 Nov 2014 20:35:05 GMT) :
> (is debian still using 208? :) ).

Nope, we have v215 in Debian testing/sid :)

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

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

2014-11-20 Thread Lukáš Nykrýn

intrigeri píše v Čt 20. 11. 2014 v 21:40 +0100:
> Lukáš Nykrýn wrote (20 Nov 2014 20:35:05 GMT) :
> > (is debian still using 208? :) ).
> 
> Nope, we have v215 in Debian testing/sid :)
> 
> Cheers!
> --
> intrigeri
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Ah sorry for that, I have old information. You will definitely have less
headaches than us. Damn you, sd_bus rewrite.

Lukas

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

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

2014-11-20 Thread Vasiliy Tolstov

2014-11-20 15:22 GMT+03:00 Lennart Poettering :
> Both LLMNR and mDNS are strictly per-link, they will not announce IP
> addresses that are not on the very link that is used for traffic. That
> means if you have eth0 then the hostname will be announced with eth0's
> set of addersses on it. If you have eth1, then the hostname will be
> announced with only eth1's addresses. And similar for dummy0's
> addresses, or any other interface's.
>
> Also note that LLMNR/mDNS only works on interfaces that provide
> multicasting, i.e. only those which appear in "ip link" with the
> MULTICAST flag set.
>
> I am not sure I grok what you are trying to do, but do note that you
> can easily add an additional address to any interface you like,
> including the same address to multiple links. This means to make
> resolved announce a specific address via LLMNR/mDNS is just a matter
> of adding it to the interface via "ip addr add".


My use case is useful when i have ecmp routing for dummy0 address (yes
it have multicast option). In this case on other nodes this address
available via two routing entries with equal cost.
Why not add ability to advertise hostname based on one interface
addresses, but use for communication another devices (in my case eth0,
eth1).

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

Re: [systemd-devel] [PATCH v2 2/2] update TODO



On 11/20/2014 08:18 PM, Iago López Galeiras wrote:

Empty environment variables in Environment= and EnvironmentFile= options
work.


What's the usecase for setting empty environment variables?

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

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

2014-11-20 Thread Michael Biebl

2014-11-20 20:34 GMT+01:00 Dan Williams :
> On Thu, 2014-11-20 at 14:56 +0100, Michael Biebl wrote:
>> I had some rather "interesting" experience with the rfkill service as well.
>> See [1]. Basically, running rfkill on one device, made the other device go 
>> away.
>
> That's normal behavior in the case of a platform rfkill device and a
> device-specific rfkill device.  The platform rfkill functionality can
> sometimes (often?) cut power to the device through BIOS and GPIOs, and
> it will drop off the USB or PCI bus.  But the device itself can also
> expose rfkill functionality through it's own drivers, that doesn't cause
> it to drop off the bus.  This is your case with the USB-based Bluetooth
> device and the BIOS-based platform killswitch.
>
> Since the routing of all these rfkills is highly model specific, there
> is no way to know that the platform rfkill has an affect on any other
> device in a generic way.  That would have to be hardcoded into the
> kernel and would be pretty awful to maintain.

Thanks for the detailed explanation.
Any suggestion how we can address that in systemd-rfkill or its service file?
It's kinda ugly if you get a failed service because of that and having
the system state be reported as "degraded".


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

On Thu, 20.11.14 14:48, Martin Pitt (martin.p...@ubuntu.com) wrote:

> > Sounds resonable. But first, can you elaborate on the reason for 0700
> > rather than 0755?
> 
> Mostly so that users on the host can't call suid root binaries in the
> container. If containers are restricted with selinux/apparmor or
> started as user (both happens in Ubuntu for LXC, for example) this
> would open a way to escalate root privs in a container into root privs
> on the host. https://launchpad.net/bugs/1244635 has the
> details/history of this.
> 
> I know that upstream systemd doesn't ship AppArmor/SELinux profiles,
> and thus your stanza is that containers are inherently insecure. So if
> you aren't convinced by the calling of suid root binaries, 0755 is
> also ok for upstream, or we just skip this part entirely (it's really
> just a small detail, after all).
> 
> Patch attached.

OK, applied. Thanks.

> diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
> index c2311b3..5a80cf2 100644
> --- a/src/nspawn/nspawn.c
> +++ b/src/nspawn/nspawn.c
> @@ -124,6 +124,7 @@ static bool arg_private_network = false;
>  static bool arg_read_only = false;
>  static bool arg_boot = false;
>  static LinkJournal arg_link_journal = LINK_AUTO;
> +static bool link_journal_try = false;

So far we prefixed all variables parsed from command line arguments
with "arg_", please follow the same scheme for this.

Otherwise looks great!

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] Hosts without /etc/machine-id on boot

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

> >a) make /etc writable before systemd is invoked. If you use an initrd
> >this is without risk, given that the initrd should really invoke
> >fsck on the root disk anyway, and there's hence little reason to
> >transition to a read-only root, rather than just doing rw
> >right-away.
> 
> Interesting, I run that through our kernel team. However, we run fsck a
> little bit later on in the boot process to be able to pipe the output to
> plymouth.

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

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

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

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

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

> >The guarantee with /etc/machine-id is really that it is valid at *any*
> >time, in early boot and late boot and all the time in between.
>
> I think I will go that path which is an interesting one and mapping some of
> my thoughts. Thanks for the guidance and documentation on what's the right
> approach to achieve this race-free! I'll work on something around that and
> propose a patch.

Looking forword to it.

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] [BUG] too many rfkill services

On Thu, 20.11.14 13:34, Dan Williams (d...@redhat.com) wrote:

> That's normal behavior in the case of a platform rfkill device and a
> device-specific rfkill device.  The platform rfkill functionality can
> sometimes (often?) cut power to the device through BIOS and GPIOs, and
> it will drop off the USB or PCI bus.  But the device itself can also
> expose rfkill functionality through it's own drivers, that doesn't cause
> it to drop off the bus.  This is your case with the USB-based Bluetooth
> device and the BIOS-based platform killswitch.
> 
> Since the routing of all these rfkills is highly model specific, there
> is no way to know that the platform rfkill has an affect on any other
> device in a generic way.  That would have to be hardcoded into the
> kernel and would be pretty awful to maintain.

Hmm, so, currently we include the rfkill device name in the filename
we store in disk (combined with ID_PATH if it is known). For an rfkill
device that comes and goes and each time changes its name this
filename will not be stable. 

Is there any way how we can get some stable ID out of these devices,
in a way that allows multiple rfkill devices per USB device/interface?
I don't see how without kernel change.

If rfkill devices shall be reliably recognizable, then we need some
kind of sub-USB device stability...

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] [BUG] too many rfkill services

On Thu, 20.11.14 11:42, Greg KH (gre...@linuxfoundation.org) wrote:

> On Thu, Nov 20, 2014 at 03:50:43PM -0300, Cristian Rodríguez wrote:
> > El 20/11/14 a las 15:40, Lukasz Stelmach escribió:
> > 
> > > 
> > > $ ls /sys/class/rfkill/
> > > rfkill41  rfkill42
> > > $ systemctl -t device | grep rfkill
> > > sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device
> > >  
> > > sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device
> > > 
> > 
> > huh.. so the kernel does not preserve the device number on resume and
> > recreate new ones? Im not sure but that sounds like a kernel bug...
> 
> Nope, not a bug, that's how rfkill is designed, it is an incrementing
> number that keeps going up.
> 
> Now we can change this, in the kernel, to "recycle" numbers, but you
> will still have the same issue where the numbers could reverse after
> suspend/resume, so you can't rely on the number for anything.  You need
> to follow the parent of the device to know what it controls.

Well, we use ID_PATH, but this will not suffice for USB devices that
have two rfkill child devices... How do we get stable identifiers for
those? If the rfkill name is not usable, then we need something else
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] [BUG] too many rfkill services

On Thu, 20.11.14 19:56, Lukasz Stelmach (stl...@poczta.fm) wrote:

> I talked to the kernel guys at my office and they told me that it is
> quite usual (at least for USB devices, and my wlan and bt are USB)
> that devices are stopped and unregistered in the kernel before
> a system is suspended end reported as completely new ones
> with increased numbers after machine resumes.

So, I have now added some code that adds BindsTo= for the device unit
to the service. This won't fix much though, as the service is likely
to fail in ExecStop= because it cannot find the device anymore.

For cases like this the tool is entirely useless I figure, since it
can only save the rfkill state at shutdown now, but not on
unplug. This means each time the device appears as hotplug we restore
the state that was set during boot, but not the state from right
before we went to suspend.

I figure the only proper fix for this is to make some daemon take
responsibility, listen to events and store things to disk each time
the setting changes... Not too enthusiastic about adding that
though...

Lennart

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

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