date:20150319

Hello,

 I am experimenting a little with systemd and trying to define a new
 intermediate runlevel, a runlevel between basic.target and
 multi-user.target. This means that I want the services which are
 required
 by my new runlevel to be started after all services from basic.target
 have
 been started and to be finished before any service from
 multi-user.target
 is started.


 There is no feasible way to do it right now.

So, if the original unit file multi-user.target contains

After=basic.target rescue.service rescue.target

this after does not really mean anything and jobs wanted or required by
multi-user.target can already be started when some jobs from basic.target
have not been started???

Regards
  Christoph

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

Re: [systemd-devel] Boot ordering

On Thu, Mar 19, 2015 at 1:00 PM, Christoph Pleger
christoph.ple...@cs.tu-dortmund.de wrote:
 Hello,

 I am experimenting a little with systemd and trying to define a new
 intermediate runlevel, a runlevel between basic.target and
 multi-user.target. This means that I want the services which are
 required
 by my new runlevel to be started after all services from basic.target
 have
 been started and to be finished before any service from
 multi-user.target
 is started.


 There is no feasible way to do it right now.

 So, if the original unit file multi-user.target contains

 After=basic.target rescue.service rescue.target

 this after does not really mean anything and jobs wanted or required by
 multi-user.target can already be started when some jobs from basic.target
 have not been started???


After means exactly what it says - multi-user.target waits for all
units listed in After line. It does not imply anything about relative
ordering of those units. Unless they have other dependencies all of
them will (attempted to) be started in parallel.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Boot ordering

On 19 March 2015 at 10:00, Christoph Pleger
christoph.ple...@cs.tu-dortmund.de wrote:
 Hello,

 I am experimenting a little with systemd and trying to define a new
 intermediate runlevel, a runlevel between basic.target and
 multi-user.target. This means that I want the services which are
 required
 by my new runlevel to be started after all services from basic.target
 have
 been started and to be finished before any service from
 multi-user.target
 is started.


 There is no feasible way to do it right now.

 So, if the original unit file multi-user.target contains

 After=basic.target rescue.service rescue.target

 this after does not really mean anything and jobs wanted or required by
 multi-user.target can already be started when some jobs from basic.target
 have not been started???

Correct.

You can move a service to be started earlier.

You cannot force move a service to be started later.

E.g. if foo.service is WantedBy=multi-user.target, yet bar.service
declares Wants=foo.service and bar.service is to be started e.g. for
basic.target, foo.service will be already running by the time
multi-user.target starts activation of its wants. (in simplified
description)

This is by design, and hard / non-needed to be fixed. However their
might be alternative solutions to your problem. What is the the
problem you are trying to solve by implementing a new 'intermediate'
runlevel ?

-- 
Regards,

Dimitri.

Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

2015-03-19 Thread Stef Walter

This property is in usec (like the TimeUSec property) and allows
retrieving the timezone offset for the machine. This is particularly
usable for remote callers.
---
 src/timedate/timedated.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..e384b36 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -361,6 +361,22 @@ static int property_get_time(
 return sd_bus_message_append(reply, t, now(CLOCK_REALTIME));
 }
 
+static int property_get_local_offset(
+sd_bus *bus,
+const char *path,
+const char *interface,
+const char *property,
+sd_bus_message *reply,
+void *userdata,
+sd_bus_error *error)
+{
+struct tm *tm;
+time_t dummy = 0;
+
+assert_se(tm = localtime(dummy));
+return sd_bus_message_append(reply, t, (uint64_t)(tm-tm_gmtoff * 
100));
+}
+
 static int property_get_ntp_sync(
 sd_bus *bus,
 const char *path,
@@ -440,7 +456,8 @@ static int method_set_timezone(sd_bus *bus, sd_bus_message 
*m, void *userdata, s
LOG_MESSAGE(Changed time zone to '%s'., c-zone),
NULL);
 
-sd_bus_emit_properties_changed(bus, /org/freedesktop/timedate1, 
org.freedesktop.timedate1, Timezone, NULL);
+sd_bus_emit_properties_changed(bus, /org/freedesktop/timedate1, 
org.freedesktop.timedate1,
+   Timezone, LocalOffset, NULL);
 
 return sd_bus_reply_method_return(m, NULL);
 }
@@ -666,6 +683,7 @@ static int method_set_ntp(sd_bus *bus, sd_bus_message *m, 
void *userdata, sd_bus
 static const sd_bus_vtable timedate_vtable[] = {
 SD_BUS_VTABLE_START(0),
 SD_BUS_PROPERTY(Timezone, s, NULL, offsetof(Context, zone), 
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+SD_BUS_PROPERTY(LocalOffset, t, property_get_local_offset, 0, 
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
 SD_BUS_PROPERTY(LocalRTC, b, bus_property_get_bool, 
offsetof(Context, local_rtc), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
 SD_BUS_PROPERTY(CanNTP, b, bus_property_get_bool, 
offsetof(Context, can_ntp), 0),
 SD_BUS_PROPERTY(NTP, b, bus_property_get_bool, offsetof(Context, 
use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
-- 
2.3.3

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

Re: [systemd-devel] Boot ordering

On 19 March 2015 at 12:09, Christoph Pleger
christoph.ple...@cs.tu-dortmund.de wrote:
 Hello,

 So, if the original unit file multi-user.target contains

 After=basic.target rescue.service rescue.target

 this after does not really mean anything and jobs wanted or required
 by
 multi-user.target can already be started when some jobs from
 basic.target
 have not been started???

 Correct.
 ...
 What is the the
 problem you are trying to solve by implementing a new 'intermediate'
 runlevel ?

 I want a program to be run at boot time without any other systemd services
 starting concurrently. The program needs the services from basic.target
 and may influence everything in multi-user.target and later targets, so I
 guess that between basic.target and multi-user.target is a good time for
 execution of the program.

 I hoped that this can be achieved by simply defining a new target, setting
 after basic.target dependencies for it and changing the dependencies of
 multi-user.target from basic.target to my new target. This would not
 require me too know anything about the specific services in basic.target
 and multi-user.target .

Sounds like you want to create intermediate.target, change
default.target to point at it, boot all the way up to
intermediate.target, and at that point isolate or start
multi-user.target.
If your default.target points at multi-user.target, there is no way to
prevent multi-user things from not running until after
itermediate.target.

-- 
Regards,

Dimitri.

Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC PATCH] udev: add an abs-override builtin to override EV_ABS data

Hi

On Thu, Mar 19, 2015 at 10:52 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 This builtin parses properties in the form
 EV_ABS_OVERRIDE_00=min:max:res:fuzz:flat

The concept sounds good. hwdb is definitely the place to put this,
rather than static kernel fixups.

 and applies them to the kernel device. Future processes that open that device
 will see the updated EV_ABS range.

 This is particularly useful for touchpads that don't provide a resolution in
 the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974).

 All values in the property are optional, e.g. a string of ::45 is valid to
 set the resolution to 45.

 The order intentionally orders resolution before fuzz and flat despite it
 being the last element in the absinfo struct. The use-case for setting
 fuzz/flat is almost non-existent, resolution is probably the most common case
 we'll need.

If a field is left empty, should it take the kernel-provided values?
This way, you could just order it logically and leave stuff you don't
wanna change empty.

 ---
 This is just an RFC for now, a couple of questions remain:
 * we need this for touchpads, but this seems something that could be more
   generic and have it's own ruleset, possibly depending on ID_INPUT_TOUCH*
   or so
 * input_id is already called and opens the device, we could merge this in
   there

Don't get confused by the name of this builtin. It's legacy. We should
probably also merge 'keyboard' into it.

Talking about the 'keyboard' builtin: why not merge both? They serve
the same purpose, fixing wrong kernel mapping/data. You could even
rename the prefix to evdev ('input' is reserved..), and then put
both into the same file. You could re-use the matching we have in
place for keyboards. I think it would work well enough for all other
input-devices, too. It uses the input-modalias, and device-name+dmi as
fallback. Ok, the atkbd: is special to keyboards, but just ignore
it.

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

Re: [systemd-devel] Boot ordering

Hello,

 So, if the original unit file multi-user.target contains

 After=basic.target rescue.service rescue.target

 this after does not really mean anything and jobs wanted or required
 by
 multi-user.target can already be started when some jobs from
 basic.target
 have not been started???

 Correct.
 ...
 What is the the
 problem you are trying to solve by implementing a new 'intermediate'
 runlevel ?

I want a program to be run at boot time without any other systemd services
starting concurrently. The program needs the services from basic.target
and may influence everything in multi-user.target and later targets, so I
guess that between basic.target and multi-user.target is a good time for
execution of the program.

I hoped that this can be achieved by simply defining a new target, setting
after basic.target dependencies for it and changing the dependencies of
multi-user.target from basic.target to my new target. This would not
require me too know anything about the specific services in basic.target
and multi-user.target .

Regards
  Christoph

Regards
  Christoph

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

Re: [systemd-devel] Boot ordering

On Thu, Mar 19, 2015 at 3:09 PM, Christoph Pleger
christoph.ple...@cs.tu-dortmund.de wrote:
 Hello,

 So, if the original unit file multi-user.target contains

 After=basic.target rescue.service rescue.target

 this after does not really mean anything and jobs wanted or required
 by
 multi-user.target can already be started when some jobs from
 basic.target
 have not been started???

 Correct.
 ...
 What is the the
 problem you are trying to solve by implementing a new 'intermediate'
 runlevel ?

 I want a program to be run at boot time without any other systemd services
 starting concurrently. The program needs the services from basic.target

Well, for the specific service you do know which services it requires,
right? Then simply start it as part of basic.target and make sure it
is ordered after required services.

 and may influence everything in multi-user.target and later targets, so I
 guess that between basic.target and multi-user.target is a good time for
 execution of the program.

 I hoped that this can be achieved by simply defining a new target, setting
 after basic.target dependencies for it and changing the dependencies of
 multi-user.target from basic.target to my new target. This would not
 require me too know anything about the specific services in basic.target
 and multi-user.target .

 Regards
   Christoph

 Regards
   Christoph

 ___
 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] Boot ordering

On Thu, Mar 19, 2015 at 3:19 PM, Christoph Pleger
christoph.ple...@cs.tu-dortmund.de wrote:
 Hello,

 So, if the original unit file multi-user.target contains

 After=basic.target rescue.service rescue.target

 this after does not really mean anything and jobs wanted or required
 by
 multi-user.target can already be started when some jobs from
 basic.target
 have not been started???


 After means exactly what it says - multi-user.target waits for all
 units listed in After line. It does not imply anything about relative
 ordering of those units. Unless they have other dependencies all of
 them will (attempted to) be started in parallel.

 Then, I still do not understand why my definition of a new target did not
 work. What is the difference between multi-user.target waiting for
 basic.target on the one hand and new.target waiting for basic.target and
 multi-user.target waiting for new.target on the other hand, aside from
 that one intermediate step?


Everything else that is ordered before multi-user.target is started
concurrently with your new.target.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Boot ordering

2015-03-19 Thread Reindl Harald



Am 19.03.2015 um 13:09 schrieb Christoph Pleger:

What is the the
problem you are trying to solve by implementing a new 'intermediate'
runlevel ?


I want a program to be run at boot time without any other systemd services
starting concurrently. The program needs the services from basic.target
and may influence everything in multi-user.target and later targets, so I
guess that between basic.target and multi-user.target is a good time for
execution of the program.

I hoped that this can be achieved by simply defining a new target, setting
after basic.target dependencies for it and changing the dependencies of
multi-user.target from basic.target to my new target. This would not
require me too know anything about the specific services in basic.target
and multi-user.target


what about

After=basic.target
Before=multi-user.target



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] Boot ordering

Hello,

 So, if the original unit file multi-user.target contains

 After=basic.target rescue.service rescue.target

 this after does not really mean anything and jobs wanted or required
 by
 multi-user.target can already be started when some jobs from
 basic.target
 have not been started???


 After means exactly what it says - multi-user.target waits for all
 units listed in After line. It does not imply anything about relative
 ordering of those units. Unless they have other dependencies all of
 them will (attempted to) be started in parallel.

Then, I still do not understand why my definition of a new target did not
work. What is the difference between multi-user.target waiting for
basic.target on the one hand and new.target waiting for basic.target and
multi-user.target waiting for new.target on the other hand, aside from
that one intermediate step?

Regards
  Christoph

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

Re: [systemd-devel] StartLimitBurst prevents manual start-up of a service

В Thu, 19 Mar 2015 15:23:41 -0400
Nekrasov, Alexander alexander.nekra...@emc.com пишет:

 Hi All,
 
 Suppose I have a B.service that's doing important work, and an A.service 
 that's watching over B memory consumption. So I want to start A when I start 
 B, and stop A when I stop B. Also B, being important, should be allowed to 
 restart on failures. A, being just a monitor, should be left down if it 
 starts failing too often.
 
 Suppose I have in A.service:
 
 Restart=yes
 StartLimitInterval=300
 StartLimitBurst=1
 StopWhenUnneeded=true
 
 Suppose B.service.wants/A.service and in B.service I have:
 
 Restart=yes
 StartLimitInterval=30
 StartLimitBurst=3
 
 What happens is, any start of A is counted against the StartLimitBurst limit. 
 Which means, there is no way to let B restart any more frequently than A and 
 have A follow B. The same thing applies to starting A manually - a systemctl 
 start call will fail if done more frequently than once per 300 seconds.
 
 The manual systemctl start problem can be fixed by running systemctl 
 reset-failed before it, but I couldn't find a way to fix the failing to start 
 on a dependency.
 
 How do I support this use case?
 

Why A is restarted in the first place? Once it is started, it should
not be cleaned up until B is present, and B will be present as long as
it is being restarted. Restart of B should not cause restart of A, at
least not because A suddenly becomes unneeded. 

 Thanks,
 Alex
 
 systemd-210-34.9.x86_64
 systemd-bash-completion-210-34.9.noarch
 systemd-rpm-macros-2-7.2.noarch
 util-linux-systemd-2.25-2.2.x86_64
 systemd-32bit-210-34.9.x86_64
 systemd-sysvinit-210-34.9.x86_64
 systemd-presets-branding-SLE-12.0-12.1.noarch
 ___
 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] [PATCH] hwdb: ship ids-update.pl sdio.ids in the release tarballs.

2015-03-19 Thread Marcel Holtmann

Hi Michael,

 On 16 March 2015 at 23:15, Marcel Holtmann mar...@holtmann.org wrote:
 Hi Dimitri,
 
 Just tell patch or git to skip the hunks modifying ids-update.pl and 
 sdio.ids. Problem solved.
 
 I'll apply the patch, but with a slightly different motivation.
 
 [L]GPL requires commercial entities distributing a modified version of
 the program to provide full source in the preferred form for modification,
 including all scripts used for building. This includes sdio.ids and
 ids-update.pl. We should make it easy to follow the our licensing, so
 we should include those files in our tarball to make it directly
 redistributable.
 
 that is just making stuff up.
 Where was I wrong?
 
 Are you now also including usb.ids?
 We probably should
 
 
 Right, we should include all source files, not only the generated files.

is this turning in Freaky Friday now? Can we please be real for a bit.

You do realize that I did not put a copyright header on top of sdio.ids. In 
addition this information will be most likely considered a not copyrightable 
piece of source anyway. If we assume that this is non-copyrightable, then how 
can you apply a copyleft license to it?

And honestly I rather take sdio.ids file out of systemd.git and maintain it 
outside if we start making these weird claims.

Regards

Marcel

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

Re: [systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.

2015-03-19 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Mar 16, 2015 at 08:33:52PM +0100, Goffredo Baroncelli wrote:
 From: Goffredo Baroncelli kreij...@inwind.it
 
 Add a new tmpfiles.d snippets to set the NOCOW attributes for the
 journal files. This allow better perfomance when the root file system
 is BTRFS. Pay attention that the NOCOW flags disables the checksum and
 prevent scrub to rebuild a corrupted journal.
I now merged patches 1-3/4, but not this one. Setting/unsetting
attributes seems to be generally useful, so the rest stands on its
own. The reason I held back with the last patch is that setting of the
attributes through tmpfiles should be added together with the removal
of the same functionality from journald. But there are some details to
work out.

Setting +C on /var/log/journal/%m has smaller scope than the code in
journal-file.c now. For example it does not cover files opened by
systemd-journal-remote. Having the files no-cow is just as useful for those,
but it's not entirely clear how to support it in the new scheme.

Zbyszek

 +# set the journal file as NOCOW; only valid for BTRFS filesystem
 +h /var/log/journal/%m - - - - +C
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl sdio.ids in the release tarballs.

2015-03-21 13:12 GMT+01:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 On Thu, Mar 19, 2015 at 06:43:18PM -0700, Marcel Holtmann wrote:
 Hi Zbyszek,

  On 16 March 2015 at 23:15, Marcel Holtmann mar...@holtmann.org wrote:
  Hi Dimitri,

  Just tell patch or git to skip the hunks modifying ids-update.pl and 
  sdio.ids. Problem solved.
 
  I'll apply the patch, but with a slightly different motivation.
 
  [L]GPL requires commercial entities distributing a modified version of
  the program to provide full source in the preferred form for modification,
  including all scripts used for building. This includes sdio.ids and
  ids-update.pl. We should make it easy to follow the our licensing, so
  we should include those files in our tarball to make it directly
  redistributable.

 that is just making stuff up.
 Where was I wrong?

 Are you now also including usb.ids?
 We probably should


Right, we should include all source files, not only the generated files.


-- 
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] hwdb: ship ids-update.pl sdio.ids in the release tarballs.

2015-03-19 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Mar 19, 2015 at 06:43:18PM -0700, Marcel Holtmann wrote:
Hi Zbyszek,

On 16 March 2015 at 23:15, Marcel Holtmann mar...@holtmann.org wrote:
Hi Dimitri,

This makes it easier to apply stable branch patches on top of the
release tarball.
---
Makefile.am | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 856accb..0ed35ac 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3877,7 +3877,9 @@ dist_udevhwdb_DATA = \
hwdb/70-touchpad.hwdb

EXTRA_DIST += \
- units/systemd-hwdb-update.service.in
+ units/systemd-hwdb-update.service.in \
+ hwdb/ids-update.pl \
+ hwdb/sdio.ids

If you want to apply patches from git, then you can always tell git to
exclude these files and it will happily apply the rest of the patch.
So I do not see a good enough reason to do this.

(a) and (b) can be solved by telling 'patch' or 'git' to not apply
hunks to those files.

Looking at stable branch:

http://cgit.freedesktop.org/systemd/systemd-stable/log/hwdb?h=v219-stable

sdio.ids was changed in
http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stableid=c10e229f8222b92117ba38045ddb3e4d7951244a

but updated in a later commit
http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stableid=9ac622b00ca23f9d01e0ff0c944130be8dc3a0e9

So they do look up to date there.

usb.ids does not appear to be in the source tree.

Why not just commit ids-update.pl / sdio.ids and generate the .hwdb
files on $ make dist, or at autoreconf time?

Just tell patch or git to skip the hunks modifying ids-update.pl and
sdio.ids. Problem solved.

I'll apply the patch, but with a slightly different motivation.

that is just making stuff up.
Where was I wrong?

Are you now also including usb.ids?
We probably should

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

[systemd-devel] systemd and nested Btrfs subvolumes

2015-03-19 Thread Chris Murphy

Short version:
--
  Instead of machinectl clone using btrfs snapshots, or even needing
to store things in a var/lib/machines Btrfs subvolume, does it meet
the requirements for Btrfs optimization to do this with cp -a
--reflink instead?

Why? Nested subvolumes are confusing. And nested subvolumes are
excluded from snapshots. Subvolume B inside of Subvolume A, will not
be snapshot or rolled back, if I snapshot Subvolume A and subsequently
rollback to the snapshot of A. Is this the intended workflow?


Long version comparing two different Btrfs layout paramdigms:
--
  New in systemd-219 is the creation of a subvolume for storing
containers (machines). This is what things look like on Fedora 22
right now.

# btrfs sub list -a /
ID 257 gen 1705 top level 5 path FS_TREE/root
ID 258 gen 1662 top level 5 path FS_TREE/home
ID 259 gen 1681 top level 5 path FS_TREE/boot
ID 262 gen 1705 top level 257 path root/var/lib/machines

# cat etc fstab
UUID=uuid  /   btrfs   subvol=root 0 0
UUID=uuid   /boot   btrfs   subvol=boot 0 0
UUID=uuid   /home   btrfs   subvol=home 0 0

And I see the entry in 'man machinectl' clone entry which says:
   clone NAME NAME
   Clones a container or VM image. The arguments specify the name of
   the image to clone and the name of the newly cloned image. Note
   that plain directory container images are cloned into subvolume
   images with this command. Note that cloning a container or VM
   image is optimized for btrfs file systems, and might not be
   efficient on others, due to file system limitations.


The problem is that nested subvolumes like var/lib/machines becomes
tricky. If I snapshot the root subvolume, it doesn't contain
var/lib/machines. If I rollback to root.n-1 and boot that, I no longer
have var/lib/machines at all because it's now in an old unused
subvolume and not in the currently mounted path.

Can clone instead use cp -a --reflink instead of using snapshots? Can
subvolumes be entirely avoided?

Right now there is a split in Btrfs layout paradigms. The Fedora/RH
method is to create non-nested subvolumes in the (permanent) top level
subvolume (ID 5 a.k.a. ID 0), and then use fstab to mount those
subvolumes to the proper mount points in the conventional FHS we're
used to. The top level of the file system is never actually mounted by
default on Fedora. This paradigm suggests a 'machines' subvolume
should go in the top level, and an fstab entry to mount it via:

UUID=uuid   /var/lib/machines   btrfs   subvol=machines 0 0

Now, the other paradigm, is from openSUSE. The top level (subvol ID 5)
is populated like any other filesystem would be, but many of the usual
directories are instead subvolumes. There are 14 subvolumes to be
exact, and they're subvolumes for the purpose of excluding them from
the snapshotting and rolling back policies of root fs. In this
paradigm, root is the only thing being snapshot and rolled back, and
to avoid rolling back things like the journal and logs, they use
subvolumes because nested subvolumes do not get snapshot - there's no
recursive snapshotting of nested subvolumes on Btrfs.

# cat /etc/fstab
UUID=uuid swap swap defaults 0 0
UUID=uuid / btrfs defaults 0 0
UUID=uuid /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0
UUID=uuid /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0
UUID=uuid /opt btrfs subvol=opt 0 0
UUID=uuid /srv btrfs subvol=srv 0 0
UUID=uuid /tmp btrfs subvol=tmp 0 0
UUID=uuid /usr/local btrfs subvol=usr/local 0 0
UUID=uuid /var/crash btrfs subvol=var/crash 0 0
UUID=uuid /var/lib/mailman btrfs subvol=var/lib/mailman 0 0
UUID=uuid /var/lib/named btrfs subvol=var/lib/named 0 0
UUID=uuid /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0
UUID=uuid /var/log btrfs subvol=var/log 0 0
UUID=uuid /var/opt btrfs subvol=var/opt 0 0
UUID=uuid /var/spool btrfs subvol=var/spool 0 0
UUID=uuid /var/tmp btrfs subvol=var/tmp 0 0
UUID=uuid /home xfs defaults 1 2
UUID=uuid /.snapshots btrfs subvol=.snapshots 0 0

If today, on openSUSE, a hypothetical 'machines' subvolume were
created, it would most likely need to go in a /.subvolume subvolume to
keep it out of the expected FHS listing at / and this is also
consistent with the /.snapshots subvolume in which they keep
snapshots.

Therefore, it's a somewhat nested subvolume strategy, with a heavy
duty fstab to reassemble the thing, and quite substantial grub2
patches so that snapshots are visible and can be rolled back from the
boot menu.

So back to cp -a --reflink as a work around for both paradigms? Does
this method of cloning meet the requirements for systemd containers?
If so, it works on both the RH/Fedora and the openSUSE layouts.
Meaning the var/lib/machines subvolume isn't needed, just use cp -a
--reflink on either directories or files, and it's almost as fast as a
btrfs snapshot.



[1]

Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl sdio.ids in the release tarballs.

2015-03-19 Thread Marcel Holtmann

Hi Zbyszek,

On 16 March 2015 at 23:15, Marcel Holtmann mar...@holtmann.org wrote:
Hi Dimitri,

This makes it easier to apply stable branch patches on top of the
release tarball.
---
Makefile.am | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 856accb..0ed35ac 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3877,7 +3877,9 @@ dist_udevhwdb_DATA = \
hwdb/70-touchpad.hwdb

EXTRA_DIST += \
- units/systemd-hwdb-update.service.in
+ units/systemd-hwdb-update.service.in \
+ hwdb/ids-update.pl \
+ hwdb/sdio.ids

If you want to apply patches from git, then you can always tell git to
exclude these files and it will happily apply the rest of the patch. So
I do not see a good enough reason to do this.

(a) and (b) can be solved by telling 'patch' or 'git' to not apply
hunks to those files.

Looking at stable branch:

http://cgit.freedesktop.org/systemd/systemd-stable/log/hwdb?h=v219-stable

sdio.ids was changed in
http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stableid=c10e229f8222b92117ba38045ddb3e4d7951244a

but updated in a later commit
http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stableid=9ac622b00ca23f9d01e0ff0c944130be8dc3a0e9

So they do look up to date there.

usb.ids does not appear to be in the source tree.

Why not just commit ids-update.pl / sdio.ids and generate the .hwdb
files on $ make dist, or at autoreconf time?

Just tell patch or git to skip the hunks modifying ids-update.pl and
sdio.ids. Problem solved.

I'll apply the patch, but with a slightly different motivation.

that is just making stuff up. Are you now also including usb.ids?

Regards

Marcel

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

Re: [systemd-devel] not running ExecStop= when stopping activating services?

В Thu, 19 Mar 2015 15:08:39 -0400
Nekrasov, Alexander alexander.nekra...@emc.com пишет:

 Hi All,
 
 With these settings
 
 [Service]
 ExecStart=/cli run
 ExecStop=/cli stop
 Type=forking
 PIDFile=/tmp/cli.pid
 
 The service is active once cli run exits. A call to systemctl stop then 
 produces a call to cli stop. This is as expected.
 
 However if I call systemctl stop on this service before cli run exited, 
 i.e., when the service is still activating, the service is stopped, all 
 threads are killed off, but cli stop is never run.
 
 Is that as intended? Why? Is there a way to change this behavior?
 

This is intentional (see commit 3f6c78dc); I do not think intention was
as much do not run ExecStopPost as do not spend time if starting
failed anyway). There is currently no way to change it, it is
hardcoded. I guess you will need to present use case and explain what
is broken with current behavior.

Although there is obvious corner case - timeout expires exactly when
service starts and before systemd has chance to notice it. Then we have
fully started service that gets killed. 

 systemd-210-34.9.x86_64
 systemd-bash-completion-210-34.9.noarch
 systemd-rpm-macros-2-7.2.noarch
 util-linux-systemd-2.25-2.2.x86_64
 systemd-32bit-210-34.9.x86_64
 systemd-sysvinit-210-34.9.x86_64
 systemd-presets-branding-SLE-12.0-12.1.noarch
 
 Thanks,
 Alex
 ___
 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] [PATCH] resolved: Do not add .busname dependencies, when compiling without kdbus.

On 19 March 2015 at 16:29, Michael Biebl mbi...@gmail.com wrote:
 2015-03-19 17:07 GMT+01:00 David Herrmann dh.herrm...@gmail.com:
 On Thu, Mar 19, 2015 at 4:59 PM, Michael Biebl mbi...@gmail.com wrote:
 So, +1 for Dimitri's patch. Looks correct to me.
 Unless someone objects, I'm planning on merging it.

 Yes, please go ahead. I missed that .busname is not installed without
 --enable-kdbus.

 Pushed as defa8e675b2903ad53e093bb2847c7256f0779a5

 I made a small addition and added /systemd-resolved.service.m4 to .gitignore

Thanks a lot.


-- 
Regards,

Dimitri.

https://01.org/clearlinux
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] CapabilityBoundingSet vs. ExecReload (kill)

2015-03-19 Thread Nusenu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

 That tells me that the ExecReload command (kill) is also
 restricted by CapabilityBoundingSet. Is this expected [..]?
 
 recent systemd has more problems in context of systemctl and
 restricting even PID1 itself in a way no longer be able to kill
 processes

thanks for the links. so you are saying this is just a bug and indeed
not expected?

thanks,
Nusenu
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVCwGpAAoJEFv7XvVCELh0DDUP/3RF5qsT44IWEunRwnuEQELc
rnGV4LcBMf+q09r5bYTN/HG1djaKlhePgUgP3QNLFhhETDJoARcgPA9aLKJTgl0h
n3gWrgzXyM6fJ5Yhd10AmexkVqb+Nv2dV2YHPQWE2d33idaitsKbO6756bVd0xjA
xUdqIdhP094fAj+enrW1Ui93k+eIY3PxuSI+3YOXkNSBsASEqJh+sXXE2A4OWWhz
GGnRi3ufusM8w3/zRw9rXgHXExDzQ512RdIly2F3S2BTsVo84IIYqzQ7VRCneVj7
Q7eysok/nSIFH1SgpnM1iSYZqke1qLAiIUIN2FGBla3UscDT7YpWNJsDx/fJ/CQE
ZC3r55EHU2TZIk5kI/FT/Xemt+YLTXxoi0XLkHky4saj4p20cG1Ciq+ACSCgXFDd
bZD8+3u2e7Xd3AWtEb4nYAUQtDSoTMaqnVgkc0QS68S2JLUyAqA5Pj8BNSN5qWiG
gAsKDPnWQRuLpxpyMuPmqv0gMSjA8+E4rdKkPZ0mxgBMF7n5RNFleichRbYa3q5K
LHpsi6XVrqQZOVp6gQfgcbGjNzqDwRfVOw5Duu3PZU0PJp8sntYt4sbMaJQ1p98g
n6+Qtz4pW8SUgSNyQIv6B1Fk6zIJgHRZUthVayie8w1ne/pypAhmqQFUA7Dea8n3
K4BSzHEkStVZ5PZHDqhd
=tCLM
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target

2015-03-19 Thread Steve Dickson



On 03/03/2015 01:36 PM, Steve Dickson wrote:
 Its been reported that having the rpc-statd-notify service
 depend on network.target instead network-online.target
 decrease boot times as much as 10 seconds on some
 installs
 
 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293
 
 Signed-off-by: Steve Dickson ste...@redhat.com
 Reported-by: Eric Work work.e...@gmail.com
Committed...

steved.

 ---
  systemd/rpc-statd-notify.service |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/systemd/rpc-statd-notify.service 
 b/systemd/rpc-statd-notify.service
 index a655445..b608a14 100644
 --- a/systemd/rpc-statd-notify.service
 +++ b/systemd/rpc-statd-notify.service
 @@ -1,6 +1,6 @@
  [Unit]
  Description=Notify NFS peers of a restart
 -Requires=network-online.target
 +Requires=network.target
  After=network.target nss-lookup.target
  
  # if we run an nfs server, it needs to be running before we
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] missing.h: add more btrfs types and defines

2015-03-19 Thread Michael Olbrich

On Thu, Mar 19, 2015 at 02:05:00PM +0100, David Herrmann wrote:
 On Wed, Mar 18, 2015 at 2:04 PM, Michael Olbrich
 m.olbr...@pengutronix.de wrote:
  it seems we're getting a lot of btrfs stuff here. Maybe we should ship a
  copy of btrfs.h instead?
 
 All these definitions where introduced with linux-3.8 (well, the
 header was moved to linux/btrfs.h at that time). Our current
 requirement is linux-3.7. I'd just say, lets require linux-headers-3.8
 at build-time?

Actually, that would be 3.9 not 3.8. And I'd really like to avoid such a
dependency. When cross-compiling for embedded systems, a host
'systemd-hwdb' is needed to generate the hwdb. And build servers often run
older Distributions (e.g. Debian stable).

Well, what I really want, is just to build systemd-hwdb and just ignore the
whole btrfs and network stuff, that would require newer kernel headers.
However, the way the systemd build-system is set up, that's currently not
possible.

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] resolved: Do not add .busname dependencies, when compiling without kdbus.

On 19 March 2015 at 13:31, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Tue, Mar 17, 2015 at 4:37 PM, Dimitri John Ledkov
 dimitri.j.led...@intel.com wrote:
 ---
  Makefile.am  |  2 +-
  units/systemd-resolved.service.in| 29 -
  units/systemd-resolved.service.m4.in | 31 +++
  3 files changed, 32 insertions(+), 30 deletions(-)
  delete mode 100644 units/systemd-resolved.service.in
  create mode 100644 units/systemd-resolved.service.m4.in

 There is already a:
 ConditionPathExists=/sys/fs/kdbus/0-system/
 in the busname unit. Isn't that enough?


The busname unit is not installed, when compiling without kdbus. Thus
upon loading systemd-resolved.service, .busname unit is attempted to
be loaded and ends up being not found, which imho is untidy.

Regards,

Dimitri.


 Thanks
 David

 diff --git a/Makefile.am b/Makefile.am
 index 856accb..dd8b825 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -5611,7 +5611,7 @@ dist_dbussystemservice_DATA += \
 src/resolve/org.freedesktop.resolve1.service

  EXTRA_DIST += \
 -   units/systemd-resolved.service.in
 +   units/systemd-resolved.service.m4.in

  SYSTEM_UNIT_ALIASES += \
 systemd-resolved.service dbus-org.freedesktop.resolve1.service
 diff --git a/units/systemd-resolved.service.in 
 b/units/systemd-resolved.service.in
 deleted file mode 100644
 index b643da9..000
 --- a/units/systemd-resolved.service.in
 +++ /dev/null
 @@ -1,29 +0,0 @@
 -#  This file is part of systemd.
 -#
 -#  systemd is free software; you can redistribute it and/or modify it
 -#  under the terms of the GNU Lesser General Public License as published by
 -#  the Free Software Foundation; either version 2.1 of the License, or
 -#  (at your option) any later version.
 -
 -[Unit]
 -Description=Network Name Resolution
 -Documentation=man:systemd-resolved.service(8)
 -After=systemd-networkd.service network.service
 -
 -# On kdbus systems we pull in the busname explicitly, because it
 -# carries policy that allows the daemon to acquire its name.
 -Wants=org.freedesktop.resolve1.busname
 -After=org.freedesktop.resolve1.busname
 -
 -[Service]
 -Type=notify
 -Restart=always
 -RestartSec=0
 -ExecStart=@rootlibexecdir@/systemd-resolved
 -CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN 
 CAP_DAC_OVERRIDE CAP_FOWNER
 -ProtectSystem=full
 -ProtectHome=yes
 -WatchdogSec=1min
 -
 -[Install]
 -WantedBy=multi-user.target
 diff --git a/units/systemd-resolved.service.m4.in 
 b/units/systemd-resolved.service.m4.in
 new file mode 100644
 index 000..d133847
 --- /dev/null
 +++ b/units/systemd-resolved.service.m4.in
 @@ -0,0 +1,31 @@
 +#  This file is part of systemd.
 +#
 +#  systemd is free software; you can redistribute it and/or modify it
 +#  under the terms of the GNU Lesser General Public License as published by
 +#  the Free Software Foundation; either version 2.1 of the License, or
 +#  (at your option) any later version.
 +
 +[Unit]
 +Description=Network Name Resolution
 +Documentation=man:systemd-resolved.service(8)
 +After=systemd-networkd.service network.service
 +
 +m4_ifdef(`ENABLE_KDBUS',
 +# On kdbus systems we pull in the busname explicitly, because it
 +# carries policy that allows the daemon to acquire its name.
 +Wants=org.freedesktop.resolve1.busname
 +After=org.freedesktop.resolve1.busname
 +
 +)m4_dnl
 +[Service]
 +Type=notify
 +Restart=always
 +RestartSec=0
 +ExecStart=@rootlibexecdir@/systemd-resolved
 +CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN 
 CAP_DAC_OVERRIDE CAP_FOWNER
 +ProtectSystem=full
 +ProtectHome=yes
 +WatchdogSec=1min
 +
 +[Install]
 +WantedBy=multi-user.target
 --
 2.1.0

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



-- 
Regards,

Dimitri.

https://01.org/clearlinux
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] missing.h: add more btrfs types and defines

Hi

On Wed, Mar 18, 2015 at 2:04 PM, Michael Olbrich
m.olbr...@pengutronix.de wrote:
 ---

 Hi,

 it seems we're getting a lot of btrfs stuff here. Maybe we should ship a
 copy of btrfs.h instead?

All these definitions where introduced with linux-3.8 (well, the
header was moved to linux/btrfs.h at that time). Our current
requirement is linux-3.7. I'd just say, lets require linux-headers-3.8
at build-time?

Thanks
David

 Michael

  src/shared/missing.h | 151 
 +++
  1 file changed, 151 insertions(+)

 diff --git a/src/shared/missing.h b/src/shared/missing.h
 index 802b4957e0a1..ca670cea43f7 100644
 --- a/src/shared/missing.h
 +++ b/src/shared/missing.h
 @@ -230,12 +230,59 @@ static inline int getrandom(void *buffer, size_t count, 
 unsigned flags) {
  #define BTRFS_UUID_SIZE 16
  #endif

 +#ifndef BTRFS_SUBVOL_RDONLY
 +#define BTRFS_SUBVOL_RDONLY (1ULL  1)
 +#endif
 +
 +#ifndef BTRFS_SUBVOL_NAME_MAX
 +#define BTRFS_SUBVOL_NAME_MAX 4039
 +#endif
 +
 +#ifndef BTRFS_INO_LOOKUP_PATH_MAX
 +#define BTRFS_INO_LOOKUP_PATH_MAX 4080
 +#endif
 +
 +#ifndef BTRFS_SEARCH_ARGS_BUFSIZE
 +#define BTRFS_SEARCH_ARGS_BUFSIZE (4096 - sizeof(struct 
 btrfs_ioctl_search_key))
 +#endif
 +
  #ifndef HAVE_LINUX_BTRFS_H
  struct btrfs_ioctl_vol_args {
  int64_t fd;
  char name[BTRFS_PATH_NAME_MAX + 1];
  };

 +struct btrfs_qgroup_limit {
 +__u64 flags;
 +__u64 max_rfer;
 +__u64 max_excl;
 +__u64 rsv_rfer;
 +__u64 rsv_excl;
 +};
 +
 +struct btrfs_qgroup_inherit {
 +__u64 flags;
 +__u64 num_qgroups;
 +__u64 num_ref_copies;
 +__u64 num_excl_copies;
 +struct btrfs_qgroup_limit lim;
 +__u64 qgroups[0];
 +};
 +
 +struct btrfs_ioctl_vol_args_v2 {
 +__s64 fd;
 +__u64 transid;
 +__u64 flags;
 +union {
 +struct {
 +__u64 size;
 +struct btrfs_qgroup_inherit *qgroup_inherit;
 +};
 +__u64 unused[4];
 +};
 +char name[BTRFS_SUBVOL_NAME_MAX + 1];
 +};
 +
  struct btrfs_ioctl_dev_info_args {
  uint64_t devid; /* in/out */
  uint8_t uuid[BTRFS_UUID_SIZE];  /* in/out */
 @@ -251,6 +298,68 @@ struct btrfs_ioctl_fs_info_args {
  uint8_t fsid[BTRFS_FSID_SIZE];  /* out */
  uint64_t reserved[124]; /* pad to 1k */
  };
 +
 +struct btrfs_ioctl_ino_lookup_args {
 +__u64 treeid;
 +__u64 objectid;
 +char name[BTRFS_INO_LOOKUP_PATH_MAX];
 +};
 +
 +struct btrfs_ioctl_search_key {
 +/* which root are we searching.  0 is the tree of tree roots */
 +__u64 tree_id;
 +
 +/* keys returned will be = min and = max */
 +__u64 min_objectid;
 +__u64 max_objectid;
 +
 +/* keys returned will be = min and = max */
 +__u64 min_offset;
 +__u64 max_offset;
 +
 +/* max and min transids to search for */
 +__u64 min_transid;
 +__u64 max_transid;
 +
 +/* keys returned will be = min and = max */
 +__u32 min_type;
 +__u32 max_type;
 +
 +/*
 + * how many items did userland ask for, and how many are we
 + * returning
 + */
 +__u32 nr_items;
 +
 +/* align to 64 bits */
 +__u32 unused;
 +
 +/* some extra for later */
 +__u64 unused1;
 +__u64 unused2;
 +__u64 unused3;
 +__u64 unused4;
 +};
 +
 +struct btrfs_ioctl_search_header {
 +__u64 transid;
 +__u64 objectid;
 +__u64 offset;
 +__u32 type;
 +__u32 len;
 +};
 +
 +
 +struct btrfs_ioctl_search_args {
 +struct btrfs_ioctl_search_key key;
 +char buf[BTRFS_SEARCH_ARGS_BUFSIZE];
 +};
 +
 +struct btrfs_ioctl_clone_range_args {
 +__s64 src_fd;
 +__u64 src_offset, src_length;
 +__u64 dest_offset;
 +};
  #endif

  #ifndef BTRFS_IOC_DEFRAG
 @@ -258,6 +367,48 @@ struct btrfs_ioctl_fs_info_args {
   struct btrfs_ioctl_vol_args)
  #endif

 +#ifndef BTRFS_IOC_CLONE
 +#define BTRFS_IOC_CLONE _IOW(BTRFS_IOCTL_MAGIC, 9, int)
 +#endif
 +
 +#ifndef BTRFS_IOC_CLONE_RANGE
 +#define BTRFS_IOC_CLONE_RANGE _IOW(BTRFS_IOCTL_MAGIC, 13, \
 + struct btrfs_ioctl_clone_range_args)
 +#endif
 +
 +#ifndef BTRFS_IOC_SUBVOL_CREATE
 +#define BTRFS_IOC_SUBVOL_CREATE _IOW(BTRFS_IOCTL_MAGIC, 14, \
 + struct btrfs_ioctl_vol_args)
 +#endif
 +
 +#ifndef BTRFS_IOC_SNAP_DESTROY
 +#define BTRFS_IOC_SNAP_DESTROY _IOW(BTRFS_IOCTL_MAGIC, 15, \
 + struct btrfs_ioctl_vol_args)
 +#endif
 +
 +#ifndef BTRFS_IOC_TREE_SEARCH
 +#define BTRFS_IOC_TREE_SEARCH _IOWR(BTRFS_IOCTL_MAGIC, 17, \
 + struct btrfs_ioctl_search_args)
 +#endif
 +
 +#ifndef

Re: [systemd-devel] [PATCH] resolved: Do not add .busname dependencies, when compiling without kdbus.

Hi

On Tue, Mar 17, 2015 at 4:37 PM, Dimitri John Ledkov
dimitri.j.led...@intel.com wrote:
 ---
  Makefile.am  |  2 +-
  units/systemd-resolved.service.in| 29 -
  units/systemd-resolved.service.m4.in | 31 +++
  3 files changed, 32 insertions(+), 30 deletions(-)
  delete mode 100644 units/systemd-resolved.service.in
  create mode 100644 units/systemd-resolved.service.m4.in

There is already a:
ConditionPathExists=/sys/fs/kdbus/0-system/
in the busname unit. Isn't that enough?

Thanks
David

 diff --git a/Makefile.am b/Makefile.am
 index 856accb..dd8b825 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -5611,7 +5611,7 @@ dist_dbussystemservice_DATA += \
 src/resolve/org.freedesktop.resolve1.service

  EXTRA_DIST += \
 -   units/systemd-resolved.service.in
 +   units/systemd-resolved.service.m4.in

  SYSTEM_UNIT_ALIASES += \
 systemd-resolved.service dbus-org.freedesktop.resolve1.service
 diff --git a/units/systemd-resolved.service.in 
 b/units/systemd-resolved.service.in
 deleted file mode 100644
 index b643da9..000
 --- a/units/systemd-resolved.service.in
 +++ /dev/null
 @@ -1,29 +0,0 @@
 -#  This file is part of systemd.
 -#
 -#  systemd is free software; you can redistribute it and/or modify it
 -#  under the terms of the GNU Lesser General Public License as published by
 -#  the Free Software Foundation; either version 2.1 of the License, or
 -#  (at your option) any later version.
 -
 -[Unit]
 -Description=Network Name Resolution
 -Documentation=man:systemd-resolved.service(8)
 -After=systemd-networkd.service network.service
 -
 -# On kdbus systems we pull in the busname explicitly, because it
 -# carries policy that allows the daemon to acquire its name.
 -Wants=org.freedesktop.resolve1.busname
 -After=org.freedesktop.resolve1.busname
 -
 -[Service]
 -Type=notify
 -Restart=always
 -RestartSec=0
 -ExecStart=@rootlibexecdir@/systemd-resolved
 -CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN 
 CAP_DAC_OVERRIDE CAP_FOWNER
 -ProtectSystem=full
 -ProtectHome=yes
 -WatchdogSec=1min
 -
 -[Install]
 -WantedBy=multi-user.target
 diff --git a/units/systemd-resolved.service.m4.in 
 b/units/systemd-resolved.service.m4.in
 new file mode 100644
 index 000..d133847
 --- /dev/null
 +++ b/units/systemd-resolved.service.m4.in
 @@ -0,0 +1,31 @@
 +#  This file is part of systemd.
 +#
 +#  systemd is free software; you can redistribute it and/or modify it
 +#  under the terms of the GNU Lesser General Public License as published by
 +#  the Free Software Foundation; either version 2.1 of the License, or
 +#  (at your option) any later version.
 +
 +[Unit]
 +Description=Network Name Resolution
 +Documentation=man:systemd-resolved.service(8)
 +After=systemd-networkd.service network.service
 +
 +m4_ifdef(`ENABLE_KDBUS',
 +# On kdbus systems we pull in the busname explicitly, because it
 +# carries policy that allows the daemon to acquire its name.
 +Wants=org.freedesktop.resolve1.busname
 +After=org.freedesktop.resolve1.busname
 +
 +)m4_dnl
 +[Service]
 +Type=notify
 +Restart=always
 +RestartSec=0
 +ExecStart=@rootlibexecdir@/systemd-resolved
 +CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN 
 CAP_DAC_OVERRIDE CAP_FOWNER
 +ProtectSystem=full
 +ProtectHome=yes
 +WatchdogSec=1min
 +
 +[Install]
 +WantedBy=multi-user.target
 --
 2.1.0

 ___
 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] [PATCH] timedated: Add a LocalOffset property for timezone offset

Hi

On Thu, Mar 19, 2015 at 11:24 AM, Stef Walter st...@redhat.com wrote:
 This property is in usec (like the TimeUSec property) and allows
 retrieving the timezone offset for the machine. This is particularly
 usable for remote callers.
 ---
  src/timedate/timedated.c | 20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

 diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
 index ca771d5..e384b36 100644
 --- a/src/timedate/timedated.c
 +++ b/src/timedate/timedated.c
 @@ -361,6 +361,22 @@ static int property_get_time(
  return sd_bus_message_append(reply, t, now(CLOCK_REALTIME));
  }

 +static int property_get_local_offset(
 +sd_bus *bus,
 +const char *path,
 +const char *interface,
 +const char *property,
 +sd_bus_message *reply,
 +void *userdata,
 +sd_bus_error *error)
 +{
 +struct tm *tm;
 +time_t dummy = 0;
 +
 +assert_se(tm = localtime(dummy));
 +return sd_bus_message_append(reply, t, (uint64_t)(tm-tm_gmtoff * 
 100));
 +}
 +

Hmm, so this is a convenience call. You could just set tm.tm_zone
locally and use mktime() with the value retrieved by Timezone? Yeah,
the time-api is awful with global variables, but that's not really our
fault, is it?

I'm not really against this bus-call, but I also don't see the point.
There's much more information in a timezone file than the offset, so
why expose the offset but not the other data?

Thanks
David

  static int property_get_ntp_sync(
  sd_bus *bus,
  const char *path,
 @@ -440,7 +456,8 @@ static int method_set_timezone(sd_bus *bus, 
 sd_bus_message *m, void *userdata, s
 LOG_MESSAGE(Changed time zone to '%s'., c-zone),
 NULL);

 -sd_bus_emit_properties_changed(bus, /org/freedesktop/timedate1, 
 org.freedesktop.timedate1, Timezone, NULL);
 +sd_bus_emit_properties_changed(bus, /org/freedesktop/timedate1, 
 org.freedesktop.timedate1,
 +   Timezone, LocalOffset, NULL);

  return sd_bus_reply_method_return(m, NULL);
  }
 @@ -666,6 +683,7 @@ static int method_set_ntp(sd_bus *bus, sd_bus_message *m, 
 void *userdata, sd_bus
  static const sd_bus_vtable timedate_vtable[] = {
  SD_BUS_VTABLE_START(0),
  SD_BUS_PROPERTY(Timezone, s, NULL, offsetof(Context, zone), 
 SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
 +SD_BUS_PROPERTY(LocalOffset, t, property_get_local_offset, 0, 
 SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
  SD_BUS_PROPERTY(LocalRTC, b, bus_property_get_bool, 
 offsetof(Context, local_rtc), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
  SD_BUS_PROPERTY(CanNTP, b, bus_property_get_bool, 
 offsetof(Context, can_ntp), 0),
  SD_BUS_PROPERTY(NTP, b, bus_property_get_bool, offsetof(Context, 
 use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
 --
 2.3.3

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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

2015-03-19 Thread Stef Walter

On 19.03.2015 14:39, David Herrmann wrote:
 Hi
 
 On Thu, Mar 19, 2015 at 11:24 AM, Stef Walter st...@redhat.com wrote:
 This property is in usec (like the TimeUSec property) and allows
 retrieving the timezone offset for the machine. This is particularly
 usable for remote callers.
 ---
  src/timedate/timedated.c | 20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

 diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
 index ca771d5..e384b36 100644
 --- a/src/timedate/timedated.c
 +++ b/src/timedate/timedated.c
 @@ -361,6 +361,22 @@ static int property_get_time(
  return sd_bus_message_append(reply, t, now(CLOCK_REALTIME));
  }

 +static int property_get_local_offset(
 +sd_bus *bus,
 +const char *path,
 +const char *interface,
 +const char *property,
 +sd_bus_message *reply,
 +void *userdata,
 +sd_bus_error *error)
 +{
 +struct tm *tm;
 +time_t dummy = 0;
 +
 +assert_se(tm = localtime(dummy));
 +return sd_bus_message_append(reply, t, (uint64_t)(tm-tm_gmtoff * 
 100));
 +}
 +
 
 Hmm, so this is a convenience call. You could just set tm.tm_zone
 locally and use mktime() with the value retrieved by Timezone? Yeah,
 the time-api is awful with global variables, but that's not really our
 fault, is it?
 
 I'm not really against this bus-call, but I also don't see the point.

In Cockpit we're running on a different machine, and accessing timedated
remotely. If this information is not available in timedated, we would
need to add another DBus service to expose this information.

Besides it fits in well with the TimeUSec property.

 There's much more information in a timezone file than the offset, so
 why expose the offset but not the other data?

I would like to be able to do 'timedatectl list-timezones' over DBus as
well.

Such work would allow timedatectl to work properly with the --host
argument. Currently the output of 'timedatectl status
--host=machine-in-another-timezone.example.com' is full of invalid
information.

Stef



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] Boot ordering

On Thu, Mar 19, 2015 at 4:27 PM, Christoph Pleger
christoph.ple...@cs.tu-dortmund.de wrote:
 Hello,

 Then, I still do not understand why my definition of a new target did
 not
 work. What is the difference between multi-user.target waiting for
 basic.target on the one hand and new.target waiting for basic.target and
 multi-user.target waiting for new.target on the other hand, aside from
 that one intermediate step?


 Everything else that is ordered before multi-user.target is started
 concurrently with your new.target.

 Hm. But I have no idea why for example gdm3 is started while my test
 script is still executing its sleep command.

Because gdm3 has no ordering dependencies against your test script so
both are scheduled to be started concurrently. Which one will be first
is more or less random.

   This is the output of
 systemd-analyze dot | grep gdm:

 shutdown.target-gdm.service [color=green];
 shutdown.target-gdm.service [color=red];
 graphical.target-gdm.service [color=grey66];
 x-display-manager.target-gdm.service [color=green];
 x-display-manager.target-gdm.service [color=black];
 gdm.service-systemd-user-sessions.service [color=green];
 gdm.service-getty@tty7.service [color=green];
 gdm.service-plymouth-quit.service [color=green];
 gdm.service-systemd-journald.socket [color=green];
 gdm.service-basic.target [color=green];
 gdm.service-system.slice [color=green];
 gdm.service-basic.target [color=black];
 gdm.service-x-display-manager.target [color=grey66];
 gdm.service-system.slice [color=grey66];
 gdm.service-getty@tty7.service [color=red];
 gdm.service-plymouth-quit.service [color=red];
 gdm.service-shutdown.target [color=red];
 getty@tty7.service-gdm.service [color=red];
 plymouth-quit.service-gdm.service [color=red];
 plymouth-halt.service-gdm.service [color=green];
 plymouth-reboot.service-gdm.service [color=green];
Color legend: black = Requires
  dark blue = Requisite
  dark grey = Wants
  red   = Conflicts
  green = After

 If I understand this correctly, gdm is pulled into the boot process only
 by graphical.target, which according to target unit definitions should be
 after multi-user.target , which should be after my new.target ...


You seem to misunderstand what target does. Target simply tells
systemd if you start me, start also these other services. Those
other services are started as soon as possible. Ordering of target
units has absolutely no relation to startup order of other services.

 The only thing I can imagine what causes my problem is that Debian jessie
 does not use only systemd units, but also init scripts in /etc/rc*.d/ and
 that this brakes my desired boot order.

 Regards
   Christoph


 ___
 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] [PATCH] timedated: Add a LocalOffset property for timezone offset

Hi

On Thu, Mar 19, 2015 at 2:58 PM, Stef Walter st...@redhat.com wrote:
 On 19.03.2015 14:39, David Herrmann wrote:
 Hmm, so this is a convenience call. You could just set tm.tm_zone
 locally and use mktime() with the value retrieved by Timezone? Yeah,
 the time-api is awful with global variables, but that's not really our
 fault, is it?

 I'm not really against this bus-call, but I also don't see the point.

 In Cockpit we're running on a different machine, and accessing timedated
 remotely. If this information is not available in timedated, we would
 need to add another DBus service to expose this information.

 Besides it fits in well with the TimeUSec property.

But TimeUSec is UTC. If you retrieve TimeUSec and Timezone, you
can reconstruct the time offset yourself, without any further
information, right?

 There's much more information in a timezone file than the offset, so
 why expose the offset but not the other data?

 I would like to be able to do 'timedatectl list-timezones' over DBus as
 well.

Why? This information should be the same on all machines, right? I
don't see why the remote list is of any interest.

 Such work would allow timedatectl to work properly with the --host
 argument. Currently the output of 'timedatectl status
 --host=machine-in-another-timezone.example.com' is full of invalid
 information.

Yes, but it's the job of timedatectl to print information in the
timezone of the remote host, not of the local host. It should retrieve
the Timezone field and modify it's local timezone if you want the
information to be relative to remote timezone, not the local timezone
(which I'm not sure you really want).

What exactly do you mean with full of invalid information?

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

Re: [systemd-devel] [PATCH] Create journal-remote.conf.xml to document the format of the configuration file for systemd-journal-remote

2015-03-19 Thread Chris Morgan

On Thu, Mar 19, 2015 at 9:23 AM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Mon, Mar 16, 2015 at 1:49 PM, Chris Morgan chmor...@gmail.com wrote:
 ---
  man/journal-remote.conf.xml| 111 
 +
  man/systemd-journal-remote.xml |   1 +
  2 files changed, 112 insertions(+)
  create mode 100644 man/journal-remote.conf.xml

 diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
 new file mode 100644
 index 000..84e07ee
 --- /dev/null
 +++ b/man/journal-remote.conf.xml
 @@ -0,0 +1,111 @@
 +?xml version='1.0'? !--*-nxml-*--
 +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN
 +  http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
 +
 +!--
 +  This file is part of systemd.
 +
 +  Copyright 2015 Chris Morgan
 +
 +  systemd is free software; you can redistribute it and/or modify it
 +  under the terms of the GNU Lesser General Public License as published by
 +  the Free Software Foundation; either version 2.1 of the License, or
 +  (at your option) any later version.
 +
 +  systemd is distributed in the hope that it will be useful, but
 +  WITHOUT ANY WARRANTY; without even the implied warranty of
 +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 +  Lesser General Public License for more details.
 +
 +  You should have received a copy of the GNU Lesser General Public License
 +  along with systemd; If not, see http://www.gnu.org/licenses/.
 +--
 +
 +refentry id=journal-remote.conf
 +xmlns:xi=http://www.w3.org/2001/XInclude;
 +  refentryinfo
 +titlejournal-remote.conf/title
 +productnamesystemd/productname
 +
 +authorgroup
 +  author
 +contribDeveloper/contrib
 +firstnameChris/firstname
 +surnameMorgan/surname
 +emailchmor...@gmail.com/email
 +  /author
 +/authorgroup
 +  /refentryinfo
 +
 +  refmeta
 +refentrytitlejournal-remote.conf/refentrytitle
 +manvolnum5/manvolnum
 +  /refmeta
 +
 +  refnamediv
 +refnamejournal-remote.conf/refname

 missing:
 refnamejournal-remote.conf.d/refname

 +refpurposeJournal remote service configuration files/refpurpose
 +  /refnamediv
 +
 +  refsynopsisdiv
 +parafilename/etc/systemd/journal-remote.conf/filename/para
 +parafilename/etc/journal-remote.conf/filename/para
 +parafilename/run/journal-remote.conf/filename/para
 +parafilename/usr/local/lib/journal-remote.conf/filename/para
 +parafilename/usr/lib/journal-remote.conf/filename/para

 Where do all these come from? Shouldn't these be the same as in
 journal.conf.xml? Have a look at the CONF_DIRS_NULSTR macro in
 src/shared/macro.h, which defines the lookup directories.

 +  /refsynopsisdiv
 +
 +  refsect1
 +titleDescription/title
 +
 +paraThese files configure various parameters of the 
 systemd-remote-journal
 +application,
 +
 citerefentryrefentrytitlesystemd-journal-remote/refentrytitlemanvolnum8/manvolnum/citerefentry./para
 +
 +  /refsect1
 +

 How about:
 xi:include href=standard-conf.xml xpointer=main-conf /

 +  refsect1
 +titleOptions/title
 +
 +paraAll options are configured in the
 +literal[Journal]/literal section:/para

 The section is called [Remote].

 +
 +variablelist
 +
 +  varlistentry
 +termvarnameSplitMode=/varname/term
 +
 +listitemparaOne of literalhost/literal or 
 literalnone/literal.
 +/para/listitem
 +  /varlistentry
 +
 +  varlistentry
 +termvarnameServerKeyFile=/varname/term
 +
 +listitemparaSSL key in PEM format/para/listitem
 +  /varlistentry
 +
 +  varlistentry
 +termvarnameServerCertificateFile=/varname/term
 +
 +listitemparaSSL CA certificate in PEM format./para/listitem
 +  /varlistentry
 +
 +  varlistentry
 +termvarnameTrustedCertificateFile=/varname/term
 +
 +listitemparaSSL CA certificate./para/listitem
 +  /varlistentry
 +
 +/variablelist

 A bit short, but better than nothing, so I wouldn't mind applying it.
 Maybe Zbigniew can amend some more information.

 +
 +  /refsect1
 +
 +  refsect1
 +  titleSee Also/title
 +  para
 +
 citerefentryrefentrytitlesystemd-journal-remote/refentrytitlemanvolnum1/manvolnum/citerefentry

 I'd add some more entries here, including systemd(1) and systemd-journald(1).

 Otherwise looks good. I'll leave this to Zbigniew, though. I have not
 much clue of how journal-remote works, sorry!

 Thanks
 David

 +  /para
 +  /refsect1
 +
 +/refentry
 diff --git a/man/systemd-journal-remote.xml b/man/systemd-journal-remote.xml
 index 2687662..d5bda63 100644
 --- a/man/systemd-journal-remote.xml
 +++ b/man/systemd-journal-remote.xml
 @@ -310,6 +310,7 @@ systemd-journal-remote --url http://some.host:19531/

 citerefentryrefentrytitlejournalctl/refentrytitlemanvolnum1/manvolnum/citerefentry,

 citerefentryrefentrytitlesystemd-journald.service/refentrytitlemanvolnum8/manvolnum/citerefentry,

Re: [systemd-devel] [PATCH] Create journal-remote.conf.xml to document the format of the configuration file for systemd-journal-remote

Hi

On Mon, Mar 16, 2015 at 1:49 PM, Chris Morgan chmor...@gmail.com wrote:
 ---
  man/journal-remote.conf.xml| 111 
 +
  man/systemd-journal-remote.xml |   1 +
  2 files changed, 112 insertions(+)
  create mode 100644 man/journal-remote.conf.xml

 diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
 new file mode 100644
 index 000..84e07ee
 --- /dev/null
 +++ b/man/journal-remote.conf.xml
 @@ -0,0 +1,111 @@
 +?xml version='1.0'? !--*-nxml-*--
 +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN
 +  http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
 +
 +!--
 +  This file is part of systemd.
 +
 +  Copyright 2015 Chris Morgan
 +
 +  systemd is free software; you can redistribute it and/or modify it
 +  under the terms of the GNU Lesser General Public License as published by
 +  the Free Software Foundation; either version 2.1 of the License, or
 +  (at your option) any later version.
 +
 +  systemd is distributed in the hope that it will be useful, but
 +  WITHOUT ANY WARRANTY; without even the implied warranty of
 +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 +  Lesser General Public License for more details.
 +
 +  You should have received a copy of the GNU Lesser General Public License
 +  along with systemd; If not, see http://www.gnu.org/licenses/.
 +--
 +
 +refentry id=journal-remote.conf
 +xmlns:xi=http://www.w3.org/2001/XInclude;
 +  refentryinfo
 +titlejournal-remote.conf/title
 +productnamesystemd/productname
 +
 +authorgroup
 +  author
 +contribDeveloper/contrib
 +firstnameChris/firstname
 +surnameMorgan/surname
 +emailchmor...@gmail.com/email
 +  /author
 +/authorgroup
 +  /refentryinfo
 +
 +  refmeta
 +refentrytitlejournal-remote.conf/refentrytitle
 +manvolnum5/manvolnum
 +  /refmeta
 +
 +  refnamediv
 +refnamejournal-remote.conf/refname

missing:
refnamejournal-remote.conf.d/refname

 +refpurposeJournal remote service configuration files/refpurpose
 +  /refnamediv
 +
 +  refsynopsisdiv
 +parafilename/etc/systemd/journal-remote.conf/filename/para
 +parafilename/etc/journal-remote.conf/filename/para
 +parafilename/run/journal-remote.conf/filename/para
 +parafilename/usr/local/lib/journal-remote.conf/filename/para
 +parafilename/usr/lib/journal-remote.conf/filename/para

Where do all these come from? Shouldn't these be the same as in
journal.conf.xml? Have a look at the CONF_DIRS_NULSTR macro in
src/shared/macro.h, which defines the lookup directories.

 +  /refsynopsisdiv
 +
 +  refsect1
 +titleDescription/title
 +
 +paraThese files configure various parameters of the 
 systemd-remote-journal
 +application,
 +
 citerefentryrefentrytitlesystemd-journal-remote/refentrytitlemanvolnum8/manvolnum/citerefentry./para
 +
 +  /refsect1
 +

How about:
xi:include href=standard-conf.xml xpointer=main-conf /

 +  refsect1
 +titleOptions/title
 +
 +paraAll options are configured in the
 +literal[Journal]/literal section:/para

The section is called [Remote].

 +
 +variablelist
 +
 +  varlistentry
 +termvarnameSplitMode=/varname/term
 +
 +listitemparaOne of literalhost/literal or 
 literalnone/literal.
 +/para/listitem
 +  /varlistentry
 +
 +  varlistentry
 +termvarnameServerKeyFile=/varname/term
 +
 +listitemparaSSL key in PEM format/para/listitem
 +  /varlistentry
 +
 +  varlistentry
 +termvarnameServerCertificateFile=/varname/term
 +
 +listitemparaSSL CA certificate in PEM format./para/listitem
 +  /varlistentry
 +
 +  varlistentry
 +termvarnameTrustedCertificateFile=/varname/term
 +
 +listitemparaSSL CA certificate./para/listitem
 +  /varlistentry
 +
 +/variablelist

A bit short, but better than nothing, so I wouldn't mind applying it.
Maybe Zbigniew can amend some more information.

 +
 +  /refsect1
 +
 +  refsect1
 +  titleSee Also/title
 +  para
 +
 citerefentryrefentrytitlesystemd-journal-remote/refentrytitlemanvolnum1/manvolnum/citerefentry

I'd add some more entries here, including systemd(1) and systemd-journald(1).

Otherwise looks good. I'll leave this to Zbigniew, though. I have not
much clue of how journal-remote works, sorry!

Thanks
David

 +  /para
 +  /refsect1
 +
 +/refentry
 diff --git a/man/systemd-journal-remote.xml b/man/systemd-journal-remote.xml
 index 2687662..d5bda63 100644
 --- a/man/systemd-journal-remote.xml
 +++ b/man/systemd-journal-remote.xml
 @@ -310,6 +310,7 @@ systemd-journal-remote --url http://some.host:19531/

 citerefentryrefentrytitlejournalctl/refentrytitlemanvolnum1/manvolnum/citerefentry,

 citerefentryrefentrytitlesystemd-journald.service/refentrytitlemanvolnum8/manvolnum/citerefentry,

Re: [systemd-devel] Boot ordering

Hello,

 Then, I still do not understand why my definition of a new target did
 not
 work. What is the difference between multi-user.target waiting for
 basic.target on the one hand and new.target waiting for basic.target and
 multi-user.target waiting for new.target on the other hand, aside from
 that one intermediate step?


 Everything else that is ordered before multi-user.target is started
 concurrently with your new.target.

Hm. But I have no idea why for example gdm3 is started while my test
script is still executing its sleep command. This is the output of
systemd-analyze dot | grep gdm:

shutdown.target-gdm.service [color=green];
shutdown.target-gdm.service [color=red];
graphical.target-gdm.service [color=grey66];
x-display-manager.target-gdm.service [color=green];
x-display-manager.target-gdm.service [color=black];
gdm.service-systemd-user-sessions.service [color=green];
gdm.service-getty@tty7.service [color=green];
gdm.service-plymouth-quit.service [color=green];
gdm.service-systemd-journald.socket [color=green];
gdm.service-basic.target [color=green];
gdm.service-system.slice [color=green];
gdm.service-basic.target [color=black];
gdm.service-x-display-manager.target [color=grey66];
gdm.service-system.slice [color=grey66];
gdm.service-getty@tty7.service [color=red];
gdm.service-plymouth-quit.service [color=red];
gdm.service-shutdown.target [color=red];
getty@tty7.service-gdm.service [color=red];
plymouth-quit.service-gdm.service [color=red];
plymouth-halt.service-gdm.service [color=green];
plymouth-reboot.service-gdm.service [color=green];
   Color legend: black = Requires
 dark blue = Requisite
 dark grey = Wants
 red   = Conflicts
 green = After

If I understand this correctly, gdm is pulled into the boot process only
by graphical.target, which according to target unit definitions should be
after multi-user.target , which should be after my new.target ...

The only thing I can imagine what causes my problem is that Debian jessie
does not use only systemd units, but also init scripts in /etc/rc*.d/ and
that this brakes my desired boot order.

Regards
  Christoph


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

Re: [systemd-devel] machinectl login system: Failed to get machine PTY: Unit container-getty@0.service failed to load: No such file or directory.

Hi

On Tue, Mar 17, 2015 at 4:54 PM, Peter Paule systemd-de...@fedux.org wrote:
 Hi,

 starting a container works fine. I'm running now systemd from git. Last
 commit is 1b41981d9a62443d566df6bcabc1b5024e9f5e4a which changes things with
 container-getty.

   $ sudo machinectl start test-server

   $ sudo machinectl status test-server
   test-server
  Since: Tue 2015-03-17 16:41:34 CET; 3s ago
 Leader: 707 (systemd)
Service: nspawn; class container
   Root: /var/lib/machines/test-server
  Iface: ve-test-server
 OS: CentOS Linux 7 (Core)
   Unit: systemd-nspawn@test\x2dserver.service
 ├─706 /usr/bin/systemd-nspawn --quiet --keep-unit --boot
 --link-journal=try-guest --network-veth --machine=test-server
 ├─707 /usr/lib/systemd/systemd
 └─system.slice
   ├─dbus.service
   │ └─751 /bin/dbus-daemon --system --address=systemd:
 --nofork --nopidfile --systemd-activation
   ├─systemd-journald.service
   │ └─724 /usr/lib/systemd/systemd-journald
   ├─systemd-logind.service
   │ └─750 /usr/lib/systemd/systemd-logind
   ├─console-getty.service
   │ └─757 /sbin/agetty --noclear -s console 115200 38400
 9600
   └─rails-app.service
 └─749 /usr/local/bin/ruby script/rails server

   Mar 17 16:41:35 test1.ib.vrnetze.de systemd-nspawn[706]: Starting Console
 Getty...
   Mar 17 16:41:35 test1.ib.vrnetze.de systemd-nspawn[706]: [  OK  ] Started
 Console Getty.
   Mar 17 16:41:35 test1.ib.vrnetze.de systemd-nspawn[706]: [  OK  ] Reached
 target Login Prompts.
   Mar 17 16:41:35 test1.ib.vrnetze.de systemd-nspawn[706]: [  OK  ] Started
 Dump dmesg to /var/log/dmesg.
   Mar 17 16:41:35 test1.ib.vrnetze.de systemd-nspawn[706]: [  OK  ] Started
 Login Service.
   Mar 17 16:41:36 test1.ib.vrnetze.de systemd-nspawn[706]: [FAILED] Failed
 to start LSB: Bring up/down networking.
   Mar 17 16:41:36 test1.ib.vrnetze.de systemd-nspawn[706]: See 'systemctl
 status network.service' for details.
   Mar 17 16:41:36 test1.ib.vrnetze.de systemd-nspawn[706]: [  OK  ] Reached
 target Multi-User System.
   Mar 17 16:41:36 test1.ib.vrnetze.de systemd-nspawn[706]: CentOS Linux 7
 (Core)
   Mar 17 16:41:36 test1.ib.vrnetze.de systemd-nspawn[706]: Kernel
 3.18.6-1-ARCH on an x86_64


 But when I tried to login I get the following error message:

   $ sudo machinectl login test-server
   Failed to get machine PTY: Unit container-getty@0.service failed to load:
 No such file or directory.

The file container-getty@.service is available in your container?
/sbin/agetty is available in your container?

Thanks
David

 I would like to troubleshoot

   Mar 17 16:41:36 test1.ib.vrnetze.de systemd-nspawn[706]: [FAILED] Failed
 to start LSB: Bring up/down networking.
   Mar 17 16:41:36 test1.ib.vrnetze.de systemd-nspawn[706]: See 'systemctl
 status network.service' for details.

 Is there another way to get a login prompt or fix the error above?

 /pp


 ___
 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] Needs help for on charging activation

Hi

On Mon, Mar 9, 2015 at 3:21 PM, WaLyong Cho walyong@samsung.com wrote:
 Hi,

 I want to find best solution on our case. Our product is mobile device.
 But I don't think that is only problem of mobile device. That also can
 be problem of laptop. So, please comment to me.

 We have some of services are always running after system is started up
 as default. They don't need to be running always. They are just needed
 only charger is plugged in.
 So I thought lets only active them when only charger is plugged in.

 I thought two methods.

 method 1:
 Charger also can be detected by udev. So udev hardware activation can be
 used.
 I wrote below udev rules.

 SUBSYSTEM==power_supply, ENV{POWER_SUPPLY_CHARGE_NOW}==1,
 TAG+=systemd, ENV{SYSTEMD_WANTS}+=foo.service

I guess the problem is, the .device unit is never stopped. Therefore,
when you unplug it, it will not be stopped, as the device is still
there.

You could try this:

SUBSYSTEM==power_supply, ENV{POWER_SUPPLY_CHARGE_NOW}==1, \
TAG+=systemd, ENV{SYSTEMD_WANTS}+=foo.service, \
ENV{SYSTEMD_READY}=1

SUBSYSTEM==power_supply, ENV{POWER_SUPPLY_CHARGE_NOW}==0, \
ENV{SYSTEMD_READY}=0

It's not particularly nice, as other dependencies on the power-supply
device will now be borked. But as a hack it should work.

I cannot think of a better way to support udev-activation based on
attribute-changes. We never explicitly supported it. Hmm..

Thanks
David

 It looked working well. foo.service is only activated when charger was
 plugged in.
 But I have some of problems with hardware activation.
 I want to be stopped foo.service when the charger is plugged out. As I
 know, this is impossible with udev hardware activation.
 To do this, foo.service have to determine the charger state itself and
 if the charger is plugged out, it have to stop itself.
 And it is working only at the first time.
 After foo.service was activated, I stopped foo.service by systemctl
 stop foo.service. And plug out and plug in the charger again. Then
 foo.service was not activated. (Is it normal? I did not try to find the
 reason. If you say it's a problem, then I will try to find.)


 method 2:
 We have another device daemon. Let's call that as deviced and its
 service name is deviced.service. deviced know about plug in/out of the
 charger.
 So, I made a new charging.target. foo.service have Wants= dependency for
 charging.target. (Installed on charging.target.wants.) And I added
 BindsTo=charging.target to foo.service.
 Then foo.service is activated well when the charging.target is entered
 to active state. And also deactivated when charging.target was deactivated.

 In this method, there are limitations what some of other daemon is
 needed and new charging.target is needed.


 Is there any more good way for this?
 I want to find best appropriate way.

 Thank you in advance for comment.

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

Re: [systemd-devel] CapabilityBoundingSet vs. ExecReload (kill)

2015-03-19 Thread Reindl Harald



Am 19.03.2015 um 18:04 schrieb Nusenu:

That tells me that the ExecReload command (kill) is also
restricted by CapabilityBoundingSet. Is this expected [..]?



recent systemd has more problems in context of systemctl and
restricting even PID1 itself in a way no longer be able to kill
processes


thanks for the links. so you are saying this is just a bug and indeed
not expected?


to be honest i don't know but i hope it's not excpected so it can go 
away sonner or later - while i understand the intention restrict even 
systemd pieces itself as much as possible some of this things are in the 
way when you try to secure a customized service as much as possible


as example there is PermissionsStartOnly=true which helps to have a 
ExecStartPre script to ensure permissions and apply User/Group only to 
ExecStart the same don#t work for ReadOnlyDirectories which are 
unconditionally applied *before* ExecStartPre


what i would like in some cases is to have a ExecStartPre script which 
takes acre of owner, group, permissions and so on on folders which are 
finally protected by ReadOnlyDirectories - in otehr words: make sure 
that the service binary has read-permissions without the need of a own 
root-unit ordered with Before/After beause that don't sale with 
Restart/Reload




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] Boot ordering

2015-03-19 Thread Reindl Harald



Am 19.03.2015 um 18:00 schrieb Uoti Urpala:

On Thu, 2015-03-19 at 18:41 +0300, Andrei Borzenkov wrote:

On Thu, Mar 19, 2015 at 6:11 PM, Michael Biebl mbi...@gmail.com wrote:

The summary of my reply was What you probably want, is hook into
basic.target or sysinit.target, use DefaultDependencies=no, and
specify the dependencies/orderings explicitly.

Apparently, this didn't stick.


The reality is, this question comes again and again; and the very fact
that we had to add *-pre.target to allow such kind of ordering
dependencies shows that the problem is real.


What exactly is your definition of this question and the problem? I
don't see any natural definition that would equally apply to what the
original poster was trying to do and things like local-fs-pre.target


that you have sometimes things where you want to make sure a specific 
order and say: don't start my target until basic target is started and 
don't start anything until all the services of my target are up


it would make ordering way easier and give a ton of flexibility for 
unit-writers (which are not only distributions but end-users/admins with 
very specific environments)





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] experiments with 'minimal build'

В Thu, 19 Mar 2015 08:39:18 -0700
Alison Chaiken ali...@she-devel.com пишет:

 I ran systemd 219 with most recent patches and
 
 -PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP
 -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL -XZ -LZ4 -SECCOMP +BLKID -ELFUTILS
 +KMOD -IDN
 
 and, to compare, with
 
 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
 +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS
 +KMOD +IDN
 
 Checking memory RSS usage with 'sudo pmap -x -p 1' as suggested by
 Mantas, the former case uses about 5 MB, while the later consumes
 close to 9 MB.I'm sure that with statically compiled kernel and
 appropriate fstab that KMOD and BLKID are not needed either, but I
 doubt that they affect memory usage much.
 
 http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ says that
 the minimum requirements are udev and journald.   I wonder if udev is
 really needed if the kernel is completely statically compiled and
 module loading is disabled?   That is a common use case for many
 embedded devices.
 


Systemd enumerates devices using udev, so any dependency on device
won't work. May be it is not that important for embedded world, just
something to keep in mind.



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

[systemd-devel] bandwidth per service

2015-03-19 Thread Rahul Sundaram

Hi

I see device specific ones at

http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html

I was wondering, whether it would be feasible to add bandwidth limits
either by size or percentage for any particular service? squid, torrent
daemons etc could use this.

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

Re: [systemd-devel] [PATCH 0/2] some systemd unit changes

2015-03-19 Thread Steve Dickson



On 03/03/2015 12:28 PM, Martin Pitt wrote:
 Hello NFS developers,
 
 reposting the two patches inline as requested by Steve.
 
 I'm currently systemd-ifying our nfs-utils Ubuntu package. For testing I put
 the NFS server and client (i. e. localhost:/foo/bar mounts) on the same
 machine. With that I get long hangs during shutdown on stopping the NFS .mount
 units, as when that happens the NFS server is already shut down.
 
 This is certainly a corner case as you'd usually not NFS-mount a share from
 localhost; but fixing it is relatively simple with the first patch, which 
 makes
 sure that if NFS server and client are installed, the server starts before the
 client, and the client stops before the server.
 
 For a client without installed server this is harmless as Before= does not
 imply a dependency. Likewise, for an NFS server which does not mount shares by
 itself, it's also a no-op as remote-fs.target is empty. This would only
 slightly reorder the boot sequence for machines which both are an NFS server
 and have some remote NFS mounts, but I don't see an issue with that.
 
 The second patch make NFS start earlier in the boot (i. e. before
 basic.target), so that you can do things like put /var/ on NFS, or have rcS
 SysV init scripts which depend on $remote_fs work. I tested this on both a
 server and a client. This is certainly a bit more intrusive, but could be
 worthwhile; what do you think?
 
 Thanks for considering,
Committed

steved.

 
 Martin
 
 ___
 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] Boot ordering

2015-03-19 Thread Uoti Urpala

On Thu, 2015-03-19 at 18:41 +0300, Andrei Borzenkov wrote:
 On Thu, Mar 19, 2015 at 6:11 PM, Michael Biebl mbi...@gmail.com wrote:
  The summary of my reply was What you probably want, is hook into
  basic.target or sysinit.target, use DefaultDependencies=no, and
  specify the dependencies/orderings explicitly.
 
  Apparently, this didn't stick.
 
 
 The reality is, this question comes again and again; and the very fact
 that we had to add *-pre.target to allow such kind of ordering
 dependencies shows that the problem is real.

What exactly is your definition of this question and the problem? I
don't see any natural definition that would equally apply to what the
original poster was trying to do and things like local-fs-pre.target.


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

Re: [systemd-devel] Needs help for on charging activation

2015-03-19 Thread Kyungmin Park

On Thursday, March 19, 2015, David Herrmann dh.herrm...@gmail.com wrote:

 Hi

 On Mon, Mar 9, 2015 at 3:21 PM, WaLyong Cho walyong@samsung.com
 javascript:; wrote:
  Hi,
 
  I want to find best solution on our case. Our product is mobile device.
  But I don't think that is only problem of mobile device. That also can
  be problem of laptop. So, please comment to me.
 
  We have some of services are always running after system is started up
  as default. They don't need to be running always. They are just needed
  only charger is plugged in.
  So I thought lets only active them when only charger is plugged in.
 
  I thought two methods.
 
  method 1:
  Charger also can be detected by udev. So udev hardware activation can be
  used.
  I wrote below udev rules.
 
  SUBSYSTEM==power_supply, ENV{POWER_SUPPLY_CHARGE_NOW}==1,
  TAG+=systemd, ENV{SYSTEMD_WANTS}+=foo.service

 I guess the problem is, the .device unit is never stopped. Therefore,
 when you unplug it, it will not be stopped, as the device is still
 there.

 You could try this:

 SUBSYSTEM==power_supply, ENV{POWER_SUPPLY_CHARGE_NOW}==1, \
 TAG+=systemd, ENV{SYSTEMD_WANTS}+=foo.service, \
 ENV{SYSTEMD_READY}=1

 SUBSYSTEM==power_supply, ENV{POWER_SUPPLY_CHARGE_NOW}==0, \
 ENV{SYSTEMD_READY}=0

 It's not particularly nice, as other dependencies on the power-supply
 device will now be borked. But as a hack it should work.


There are some hard test-case. Connect  disconnect within short time and
several time. Then does it handle it at udev activation based
service launch?

Another one is that there are lots of services has dependency with
charging. Then dose it add it all cases like above? Doesn't better to use
target? E.g., charging.target?

Thank you,
Kyungmin Park


 I cannot think of a better way to support udev-activation based on
 attribute-changes. We never explicitly supported it. Hmm..



 Thanks
 David

  It looked working well. foo.service is only activated when charger was
  plugged in.
  But I have some of problems with hardware activation.
  I want to be stopped foo.service when the charger is plugged out. As I
  know, this is impossible with udev hardware activation.
  To do this, foo.service have to determine the charger state itself and
  if the charger is plugged out, it have to stop itself.
  And it is working only at the first time.
  After foo.service was activated, I stopped foo.service by systemctl
  stop foo.service. And plug out and plug in the charger again. Then
  foo.service was not activated. (Is it normal? I did not try to find the
  reason. If you say it's a problem, then I will try to find.)
 
 
  method 2:
  We have another device daemon. Let's call that as deviced and its
  service name is deviced.service. deviced know about plug in/out of the
  charger.
  So, I made a new charging.target. foo.service have Wants= dependency for
  charging.target. (Installed on charging.target.wants.) And I added
  BindsTo=charging.target to foo.service.
  Then foo.service is activated well when the charging.target is entered
  to active state. And also deactivated when charging.target was
 deactivated.
 
  In this method, there are limitations what some of other daemon is
  needed and new charging.target is needed.
 
 
  Is there any more good way for this?
  I want to find best appropriate way.
 
  Thank you in advance for comment.
 
  WaLyong
  ___
  systemd-devel mailing list
  systemd-devel@lists.freedesktop.org javascript:;
  http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org javascript:;
 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] [PATCH] timedated: Add a LocalOffset property for timezone offset

2015-03-19 Thread Stef Walter

On 19.03.2015 15:17, David Herrmann wrote:
 Hi
 
 On Thu, Mar 19, 2015 at 2:58 PM, Stef Walter st...@redhat.com wrote:
 On 19.03.2015 14:39, David Herrmann wrote:
 Hmm, so this is a convenience call. You could just set tm.tm_zone
 locally and use mktime() with the value retrieved by Timezone? Yeah,
 the time-api is awful with global variables, but that's not really our
 fault, is it?

 I'm not really against this bus-call, but I also don't see the point.

 In Cockpit we're running on a different machine, and accessing timedated
 remotely. If this information is not available in timedated, we would
 need to add another DBus service to expose this information.

 Besides it fits in well with the TimeUSec property.
 
 But TimeUSec is UTC. If you retrieve TimeUSec and Timezone, you
 can reconstruct the time offset yourself, without any further
 information, right?

No, the Timezone field is textual and unusable in a browser (unless you
reimplement all of /usr/share/zoneinfo in the browser).

 There's much more information in a timezone file than the offset, so
 why expose the offset but not the other data?

 I would like to be able to do 'timedatectl list-timezones' over DBus as
 well.
 
 Why? This information should be the same on all machines, right? I
 don't see why the remote list is of any interest.

Because Cockpit is running in a browser, and accesses DBus from a
browser. But I guess we could implement our own DBus timedated2
interface which exposes the zoneinfo information. I just figured
timedated would be a natural place for such an API.

 Such work would allow timedatectl to work properly with the --host
 argument. Currently the output of 'timedatectl status
 --host=machine-in-another-timezone.example.com' is full of invalid
 information.
 
 Yes, but it's the job of timedatectl to print information in the
 timezone of the remote host, not of the local host. It should retrieve
 the Timezone field and modify it's local timezone if you want the
 information to be relative to remote timezone, not the local timezone
 (which I'm not sure you really want).
 
 What exactly do you mean with full of invalid information?

Example below. First set of timedatectl output is correct (since I SSH
and then invoke timedatectl) ... second set has lots of incorrect
fields, since timedatectl accesses timedated remotely:

$ ssh 192.168.11.155 timedatectl
  Local time: Fr 2015-03-20 01:31:41 AEDT
  Universal time: Do 2015-03-19 14:31:41 UTC
RTC time: Do 2015-03-19 14:31:41
   Time zone: Australia/Tasmania (AEDT, +1100)
 NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
  DST active: yes
 Last DST change: DST began at
  So 2014-10-05 01:59:59 AEST
  So 2014-10-05 03:00:00 AEDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
  So 2015-04-05 02:59:59 AEDT
  So 2015-04-05 02:00:00 AEST

$ timedatectl --host=192.168.11.155
  Local time: Do 2015-03-19 15:31:50 CET
  Universal time: Do 2015-03-19 14:31:50 UTC
RTC time: Do 2015-03-19 14:31:50
   Time zone: Australia/Tasmania (CET, +0100)
 NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
  DST active: no
 Last DST change: DST ended at
  So 2014-10-26 02:59:59 CEST
  So 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
  So 2015-03-29 01:59:59 CET
  So 2015-03-29 03:00:00 CEST



In particular the following fields are incorrect in the second set of
output:

  Local time: Do 2015-03-19 15:31:50 CET
   Time zone: Australia/Tasmania (CET, +0100)
 Last DST change: DST ended at
  So 2014-10-26 02:59:59 CEST
  So 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
  So 2015-03-29 01:59:59 CET
  So 2015-03-29 03:00:00 CEST


Cheers,

Stef



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] Boot ordering

2015-03-19 Thread Uoti Urpala

On Thu, 2015-03-19 at 14:27 +0100, Christoph Pleger wrote:
  Then, I still do not understand why my definition of a new target did
  not
  work. What is the difference between multi-user.target waiting for
  basic.target on the one hand and new.target waiting for basic.target and
  multi-user.target waiting for new.target on the other hand, aside from
  that one intermediate step?

You're misunderstanding some of the basics of unit ordering. That
multi-user.target has an After: relationship to basic.target only
means that multi-user.target ITSELF will not be considered to have been
successfully started before basic.target has. This does not say anything
about the ordering of any other units, such as the services that are
started because multi-user.target wants them - the reason why some
service is started at boot (such as which target pulls it in via a
Wants/Requires relationship) says NOTHING about where the service can
be ordered. If multi-user.target wants some service, it's up to the
individual dependencies of that service to determine when the service
can be started.

Typically most services started by multi-user.target run after
basic.target, but that's only because they each have the default
configuration DefaultDependencies=yes, which implies After:
basic.target. If some service has DefaultDependencies=no and defines
no other ordering requirements, it can even be the first service to run
at boot even if it's only wanted by multi-user.target.


Thus your between basic.target and multi-user.target is not a
well-defined requirement. My best guess about what you might actually
want to achieve (assuming you aren't so thoroughly confused that it
makes no sense at all) is a service that runs before any service that
has DefaultDependencies enabled, and which requires (most of)
basic.target. I think this would be most practically implemented as a
DefaultDependencies=no service, which is wanted by basic.target, and
which has explicit dependencies on (most of) other services that are
wanted by basic.target.

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

Re: [systemd-devel] Boot ordering

2015-03-19 15:46 GMT+01:00 Uoti Urpala uoti.urp...@pp1.inet.fi:
 On Thu, 2015-03-19 at 14:27 +0100, Christoph Pleger wrote:
  Then, I still do not understand why my definition of a new target did
  not
  work. What is the difference between multi-user.target waiting for
  basic.target on the one hand and new.target waiting for basic.target and
  multi-user.target waiting for new.target on the other hand, aside from
  that one intermediate step?

 You're misunderstanding some of the basics of unit ordering. That
 multi-user.target has an After: relationship to basic.target only
 means that multi-user.target ITSELF will not be considered to have been
 successfully started before basic.target has. This does not say anything
 about the ordering of any other units, such as the services that are
 started because multi-user.target wants them - the reason why some
 service is started at boot (such as which target pulls it in via a
 Wants/Requires relationship) says NOTHING about where the service can
 be ordered. If multi-user.target wants some service, it's up to the
 individual dependencies of that service to determine when the service
 can be started.

 Typically most services started by multi-user.target run after
 basic.target, but that's only because they each have the default
 configuration DefaultDependencies=yes, which implies After:
 basic.target. If some service has DefaultDependencies=no and defines
 no other ordering requirements, it can even be the first service to run
 at boot even if it's only wanted by multi-user.target.


 Thus your between basic.target and multi-user.target is not a
 well-defined requirement. My best guess about what you might actually
 want to achieve (assuming you aren't so thoroughly confused that it
 makes no sense at all) is a service that runs before any service that
 has DefaultDependencies enabled, and which requires (most of)
 basic.target. I think this would be most practically implemented as a
 DefaultDependencies=no service, which is wanted by basic.target, and
 which has explicit dependencies on (most of) other services that are
 wanted by basic.target.


I already told Christoph that a week ago, since he was posting the
same question on debian-user.

The summary of my reply was What you probably want, is hook into
basic.target or sysinit.target, use DefaultDependencies=no, and
specify the dependencies/orderings explicitly.

Apparently, this didn't stick.


-- 
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] experiments with 'minimal build'

2015-03-19 Thread Greg KH

On Fri, Mar 20, 2015 at 02:44:47AM +1100, Jeff Waugh wrote:
 On Fri, Mar 20, 2015 at 2:39 AM, Alison Chaiken ali...@she-devel.com wrote:
 
 http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ says that
 the minimum requirements are udev and journald.   I wonder if udev is
 really needed if the kernel is completely statically compiled and
 module loading is disabled?   That is a common use case for many
 embedded devices.
 
 
 Yeah, we still need udev to populate /dev and manage device changes, all of
 which is still relevant even if the kernel has everything built in. (devtmpfs
 doesn't let us dump udev, either.)

Population of /dev happens from devtmpfs, not udev.  udev doesn't create
device nodes anymore, and hasn't for years from what I recall.

thanks,

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

Re: [systemd-devel] experiments with 'minimal build'

2015-03-19 Thread Greg KH

On Thu, Mar 19, 2015 at 08:39:18AM -0700, Alison Chaiken wrote:
 I ran systemd 219 with most recent patches and
 
 -PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP
 -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL -XZ -LZ4 -SECCOMP +BLKID -ELFUTILS
 +KMOD -IDN
 
 and, to compare, with
 
 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
 +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS
 +KMOD +IDN
 
 Checking memory RSS usage with 'sudo pmap -x -p 1' as suggested by
 Mantas, the former case uses about 5 MB, while the later consumes
 close to 9 MB.I'm sure that with statically compiled kernel and
 appropriate fstab that KMOD and BLKID are not needed either, but I
 doubt that they affect memory usage much.
 
 http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ says that
 the minimum requirements are udev and journald.   I wonder if udev is
 really needed if the kernel is completely statically compiled and
 module loading is disabled?   That is a common use case for many
 embedded devices.

static compilation doesn't affect the ability to plug in dynamic devices
into your system, like USB :)

That being said, you can run an embedded system without udev, just use
the kernel devtmpfs and you should be fine.  But watch out, you usually
quickly need/want to determine your hardware types and locations, and
need libudev, so I really recommend adding it.

thanks,

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

Re: [systemd-devel] [PATCH] resolved: Do not add .busname dependencies, when compiling without kdbus.

2015-03-19 17:07 GMT+01:00 David Herrmann dh.herrm...@gmail.com:
 On Thu, Mar 19, 2015 at 4:59 PM, Michael Biebl mbi...@gmail.com wrote:
 So, +1 for Dimitri's patch. Looks correct to me.
 Unless someone objects, I'm planning on merging it.

 Yes, please go ahead. I missed that .busname is not installed without
 --enable-kdbus.

Pushed as defa8e675b2903ad53e093bb2847c7256f0779a5

I made a small addition and added /systemd-resolved.service.m4 to .gitignore

Thanks,
Michael

-- 
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] resolved: Do not add .busname dependencies, when compiling without kdbus.

2015-03-19 15:02 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com:
 On 19 March 2015 at 13:31, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Tue, Mar 17, 2015 at 4:37 PM, Dimitri John Ledkov
 dimitri.j.led...@intel.com wrote:
 ---
  Makefile.am  |  2 +-
  units/systemd-resolved.service.in| 29 -
  units/systemd-resolved.service.m4.in | 31 +++
  3 files changed, 32 insertions(+), 30 deletions(-)
  delete mode 100644 units/systemd-resolved.service.in
  create mode 100644 units/systemd-resolved.service.m4.in

 There is already a:
 ConditionPathExists=/sys/fs/kdbus/0-system/
 in the busname unit. Isn't that enough?


 The busname unit is not installed, when compiling without kdbus. Thus
 upon loading systemd-resolved.service, .busname unit is attempted to
 be loaded and ends up being not found, which imho is untidy.


This also leads to those error messages in the journal:

Mär 19 16:57:59 debian systemd[1]: Cannot add dependency job for unit
org.freedesktop.resolve1.busname, ignoring: Unit
org.freedesktop.resolve1.busname failed to load: No such file or
directory.

So, +1 for Dimitri's patch. Looks correct to me.
Unless someone objects, I'm planning on merging it.


Regards,
Michael


-- 
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] resolved: Do not add .busname dependencies, when compiling without kdbus.

Hi

On Thu, Mar 19, 2015 at 4:59 PM, Michael Biebl mbi...@gmail.com wrote:
 2015-03-19 15:02 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com:
 On 19 March 2015 at 13:31, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Tue, Mar 17, 2015 at 4:37 PM, Dimitri John Ledkov
 dimitri.j.led...@intel.com wrote:
 ---
  Makefile.am  |  2 +-
  units/systemd-resolved.service.in| 29 -
  units/systemd-resolved.service.m4.in | 31 +++
  3 files changed, 32 insertions(+), 30 deletions(-)
  delete mode 100644 units/systemd-resolved.service.in
  create mode 100644 units/systemd-resolved.service.m4.in

 There is already a:
 ConditionPathExists=/sys/fs/kdbus/0-system/
 in the busname unit. Isn't that enough?


 The busname unit is not installed, when compiling without kdbus. Thus
 upon loading systemd-resolved.service, .busname unit is attempted to
 be loaded and ends up being not found, which imho is untidy.


 This also leads to those error messages in the journal:

 Mär 19 16:57:59 debian systemd[1]: Cannot add dependency job for unit
 org.freedesktop.resolve1.busname, ignoring: Unit
 org.freedesktop.resolve1.busname failed to load: No such file or
 directory.

 So, +1 for Dimitri's patch. Looks correct to me.
 Unless someone objects, I'm planning on merging it.

Yes, please go ahead. I missed that .busname is not installed without
--enable-kdbus.

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

Re: [systemd-devel] experiments with 'minimal build'

2015-03-19 Thread Alison Chaiken

I ran systemd 219 with most recent patches and

-PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP
-LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL -XZ -LZ4 -SECCOMP +BLKID -ELFUTILS
+KMOD -IDN

and, to compare, with

+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS
+KMOD +IDN

Checking memory RSS usage with 'sudo pmap -x -p 1' as suggested by
Mantas, the former case uses about 5 MB, while the later consumes
close to 9 MB.I'm sure that with statically compiled kernel and
appropriate fstab that KMOD and BLKID are not needed either, but I
doubt that they affect memory usage much.

http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ says that
the minimum requirements are udev and journald.   I wonder if udev is
really needed if the kernel is completely statically compiled and
module loading is disabled?   That is a common use case for many
embedded devices.

Thanks,
Alison

-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
One consumes a great deal of silence in the course of becoming
educated. -- Matthew B. Crawford
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Boot ordering