Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

[Andrei Borzenkov]

On Wed, May 6, 2015 at 5:52 AM, Ivan Shapovalov  wrote:
> On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote:
>> On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote:
>>
>> > - do `systemd-run` twice and somehow set up the dependencies
>> > between
>> >   two transient units
>>
>> I'd be happy to take a patch that allows configuring deps for
>> transient units when constructing them.
>
> Hi Lennart,
>
> I've just done this (also added manager-side support for
> JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this
> turned out to be insufficient for my usecase.
>
> I have to start two transient services, say, A.service and B.service,
> and
>
> - B.service "needs" A.service
>   (i. e. B.service Requires=A.service and After=A.service)
>
> - A.service must be stopped as soon as B.service exits
>   (i. e. A.service BindsTo=B.service)
>
> And there is a contradiction: I can't make a dependency on an
> inexistent unit.
> If I create A.service before B.service, I can't set BindsTo=, and if I
> create B.service before A.service, I can't set Requires= and After=.
>
> Locally, I've solved this by allowing inverse dependencies to be set
> over the bus. That is, I make B.service BoundBy=A.service. Is this
> acceptable for upstream?
>

What about adding option --define-only (I do not care about actual
name) that adds unit definition but does not start unit? Then you can
define any number of transient units and then "systemctl start" them
later.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] udev: fix coding style

[Susant Sahani]

---
 src/udev/net/ethtool-util.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/udev/net/ethtool-util.c b/src/udev/net/ethtool-util.c
index ec67126..927b8ab 100644
--- a/src/udev/net/ethtool-util.c
+++ b/src/udev/net/ethtool-util.c
@@ -93,8 +93,7 @@ int ethtool_get_driver(int *fd, const char *ifname, char 
**ret) {
 return 0;
 }
 
-int ethtool_set_speed(int *fd, const char *ifname, unsigned int speed, Duplex 
duplex)
-{
+int ethtool_set_speed(int *fd, const char *ifname, unsigned int speed, Duplex 
duplex) {
 struct ethtool_cmd ecmd = {
 .cmd = ETHTOOL_GSET
 };
-- 
2.4.0

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

Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs

[systemd github import bot]

Patchset imported to github.
Pull request:


--
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] Sending a SIGABRT to PID1

[Mantas Mikulėnas]

On Mon, May 4, 2015 at 3:40 AM, Lennart Poettering 
wrote:

> On Sun, 03.05.15 19:10, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
> > On Sun, May 3, 2015 at 6:54 PM, Víctor Fernández 
> wrote:
> >
> > > Ok, Thanks for your reply.
> > >
> > > But, just out of curiosity, why init process gets down with a SIGABRT
> and
> > > not with a SIGKILL (9), being this a signal which cannot be caught,
> blocked
> > > or ignored?
> > >
> >
> > pid 1 is allowed to catch SIGKILL, and usually does so, so that you can
> > sigkill everything (e.g. Alt+SysRq+I) and still have a working system
> > afterwards.
>
> Hmm, it is allowed to do catch SIGKILL? That would be news to me, and
> systemd certainly doesn't. Do you have any reference?


I'm not sure exactly. It *seems* I was wrong; the comment in the source
says "init gets no signals it doesn't want" (i.e. no custom handler), but
doesn't actually allow installing a handler for SIGKILL.

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

[systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs

[Zbigniew Jędrzejewski-Szmek]

In the initramfs, we run systemd-fsck@.service.
In the real system we run systemd-fsck-root.service. Generate
a fake systemd-fsck-root.service if we are running a unit check
for the root file system. We don't really care if the real fsck unit
fails, because the failure will be handled in some other way.

This fake unit is created and pulled in only when we actually plan to
check the file system for /sysroot. This way we avoid having an
active/exited systemd-fsck-root.service in the main filesystem if
we didn't do anything.

https://bugzilla.redhat.com/show_bug.cgi?id=1201979

C.f. 956eaf2b8d6c024705ddadc7393bc707de02.
---
Something like this?

 TODO   |  5 -
 src/shared/generator.c | 30 ++
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/TODO b/TODO
index 430a354e84..cc827701f0 100644
--- a/TODO
+++ b/TODO
@@ -113,9 +113,6 @@ Features:
 * Maybe add support for the equivalent of "ethtool advertise" to .link files?
   http://lists.freedesktop.org/archives/systemd-devel/2015-April/030112.html
 
-* fstab-generator should generate systemd-fsck-root.service when
-  running in the initrd, and operate on the right device.
-
 * .timer units should optionally support CLOCK_BOOTTIME in addition to 
CLOCK_MONOTONIC
 
 * create a btrfs qgroup for /var/lib/machines, and add all container
@@ -153,8 +150,6 @@ Features:
 * Introduce $LISTEN_NAMES to complement $LISTEN_FDS, containing a
   colon separated list of identifiers for the fds passed.
 
-* when the fstab-generator runs in the initrd, it should create a /dev/null 
mask for systemd-fsck-root.service, to avoid that the the root fs is fsck'ed 
twice.
-
 * maybe introduce WantsMountsFor=? Usecase:
   http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
 
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 2dc34bf738..813ce1af9a 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -28,8 +28,32 @@
 #include "generator.h"
 #include "path-util.h"
 #include "fstab-util.h"
+#include "fileio.h"
 #include "dropin.h"
 
+static int write_fsck_root_service(const char *dir) {
+const char *unit;
+int r;
+
+unit = strjoina(dir, "/systemd-fsck-root.service");
+log_debug("Creating %s.", unit);
+
+r = write_string_file_atomic(unit,
+"# Automatically generated by a systemd-fstab-generator or 
similar\n\n"
+"[Unit]\n"
+"Description=Root File System Check Placeholder\n"
+"DefaultDependencies=no\n"
+"Before=shutdown.target\n"
+"\n"
+"[Service]\n"
+"ExecStart=/bin/true\n"
+"Type=oneshot\n"
+"RemainAfterExit=yes\n");
+if (r < 0)
+log_warning_errno(errno, "Failed to write unit file %s: %m", 
unit);
+return r;
+}
+
 int generator_write_fsck_deps(
 FILE *f,
 const char *dir,
@@ -79,6 +103,12 @@ int generator_write_fsck_deps(
 "RequiresOverridable=%1$s\n"
 "After=%1$s\n",
 fsck);
+
+if (in_initrd() && path_equal(where, "/sysroot")) {
+(void) write_fsck_root_service(dir);
+fprintf(f,
+"Wants=systemd-fsck-root.service\n");
+}
 }
 
 return 0;
-- 
2.3.5

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

Re: [systemd-devel] [PATCH] Patches for lockfile code

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 05, 2015 at 11:28:26PM -0400, Colin Walters wrote:
> On Tue, May 5, 2015, at 11:15 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, May 04, 2015 at 08:57:56PM -0400, Colin Walters wrote:
> > > I'm planning to use the code in ostree (via libglnx), here's a few minor 
> > > patches for systemd's lockfile code.
> > 
> > 1/3 is useful, applied.
> > 2/3 is OK, but is useless on it's own.
> > 3/3 makes the code uglier, without other benefits ;) It doesn't
> > actually simplify anything, right? We don't want to apply patches to
> > make it easier to export code, unless they have some positive impact
> > on their own.
> 
> There are security/speed benefits to using the `*at()` family of functions;
> the patch doesn't currently change any of the codepaths that use lockfiles in
> systemd today to use it, but I could imagine some in the future.
> 
> Not a big deal though either way, if someone wants it later maybe they'll
> find it in the archives, or retype it.

We almost always use absolute paths. So the patch just changes
*("/some/path") to *at(AT_FDCWD, "/some/path"). I don't think this gives any 
benefits.

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

Re: [systemd-devel] [PATCH] tmpfiles: try to handle read-only file systems gracefully

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 30, 2015 at 08:50:38PM +0200, Michael Olbrich wrote:
> On read-only filesystems trying to create the target will not fail with
> EEXIST but with EROFS. Handle EROFS by checking if the target already
> exists, and if empty when truncating.
> This avoids reporting errors if tmpfiles doesn't actually needs to do
> anything.
> ---
> 
> This is a rework of a patch I wrote some time ago[1]. This time reacting to
> EROFS instead of preempting it.
Applied, with some small changes, see below.

> 
> Michael
> 
> [1] 
> http://lists.freedesktop.org/archives/systemd-devel/2014-August/022158.html
> 
>  src/tmpfiles/tmpfiles.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> index 218d55051410..4473bf019911 100644
> --- a/src/tmpfiles/tmpfiles.c
> +++ b/src/tmpfiles/tmpfiles.c
> @@ -983,9 +983,11 @@ static int write_one_file(Item *i, const char *path) {
>  log_debug_errno(errno, "Not writing \"%s\": %m", 
> path);
>  return 0;
>  }
> -
> -log_error_errno(errno, "Failed to create file %s: %m", path);
> -return -errno;
> +r = -errno;
> +if (i->argument || r != -EROFS || stat(path, &st) < 0 || 
> (i->type == TRUNCATE_FILE && st.st_size > 0)) {
> +log_error_errno(r, "Failed to create file %s: %m", 
> path);
> +return r;
> +}
I reverted the condition, because it seems safer to whitelist instead of
blacklisting. Also, if the condition didn't succeed, we'd do stat twice.
Please check that it still works as intended.

>  }
>  
>  if (i->argument) {
> @@ -1154,6 +1156,10 @@ static int create_item(Item *i) {
>  
>  log_debug("Copying tree \"%s\" to \"%s\".", resolved, 
> i->path);
>  r = copy_tree(resolved, i->path, false);
> +
> +if (r == -EROFS && stat(i->path, &st) == 0)
> +r = -EEXIST;
> +
>  if (r < 0) {
>  struct stat a, b;

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

Re: [systemd-devel] [PATCH] tmpfiles: remember errno before it might be overwritten

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 30, 2015 at 08:34:56PM +0200, Michael Olbrich wrote:
> ---
> 
> I'm not sure if this is really necessary right now, but that might change
> in the future. Saving errno before calling another function is always a
> good idea.
It's one of those functions which explicitly do not modify errno. It it
designed to be inserted between the call and error handling, so this
property is not going to change.

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

Re: [systemd-devel] [PATCH] shared/utmp-wtmp: fix copy/paste error

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 30, 2015 at 08:28:37PM +0200, Michael Olbrich wrote:
> ---
>  src/shared/utmp-wtmp.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/shared/utmp-wtmp.h b/src/shared/utmp-wtmp.h
> index 6ac2c7b1c768..5d26ba6fb1d0 100644
> --- a/src/shared/utmp-wtmp.h
> +++ b/src/shared/utmp-wtmp.h
> @@ -65,7 +65,7 @@ static inline int utmp_wall(
>  const char *username,
>  const char *origin_tty,
>  bool (*match_tty)(const char *tty, void *userdata),
> -void *userdata);
> +void *userdata) {
>  return 0;
>  }
Applied.

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

Re: [systemd-devel] [PATCH] Patches for lockfile code

[Colin Walters]

On Tue, May 5, 2015, at 11:15 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, May 04, 2015 at 08:57:56PM -0400, Colin Walters wrote:
> > I'm planning to use the code in ostree (via libglnx), here's a few minor 
> > patches for systemd's lockfile code.
> 
> 1/3 is useful, applied.
> 2/3 is OK, but is useless on it's own.
> 3/3 makes the code uglier, without other benefits ;) It doesn't
> actually simplify anything, right? We don't want to apply patches to
> make it easier to export code, unless they have some positive impact
> on their own.

There are security/speed benefits to using the `*at()` family of functions;
the patch doesn't currently change any of the codepaths that use lockfiles in
systemd today to use it, but I could imagine some in the future.

Not a big deal though either way, if someone wants it later maybe they'll
find it in the archives, or retype it.



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

Re: [systemd-devel] [PATCH] Patches for lockfile code

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 04, 2015 at 08:57:56PM -0400, Colin Walters wrote:
> I'm planning to use the code in ostree (via libglnx), here's a few minor 
> patches for systemd's lockfile code.

1/3 is useful, applied.
2/3 is OK, but is useless on it's own.
3/3 makes the code uglier, without other benefits ;) It doesn't
actually simplify anything, right? We don't want to apply patches to
make it easier to export code, unless they have some positive impact
on their own.

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

Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

[Ivan Shapovalov]

On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote:
> On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote:
> 
> > - do `systemd-run` twice and somehow set up the dependencies 
> > between
> >   two transient units
> 
> I'd be happy to take a patch that allows configuring deps for
> transient units when constructing them.

Hi Lennart,

I've just done this (also added manager-side support for
JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this
turned out to be insufficient for my usecase.

I have to start two transient services, say, A.service and B.service,
and

- B.service "needs" A.service
  (i. e. B.service Requires=A.service and After=A.service)

- A.service must be stopped as soon as B.service exits
  (i. e. A.service BindsTo=B.service)

And there is a contradiction: I can't make a dependency on an
inexistent unit.
If I create A.service before B.service, I can't set BindsTo=, and if I
create B.service before A.service, I can't set Requires= and After=.

Locally, I've solved this by allowing inverse dependencies to be set
over the bus. That is, I make B.service BoundBy=A.service. Is this
acceptable for upstream?

-- 
Ivan Shapovalov / intelfx /


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] udev: Restore udevadm settle timeout

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 20, 2015 at 10:33:48AM +0200, David Herrmann wrote:
> Hi
> 
> On Sat, Apr 11, 2015 at 9:38 PM, Nir Soffer  wrote:
> > On Sat, Apr 11, 2015 at 1:36 PM, David Herrmann  
> > wrote:
> >> > @@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc, 
> >> > char *argv[]) {
> >> >  break;
> >> >  }
> >> >
> >> > +if (now(CLOCK_MONOTONIC) >= deadline)
> >> > +break;
> >> > +
> >>
> >> Previous udevadm allowed timeout=0 to disable this. I added the condition.
> >
> > Hi David,
> >
> > I think the handling of timeout=0 is incorrect now. The manual says:
> >
> > A value of 0 will check if the queue is empty and always return
> > immediately.
> >
> > In udev-147 (used on rhel6), this was the behavior. If timeout was 0,
> > is_timeout was set and settle was returning with rc=1.
> >
> > This behavior changed in:
> >
> > http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=ead7c62ab7641e150c6d668f939c102a6771ce60
> >
> > After this commit, zero timeout results in unlimited wait. Since this
> > patch did not
> > change the manual or the online help, and the commit message says:
> > "udevadm: settle - kill alarm()", I guess this was unintended change.
> >
> > I don't see the use case for disabling the timeout, so it seems that
> > we should fix
> > this, restoring the behavior before this commit.
> >
> > What do you think?
> 
> Ok, this is on me, sorry for that. I tried to keep the behavior from
> before the code-removal. I wasn't aware that this was not how it is
> documented.
> 
> I'm actually not sure whether that was an intended change. It does not
> look like it was, indeed. Maybe Kay or Tom know more.. I have no idea
> whether timeout=0 is used in the wild.
> 
> I'll stall your further patches until we've decided on this.
What's the status here?

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

Re: [systemd-devel] [PATCH] fix permissions on /run/systemd/nspawn/locks

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 05, 2015 at 01:31:01PM -0500, Seth Jennings wrote:
> machined is getting an EACCES when trying to create the lock file for
> images because the mode on /run/systemd/nspawn/locks is 0600.
> 
> mkdir("/run/systemd/nspawn/locks", 0600) = -1 EEXIST (File exists)
> stat("/run/systemd/nspawn/locks", {st_mode=S_IFDIR|0600, st_size=40, ...}) = 0
> open("/run/systemd/nspawn/locks/inode-41:256", 
> O_RDWR|O_CREAT|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EACCES (Permission 
> denied)
> 
> This commit adjusts the mode to 0700 to correct the issue.
Applied.

Zbyszek

> Signed-off-by: Seth Jennings 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] treewide: fix typos

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 30, 2015 at 11:57:09AM +0200, Torstein Husebø wrote:
> ---
>  man/systemd.unit.xml| 2 +-
>  src/import/export-tar.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Applied.

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

Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service

[Cameron Norman]

On Tue, May 5, 2015 at 4:47 PM, Cameron Norman  wrote:
> On Mon, May 4, 2015 at 5:54 AM, Michael Biebl  wrote:
>> 2015-05-04 14:49 GMT+02:00 Michael Biebl :
>>> Since emergency.service has
>>> KillMode=process
>>> the running bash kept running, and the result was an unusable system.
>>
>> Btw, what's the reason for using KillMode=process in emergency.service?
>
> It seems to have been there since it was first introduced in 2010.
>
> $ git show 70fcff314feff469a8e61dbe5017ed74f5e0a09d -- units/emergency.service
>

Crap I accidentally sent that. The commit:

commit 70fcff314feff469a8e61dbe5017ed74f5e0a09d
Author: Lennart Poettering 
Date:   Tue Apr 13 05:18:12 2010 +0200

units: install a few basic units by default

diff --git a/units/emergency.service b/units/emergency.service
new file mode 100644
index 000..2e9d049
--- /dev/null
+++ b/units/emergency.service
@@ -0,0 +1,10 @@
+[Meta]
+Description=Emergency Shell
+
+[Service]
+ExecStart=/bin/sh
+Type=simple
+StandardInput=tty
+Restart=restart-always
+RestartSec=0
+KillMode=process

If I had to take a guess I would say that it was desired to let the
shell do its own process management, but Lennart can only know. Maybe
KillMode=mixed would be better?

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

Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service

[Cameron Norman]

On Mon, May 4, 2015 at 5:54 AM, Michael Biebl  wrote:
> 2015-05-04 14:49 GMT+02:00 Michael Biebl :
>> Since emergency.service has
>> KillMode=process
>> the running bash kept running, and the result was an unusable system.
>
> Btw, what's the reason for using KillMode=process in emergency.service?

It seems to have been there since it was first introduced in 2010.

$ git show 70fcff314feff469a8e61dbe5017ed74f5e0a09d -- units/emergency.service



>
>
> --
> 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 mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service

[Michael Biebl]

Any thoughts?

2015-05-04 14:54 GMT+02:00 Michael Biebl :
> 2015-05-04 14:49 GMT+02:00 Michael Biebl :
>> Since emergency.service has
>> KillMode=process
>> the running bash kept running, and the result was an unusable system.
>
> Btw, what's the reason for using KillMode=process in emergency.service?
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?



-- 
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] [PATCH] po: Remove src/fsckd/fsckd.c from filelist

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 05, 2015 at 05:58:30PM -0300, Cristian Rodríguez wrote:
> Otherwise make check ends in failed state.
> ---
>  po/POTFILES.in | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/po/POTFILES.in b/po/POTFILES.in
> index 70e7594..b4c1121 100644
> --- a/po/POTFILES.in
> +++ b/po/POTFILES.in
> @@ -5,4 +5,3 @@ src/locale/org.freedesktop.locale1.policy.in
>  src/login/org.freedesktop.login1.policy.in
>  src/machine/org.freedesktop.machine1.policy.in
>  src/timedate/org.freedesktop.timedate1.policy.in
> -src/fsckd/fsckd.c
Kay already applied a similar patch earlier.

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

[systemd-devel] [PATCH] po: Remove src/fsckd/fsckd.c from filelist

[Cristian Rodríguez]

Otherwise make check ends in failed state.
---
 po/POTFILES.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 70e7594..b4c1121 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -5,4 +5,3 @@ src/locale/org.freedesktop.locale1.policy.in
 src/login/org.freedesktop.login1.policy.in
 src/machine/org.freedesktop.machine1.policy.in
 src/timedate/org.freedesktop.timedate1.policy.in
-src/fsckd/fsckd.c
-- 
2.3.7

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

Re: [systemd-devel] [PATCH] Add VARIANT as a standard value for /etc/os-release

[David Herrmann]

Hi

On Tue, May 5, 2015 at 4:15 PM, Stephen Gallagher  wrote:
>
>
> - Original Message -
>> From: "Lennart Poettering" 
>> To: "Stephen Gallagher" 
>> Sent: Tuesday, May 5, 2015 10:13:35 AM
>> Subject: Re: [systemd-devel] [PATCH] Add VARIANT as a standard value for 
>> /etc/os-release
>>
>> On Tue, 05.05.15 08:52, Stephen Gallagher (sgall...@redhat.com) wrote:
>>
>> > Sorry, I forgot to CC you directly on this, Lennart.
>>
>> Sorry for the delay, I am currently travelling (CoreOS fest), and I
>> haven't merged patches in a while due to that. But the patch looks
>> good to me, looks good to merge.
>>
>
>
> Thanks, I'm re-adding systemd-devel to the CC. (I removed it when CCing you 
> this morning so I didn't spam the list).
>
> If someone with commit privilege would merge this, I'd appreciate it. Thanks!

I fixed a typo and pushed it.

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

Re: [systemd-devel] [PATCH] fix permissions on /run/systemd/nspawn/locks

[systemd github import bot]

Patchset imported to github.
Pull request:


--
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] fix permissions on /run/systemd/nspawn/locks

[Seth Jennings]

machined is getting an EACCES when trying to create the lock file for
images because the mode on /run/systemd/nspawn/locks is 0600.

mkdir("/run/systemd/nspawn/locks", 0600) = -1 EEXIST (File exists)
stat("/run/systemd/nspawn/locks", {st_mode=S_IFDIR|0600, st_size=40, ...}) = 0
open("/run/systemd/nspawn/locks/inode-41:256", 
O_RDWR|O_CREAT|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EACCES (Permission 
denied)

This commit adjusts the mode to 0700 to correct the issue.

Signed-off-by: Seth Jennings 
---
 src/shared/machine-image.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/shared/machine-image.c b/src/shared/machine-image.c
index bc215f0..273dacf 100644
--- a/src/shared/machine-image.c
+++ b/src/shared/machine-image.c
@@ -603,7 +603,7 @@ int image_path_lock(const char *path, int operation, 
LockFile *global, LockFile
 return r;
 
 if (p) {
-mkdir_p("/run/systemd/nspawn/locks", 0600);
+mkdir_p("/run/systemd/nspawn/locks", 0700);
 
 r = make_lock_file(p, operation, global);
 if (r < 0) {
@@ -643,7 +643,7 @@ int image_name_lock(const char *name, int operation, 
LockFile *ret) {
 if (streq(name, ".host"))
 return -EBUSY;
 
-mkdir_p("/run/systemd/nspawn/locks", 0600);
+mkdir_p("/run/systemd/nspawn/locks", 0700);
 p = strjoina("/run/systemd/nspawn/locks/name-", name);
 
 return make_lock_file(p, operation, ret);
-- 
2.1.0

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

Re: [systemd-devel] [PATCH 3/3] Use a stamp file to avoid running systemd-fsck-root.service twice

[Harald Hoyer]

On 05.05.2015 15:24, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, May 05, 2015 at 10:48:48AM +0200, Harald Hoyer wrote:
>> On 03.05.2015 17:33, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
 В Sun, 3 May 2015 16:17:15 +0200
 Lennart Poettering  пишет:

> On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> wrote:
>
> So, the last time we discussed this we figured we should do this
> differently, and simply generate systemd-fsck-root.service in the
> initrd as well, that uses a different command line internally. The end
> result would then be that we can do without flag file, and always have
> the guarantee that "systemd-fsck-root.service" is the services that
> fsck'ed the root file system, regardless whether in initrd or not.
>

 systemd-fsck@.service has explicit dependency on
 systemd-fsck-root.service so other mounts (/usr, anything else?) will
 be serialized after it. Currently they can run in parallel.

 Not I think it is a big problem, but at least to consider.
>>> Yeah, that's the main wart. I tried to outline it in the second bullet
>>> point below.
>>>
>>> I prepared a patch to generate systemd-fsck-root.service in
>>> generator_write_fsck_deps() first, but I wasn't happy with the result.
>>> If we ignore the dependency issue, it might be judged more elegant,
>>> since it just uses unit stat to pass information.
>>>
> Harald, can you comment?
>>
>> Zbigniew has a point with the ordering.
>>
>> But maybe the whole thing is easier than it appears:
>> - the initrd can provide a fake systemd-fsck-root.service, with /bin/true
>> - if /sysroot (or any needed fsck) is failing fsck, we don't boot the real
>> system anyway
> 
> Can you have a system with initramfs, with the root mounted initially ro,
> which checks the filesystem after transition to the main system? Or is
> something which is not supported?
> 
> Zbyszek
> 

It's better checked with the fsck binary in the initramfs and not with a
potential broken fsck on the root fs. So, I think we should require the fsck's
of the initrd to succeed, before the initrd can switch root.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] bus connection

[Lennart Poettering]

On Tue, 05.05.15 13:19, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> How can I make bus connections using libsystemd and can I actually use
> them, or is it in development?

The API is not public yet, for details see:

http://lists.freedesktop.org/archives/systemd-devel/2015-April/031363.html

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] Add VARIANT as a standard value for /etc/os-release

[Stephen Gallagher]

- Original Message -
> From: "Lennart Poettering" 
> To: "Stephen Gallagher" 
> Sent: Tuesday, May 5, 2015 10:13:35 AM
> Subject: Re: [systemd-devel] [PATCH] Add VARIANT as a standard value for 
> /etc/os-release
> 
> On Tue, 05.05.15 08:52, Stephen Gallagher (sgall...@redhat.com) wrote:
> 
> > Sorry, I forgot to CC you directly on this, Lennart.
> 
> Sorry for the delay, I am currently travelling (CoreOS fest), and I
> haven't merged patches in a while due to that. But the patch looks
> good to me, looks good to merge.
> 


Thanks, I'm re-adding systemd-devel to the CC. (I removed it when CCing you 
this morning so I didn't spam the list).

If someone with commit privilege would merge this, I'd appreciate it. Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/3] avoid running fsck twice

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 05, 2015 at 10:51:53AM +0200, Harald Hoyer wrote:
> On 02.05.2015 19:16, Zbigniew Jędrzejewski-Szmek wrote:
> > This is an attempt to fix the issue with fsck running twice. Patch 3/3 is
> > the only important one, the other two are nice-to-have.
> > 
> > dracut configuration also has to be modified to include /bin/touch.
> > I'll work on a patch for that later.
> 
> instead of
> $ /bin/touch file
> use
> $ > file
> No need for a fork() to create an empty marker file.

It's in a systemd unit file, so no shell.

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

Re: [systemd-devel] [PATCH 3/3] Use a stamp file to avoid running systemd-fsck-root.service twice

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 05, 2015 at 10:48:48AM +0200, Harald Hoyer wrote:
> On 03.05.2015 17:33, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
> >> В Sun, 3 May 2015 16:17:15 +0200
> >> Lennart Poettering  пишет:
> >>
> >>> On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> >>> wrote:
> >>>
> >>> So, the last time we discussed this we figured we should do this
> >>> differently, and simply generate systemd-fsck-root.service in the
> >>> initrd as well, that uses a different command line internally. The end
> >>> result would then be that we can do without flag file, and always have
> >>> the guarantee that "systemd-fsck-root.service" is the services that
> >>> fsck'ed the root file system, regardless whether in initrd or not.
> >>>
> >>
> >> systemd-fsck@.service has explicit dependency on
> >> systemd-fsck-root.service so other mounts (/usr, anything else?) will
> >> be serialized after it. Currently they can run in parallel.
> >>
> >> Not I think it is a big problem, but at least to consider.
> > Yeah, that's the main wart. I tried to outline it in the second bullet
> > point below.
> > 
> > I prepared a patch to generate systemd-fsck-root.service in
> > generator_write_fsck_deps() first, but I wasn't happy with the result.
> > If we ignore the dependency issue, it might be judged more elegant,
> > since it just uses unit stat to pass information.
> > 
> >>> Harald, can you comment?
> 
> Zbigniew has a point with the ordering.
> 
> But maybe the whole thing is easier than it appears:
> - the initrd can provide a fake systemd-fsck-root.service, with /bin/true
> - if /sysroot (or any needed fsck) is failing fsck, we don't boot the real
> system anyway

Can you have a system with initramfs, with the root mounted initially ro,
which checks the filesystem after transition to the main system? Or is
something which is not supported?

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

[systemd-devel] bus connection

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

How can I make bus connections using libsystemd and can I actually use
them, or is it in development?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVSKdZAAoJEHb1CzgxXKwY73gP/3tQoRVOF0xviFwBcBPS3LMK
teNw+Zu9BvY6kFrHEzhspq95udgsN6SY7Q3DFO1QcXzTp2zlRXBkXjCP/S9e7qm6
2qcbN8gYMG0iHjZbcxtK75PLM5HfG4rtg5lJ7gw2PuTe2rGXpakvOA/WN3VNZVom
dyVltFegHMZeIWVgzDjLqcY3t4hrycbTxyFBkJPSAInFsVxiXZd6XNQkKRRh+2vi
O9zoUR/GhYmvkRaYrB1zl8j9a5fUF8Pof3xTu6vrmNJNMaw0JyMz/4RCdLoVpD97
tuWUC7GU4c8KMGBzZaCAEws1UQ+7YhiXXdBimVB0kR6bjUPPWc9Ns+3iYKf/+x8C
YdRuB4P+pBX+HPFlo4XNaOCnbGIc7d7Ph9qWUZkJFrr/IrXbHt6RHaxyfV1ZYaAt
boc0N2ITM9j5VJGT1i8OOc1cb1XwRoEzdd0lc4o4ApSzopZ/qcWHCXhMuya5nEoc
0zih8HvEChVZoqVY60xjUwgBJb2Nk1JvYdxrTSCzpeplq2JnGNpwHHm0ZxYUiFvR
qqETY+Q9gchgE21s4j5WI0fquL19x+AUX3I/Pbsbkt4g+5lWmHcuGGZThuT6L7cw
CTb2/CYJfCN/GXFOd5mL3dLcKznyzIcxgxDiLQMj0/Pzy4q3jIBYd13i9sBmKNo+
dEyEV4y9bjSk4hfYEfKs
=FZuf
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time

[Rauta, Alin]

Hi guys,
Any updates on this one ?
Thanks,
Alin
From: Rauta, Alin
Sent: Thursday, April 30, 2015 1:57 PM
To: systemd-devel@lists.freedesktop.org; Tom Gundersen; lenn...@poettering.net
Cc: Belkind, Nadav
Subject: networkd: dbus API for networkd reconfiguration at run-time

Hi Tom, Lennart,

I have some questions regarding dbus API and run-time networkd configuration. I 
would really appreciate your answers/suggestions.

First, when upstreaming BridgeFDB support in networkd, I had (in the first 
place) a patch composed of 2 parts:

-  One part  for clearing existing configuration;

-  One part for setting new FDB entries;

Since networkd doesn't currently clear existing configuration, only the first 
part of the patch was accepted.

At that time you said that:

"In the future we plan to get a dbus API where networkd can be reconfigured at 
run-time (i.e., change which .network file is applied to a link), and then it 
definitely would make sense to flush routes and addresses when removing the 
.network from the link, but currently we don't do that at all."

Do you have any updates or more information on dbus API (how would this be 
actually done, how would work) ?
What extensions to existing networkd functionality would the dbus API bring ?

Second, regarding "BindCarrier=" functionality, would dbus API make it possible 
to modify the string content or the bind carrier functionality at run-time ?

Moreover, we currently have the case where networkd is running and has some 
ports involved in "BindCarrier=" dependencies. Then some of this ports are 
run-time added to a team (link aggregation) device (maybe through command line).
In this case the carrier dependencies affect the team device functionality 
creating confusion at one point in time (team tries to get the childs up/down, 
but the functionality is affected by the carrier dependencies between childs or 
between childs and other ports outside of the team device).
Would dbus API be of any help in this case ? or
Do you have any suggestions on how to avoid these cases ?

Thank you in advance,

Alin Rauta
Software Applications Engineer
+353 (0) 87 101 8449
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

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

Re: [systemd-devel] [PATCH 0/3] avoid running fsck twice

[Harald Hoyer]

On 02.05.2015 19:16, Zbigniew Jędrzejewski-Szmek wrote:
> This is an attempt to fix the issue with fsck running twice. Patch 3/3 is
> the only important one, the other two are nice-to-have.
> 
> dracut configuration also has to be modified to include /bin/touch.
> I'll work on a patch for that later.

instead of
$ /bin/touch file
use
$ > file
No need for a fork() to create an empty marker file.

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

Re: [systemd-devel] [PATCH 3/3] Use a stamp file to avoid running systemd-fsck-root.service twice

[Harald Hoyer]

On 03.05.2015 17:33, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
>> В Sun, 3 May 2015 16:17:15 +0200
>> Lennart Poettering  пишет:
>>
>>> On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
>>> wrote:
>>>
>>> So, the last time we discussed this we figured we should do this
>>> differently, and simply generate systemd-fsck-root.service in the
>>> initrd as well, that uses a different command line internally. The end
>>> result would then be that we can do without flag file, and always have
>>> the guarantee that "systemd-fsck-root.service" is the services that
>>> fsck'ed the root file system, regardless whether in initrd or not.
>>>
>>
>> systemd-fsck@.service has explicit dependency on
>> systemd-fsck-root.service so other mounts (/usr, anything else?) will
>> be serialized after it. Currently they can run in parallel.
>>
>> Not I think it is a big problem, but at least to consider.
> Yeah, that's the main wart. I tried to outline it in the second bullet
> point below.
> 
> I prepared a patch to generate systemd-fsck-root.service in
> generator_write_fsck_deps() first, but I wasn't happy with the result.
> If we ignore the dependency issue, it might be judged more elegant,
> since it just uses unit stat to pass information.
> 
>>> Harald, can you comment?

Zbigniew has a point with the ordering.

But maybe the whole thing is easier than it appears:
- the initrd can provide a fake systemd-fsck-root.service, with /bin/true
- if /sysroot (or any needed fsck) is failing fsck, we don't boot the real
system anyway


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