Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

2014-10-09 Thread Tobias Geerinckx-Rice 
On 9 October 2014 17:30, Tobias Hunger tobias.hun...@gmail.com wrote:

 PS: How do you send patches to this list via gmail? I pasted the output from
 git format-patch into the mail client, bit there got to be a better way:-)

Using git send-email works surprisingly well with Gmail [1].

Regards,

T G-R

[1] See https://coderwall.com/p/dp-gka for an example
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

2014-09-22 Thread Tobias Geerinckx-Rice 
On 22 September 2014 07:57, Alexander Groleau awg...@xbetanet.com wrote:
 I have tried the following script as well during my adventures with no
 success:

 [Unit]
 Description=Start/Stop Libvirt Windows Guest
 Documentation=man:libvirtd(8)
 Documentation=http://libvirt.org
 After=libvirtd.service

Manually ordering services with Before=/After= is usually a mistake.
Try using Requires= or BindTo= instead, and let systemd handle
ordering for you.

 [Service]
 ExecStart=/usr/bin/libvirt-windows.sh start
 ExecStop=/usr/bin/libvirt-windows.sh stop
 RemainAfterExit=yes
 Type=oneshot
 StandardOutput=journal+console

 [Install]
 WantedBy=multi-user.target

 This works for boot (my sh script is run right after libvirtd is started);
 however, the libvirtd daemon, started by libvirtd.service, is always
 terminated well before my sh is run on shutdown/reboot.

I can't see any other obvious problems. This should just work, unless
something other than systemd is killing your libvirtd.

Regards,

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

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

2014-09-22 Thread Tobias Geerinckx-Rice 
On 22 September 2014 15:36, Mantas Mikulėnas graw...@gmail.com wrote:

 [Nonsense]

 Neither Requires nor BindsTo imply any ordering though. So that might in
 fact *create* race conditions, if both A and B start at once, but A already
 expects B to be available.

[Indeed. That whole paragraph was hastily re-written and doesn't even
make sense as-is: manually ordering is what Before= and After= *do*.
They don't explicitly, uhm... imply dependencies, which is what I
failed at saying.]

On Mon, Sep 22, 2014 at 7:40 AM, Alexander Groleau awg...@xbetanet.com wrote:

 Here is my journalctl log:

 Sep 21 23:14:53 Xerxes9 systemd-logind[340]: System is rebooting.
 Sep 21 23:14:53 Xerxes9 libvirtd[605]: End of file while reading data:
 Input/output error // HERE IS LIBVIRTD TERMINATING

My systems helpfully spam the life out of me when shutting down
services. I'd see a Stopping Description line between these, if
libvirtd were being stopped cleanly by systemd. Your logs don't
mention _any_ services, though.

Regards,

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

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

2014-09-22 Thread Tobias Geerinckx-Rice 
On 23 September 2014 01:10, Alexander Groleau awg...@xbetanet.com wrote:
 Hmm,

 This is a fresh installation of arch linux with systemd. What else might be
 terminating my daemons or how might I be able to figure that out?

A cursory search linked that suspicious EOF error message to libvirtd
crashing. If that's what's happening here, libvirtd could already be
dead while systemd is correctly handling ExecStop=. Does this error
message appear when manually stopping or restarting just
libvirtd.service?

There may be other hints somewhere in the logs. I just don't
understand why yours don't contain or show those Stopping...
messages that mine are full of [1]. You are using plain, unaliased
journalctl, right?

Also, focus on getting systemd {stop,start,restart} libvirt.service
to work first, without all the extra complexity (and potential races,
and time) of a full shut-down.

Regards,

T G-R

[1] Messages which are being fiercely attacked elsewhere on this list.
Hurry! ;-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

2014-09-21 Thread Tobias Geerinckx-Rice 
On 22 September 2014 05:40, Alexander Groleau awg...@xbetanet.com wrote:
 Hello systemd users,

Oh good. That's me!

 I have been trying desperately for weeks to get my simple shutdown script
 for a Libvirt guest to run before libvirtd is shut down, without success.
 Essentially, I need the libvirt-windows.sh script to run before the libvirtd
 service is terminated (which occurs right after systemd-logind outputs its
 reboot message). How can I get my script into this initial section of daemon
 shutdowns, at the top?

Weeks makes one hesitant to ask: have you tried just popping a

  ExecStop=/usr/bin/libvirt-windows.sh stop

snippet into /etc/systemd/system/my.libvirt.service.d/?

 [Install]
 WantedBy=shutdown.target

Either way, shutdown.target conflicts with all system services [1],
and is probably not what you want.

Good luck,

T G-R

[1] 
http://www.freedesktop.org/software/systemd/man/bootup.html#System%20Manager%20Shutdown
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

2014-09-16 Thread Tobias Geerinckx-Rice 
Hallo,

On 14 September 2014 19:49, Andrei Borzenkov arvidj...@gmail.com wrote:
 В Thu, 11 Sep 2014 21:53:27 +0200
 Tobias Geerinckx-Rice tobias.geerinckx.r...@gmail.com пишет:

 From my reading of the thread, this is to emulate as closely ye olde
 initscripts' unreliable and flawed behaviour of attempting to mount
 one or more devices exactly once (i.e., a one-shot mount -a), but
 not until an arbitrary time-out has elapsed after which all external
 devices are blindly assumed to have been initialised for no good
 reason.

 This thread is not about blindly assuming anything.

Indeed it isn't. But the traditional application of fstab was. Badly [1].

That's not to say that it didn't happen to work most of the time. I
just hoped systemd could do better. I still do.

 Actually, it is systemd which blindly assumes user wants to
 always mount device as soon at it appears.

The device is in fstab, marked 'auto'. I submit that's closer to a
reasonable assumption than a blind one -- however...

 This isn't hard to achieve with systemd,

 In case you missed it - it is impossible to achieve with systemd right
 now. At least, it is impossible to achieve what the goal of OP was -
 attempt to automount device exactly once on system boot and give up if
 it was not successful.

...yeah. Sorry. Quick story: for some unholy reason, the vintage Arch
VM I last used to test this always did the Right Thing:

  - Add a nofail fstab line, boot with the device present.
  - Verify that it was 'auto'-mounted. umount and (physically) unplug it.
  - Plug it back in. The device has the same path and active unit.
  - Yet nothing is mounted. All is well, if you like it that way.

Now, of course, that VM is gone. And now, with exactly the same
(logged) commands, the device is indeed silently mounted. Every time.
Even with old systemd.

Grr.

Now: is always mounting better than the old behaviour? -- Still think so.
Is it different from how everyone historically expects fstab to work,
and therefore confusing as hell until either properly documented or
(meh) made configurable? -- Hell yes.

Regardless: sorry for any noise!

T G-R

[1]: Lennart's remark, 'a concept of mount at boot if it is there,
otherwise don't
cannot work' 
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg21973.html,
isn't theoretical: it regularly broke on some dodgy hardware I'm
thankful to no longer own.

To paraphrase the OP: It never *really* worked. I don't want it back.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

2014-09-11 Thread Tobias Geerinckx-Rice 
Hallo,

On 11 September 2014 19:41, Dale R. Worley wor...@alum.mit.edu wrote:
  From: Colin Guthrie gm...@colin.guthr.ie
  I'm maybe missing something, but in the case of mount units, isn't that
  framework program mount(8)?
 
  It has a mechanism for parsing default options that apply to all mounts
  and then calling out to the appropriate, filesystem specific mount
  program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.)
  if appropriate.

 mount does the real work, of course, but it isn't the complete
 solution,

Er, solution to what, exactly? People here seem (rightly)
unconvinced there's any problem at all.

And yes, calling mount -- by definition -- actually is the complete
solution to mounting a file system under Linux.

 because *something* has to figure out not only that
 /bin/mount should be invoked, but what its arguments are.

 And as you can see from the unit file

[SNIP]
 What=/dev/Freeze02/Store2
 Where=/Store
 Type=ext4
[SNIP]
 Options=nofail,x-systemd.device-timeout=1m,defaults

 none of that is specified *directly* in the unit file.

Now surely, calling

/usr/bin/mount $What $Where [-t $Type] [-o $Options]

is about as direct as it gets. Being able to substitute the only
constant in that equation with /usr/bin/gimp really isn't going to
solve any problem, real or imagined.

 Some piece of code has to know to assemble the What, Where, Type,
 and Options values (at the very least) -- and that piece of code is what
 contains special knowledge of how to handle mount units.

Again: straightforward use of a standard Unix API that just happens to
be in a separate binary != special knowledge. Really. It's
programming.

Step back, and define exactly what it is you actually need^Wwant to do.

From my reading of the thread, this is to emulate as closely ye olde
initscripts' unreliable and flawed behaviour of attempting to mount
one or more devices exactly once (i.e., a one-shot mount -a), but
not until an arbitrary time-out has elapsed after which all external
devices are blindly assumed to have been initialised for no good
reason.

This isn't hard to achieve with systemd, but there's a good reason I
wrote it in such a silly manner, that can't simply be ignored.

Regards (and good luck nonetheless),

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

Re: [systemd-devel] Non-Stop Services in an Embedded Environment

2014-09-09 Thread Tobias Geerinckx-Rice 
On 9 September 2014 14:38, Spence, Richard (EXT-Other - DE/Ulm)
richard.spence@nsn.com wrote:
 we have an additional requirement for which we can find no clean (direct)
 solution in systemd: applications in the system should not stop for any
 reason – any termination must be handled as a failure.

So... you want *all* terminations to be listed as failed in
systemctl (!0), even when the exit status is success (0).

At that point, you're just overloading the term failure to mean
something it was never intended to mean. Therefore, any wrapper doing
this is by definition a [hack] that systemd is supposed to render
unneccessary: systemd not helping you undermine reliable semantics
natively is a *good* thing :-)

Assuming you can't patch the service(s) in question to return correct
error codes, just be explicit and use an appropriately named/commented
wrapper to tell systemd (and anyone using the system) that you're
doing something substandard.

Regards,

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

Re: [systemd-devel] [PATCH] TODO: add molly-guard functionality

2014-08-24 Thread Tobias Geerinckx-Rice 
On 24 August 2014 04:26, Josh Triplett j...@joshtriplett.org wrote:
 +  - add molly-guard functionality: prompt for hostname if interactively 
 shutting down a remote system (running as child of ssh)

I'll assume (and hope) that both the hostname prompt and SSH child
rule are merely example configurations of a more generic system. SSH
is far from the only possible use-case, and hostnames aren't always
that relevant.

Which makes me wonder whether this can't already be done today, with
some simple Requires/ExecStart{,Pre}/... snippets on shutdown.target.
These could even be shipped by default, pointing to some empty
systemd/shutdown.d directory.

(Now, that still sounds quite dirty, and leaves an unpleasant SysV
aftertaste; but it's a lot better than hard-coding this [*if* that's
what anyone is contemplating. Perhaps I'm being paranoid, but I never
know when adding another --disable- switch to ./configure will finally
return E2BIG...])

Regards,

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

Re: [systemd-devel] [RFC] [PATCH 0/3] resume: implement support for resuming from hibernation

2014-08-23 Thread Tobias Geerinckx-Rice 
On 23 August 2014 14:47, Ivan Shapovalov intelfx...@gmail.com wrote:
 This is my first patch to this project, so feel free to flak me for missing
 something obvious :)

On 4 August 2014 10:39, Tobias Geerinckx-Rice
tobias.geerinckx.r...@gmail.com wrote:
 (As this is my first systemd patch, feel free to flak me for missing
 something obvious.)

http://media.tumblr.com/tumblr_lpn8viK7f61qc4jgq.jpg

On a more serious note: thanks for pursuing this; I hope it makes it
into git soon!

Regards,

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

Re: [systemd-devel] About systemd in initrd support

2014-08-23 Thread Tobias Geerinckx-Rice 
On 23 August 2014 13:46, Luca Bruno lethalma...@gmail.com wrote:
 I'm going to do an experiment with NixOS: replace the whole current initrd
 process made of scripts and hooks with systemd.

What a coincidence... I just switched to NixOS last week, moved some
file systems around, and promptly broke my boot. Badly.

The learning curve was steepened by the proprietary initrd script,
which gave me exactly 0 error messages until I could find a live CD
and look up the NixOS-specific boot options on-line. It also manages
to boot slower than my previous systemd-based initrds.

So, yes -- please.

 Also, apart arch linux, is there any other OS that you know using systemd
 for the whole initrd process?

Simon's right: switching to dracut brings relatively decent systemd
support more or less for free. I'd focus on that.

Regarding distributions: I've been using dracut on Exherbo (A Less
Brain-dead Gentoo®) for a year or so. It's the official initrd
generator in that there's a blog post somewhere saying guys you
really should use dracut, but there's no distribution-specific code
or glue anywhere. It still works flawlessly. I take that as a
heartening hint that using it under NixOS should be relatively
straightforward.

Regards,

T G-R

 Thanks for you work.

 Best regards,

 --
 www.debian.org - The Universal Operating System

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

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

[systemd-devel] [PATCH] pager: wrap long lines by default

2014-08-18 Thread Tobias Geerinckx-Rice 
Wrap lines longer than the screen width to multiple rows instead of
making them stumble abruptly off the edge.
---
 man/less-variables.xml | 2 +-
 src/shared/pager.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/man/less-variables.xml b/man/less-variables.xml
index 09cbd42..4264692 100644
--- a/man/less-variables.xml
+++ b/man/less-variables.xml
@@ -23,7 +23,7 @@
 listitemparaOverride the default
 options passed to
 commandless/command
-(literalFRSXMK/literal)./para/listitem
+(literalFRXMK/literal)./para/listitem
 /varlistentry
 /variablelist
 /refsect1
diff --git a/src/shared/pager.c b/src/shared/pager.c
index 5479094..4eefe96 100644
--- a/src/shared/pager.c
+++ b/src/shared/pager.c
@@ -91,7 +91,7 @@ int pager_open(bool jump_to_end) {
 
 less_opts = getenv(SYSTEMD_LESS);
 if (!less_opts)
-less_opts = FRSXMK;
+less_opts = FRXMK;
 if (jump_to_end)
 less_opts = strappenda(less_opts,  +G);
 setenv(LESS, less_opts, 1);
-- 
2.0.4

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

Re: [systemd-devel] Make journalctl start at the end of the journal by default

2014-08-18 Thread Tobias Geerinckx-Rice 
On 18 August 2014 17:33, Andrei Borzenkov arvidj...@gmail.com wrote:

 Personally I find default (lack of) line wrapping quite annoying [...]
 I think line wrapping by default is really more user friendly.

Agreed. I assume there was a good reason to add -S to the default
pager options, but I can't imagine what it would be. I've a patch
applied locally that removes it, because I'm fussy that way. I'd sent
it, but it's ridiculously trivial

   T G-R

PS: oh hell, I'm staring at it anyway. Here you go. Might save someone
4 seconds of grepping.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] timer: order OnCalendar units after timer-sync.target if DefaultDependencies=no

2014-08-04 Thread Tobias Geerinckx-Rice 
Avoids prematurely triggering timers on systems with significantly inaccurate
clocks, or some embedded platforms that lack one entirely.
---
 TODO  |  2 --
 man/systemd.timer.xml | 10 ++
 src/core/timer.c  |  6 ++
 src/shared/special.h  |  2 +-
 4 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/TODO b/TODO
index 1dbb9ff..7dad2ce 100644
--- a/TODO
+++ b/TODO
@@ -60,8 +60,6 @@ Features:
 
 * Add a new verb systemctl top
 
-* order OnCalendar timer units after timer-sync.target if 
DefaultDependencies=no so that we don't trigger them prematurely
-
 * refuse mounting on symlinks
 
 * logind: allow users to kill or lock their own sessions
diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml
index d82b9bd..559b4cb 100644
--- a/man/systemd.timer.xml
+++ b/man/systemd.timer.xml
@@ -80,13 +80,15 @@
 paraUnless varnameDefaultDependencies=/varname
 is set to optionfalse/option, timer units will
 implicitly have dependencies of type
+varnameAfter=/varname on
+filenametimer-sync.target/filename, and of type
 varnameConflicts=/varname and
 varnameBefore=/varname on
 filenameshutdown.target/filename. These ensure
-that timer units are stopped cleanly prior to system
-shutdown. Only timer units involved with early boot or
-late system shutdown should disable this
-option./para
+that timer units are started at the correct time,
+and are stopped cleanly prior to system shutdown.
+Only timer units involved with early boot or late
+system shutdown should disable this option./para
 /refsect1
 
 refsect1
diff --git a/src/core/timer.c b/src/core/timer.c
index a5a33a6..d116a30 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -106,6 +106,12 @@ static int timer_add_default_dependencies(Timer *t) {
 r = unit_add_two_dependencies_by_name(UNIT(t), UNIT_AFTER, 
UNIT_REQUIRES, SPECIAL_SYSINIT_TARGET, NULL, true);
 if (r  0)
 return r;
+
+if (t-values-base == TIMER_CALENDAR) {
+r = unit_add_dependency_by_name(UNIT(t), UNIT_AFTER, 
SPECIAL_TIME_SYNC_TARGET, NULL, true);
+if (r  0)
+return r;
+}
 }
 
 return unit_add_two_dependencies_by_name(UNIT(t), UNIT_BEFORE, 
UNIT_CONFLICTS, SPECIAL_SHUTDOWN_TARGET, NULL, true);
diff --git a/src/shared/special.h b/src/shared/special.h
index 2fe5db5..b045047 100644
--- a/src/shared/special.h
+++ b/src/shared/special.h
@@ -57,13 +57,13 @@
 #define SPECIAL_REMOTE_FS_PRE_TARGET remote-fs-pre.target
 #define SPECIAL_SWAP_TARGET swap.target
 #define SPECIAL_NETWORK_ONLINE_TARGET network-online.target
+#define SPECIAL_TIME_SYNC_TARGET time-sync.target   /* LSB's $time */
 #define SPECIAL_BASIC_TARGET basic.target
 
 /* LSB compatibility */
 #define SPECIAL_NETWORK_TARGET network.target   /* LSB's $network */
 #define SPECIAL_NSS_LOOKUP_TARGET nss-lookup.target /* LSB's $named */
 #define SPECIAL_RPCBIND_TARGET rpcbind.target   /* LSB's $portmap */
-#define SPECIAL_TIME_SYNC_TARGET time-sync.target   /* LSB's $time */
 
 /*
  * Rules regarding adding further high level targets like the above:
-- 
2.0.4

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

Re: [systemd-devel] Calendar Timers: setting system clock may trigger jobs from the past

2014-08-04 Thread Tobias Geerinckx-Rice 
On 4 August 2014 14:45, Lennart Poettering lenn...@poettering.net wrote:
 On Mon, 04.08.14 12:50, Peter Mattern (matte...@arcor.de) wrote:

 Hello.

 If a *.timer unit's timestamp as stated by OnCalendar is in the past
 and the actual system time is even before that timestamp the *.timer
 gets activated when the system clock gets set.

 This sounds like you should make sure your one-time ntp service should
 be ordered before time-sync.target and your .timer unit after it, so
 that it it doesn't get scheduled before the time is set correctly (in
 fact, on the TODO list there's an item, to make sure that we
 implicitly order all OnCalendar units after time-sync.target, but in the
 meantime you can do that manually).

Hallo all,

I've just sent a simple fix that works for me, albeit on a boring old
desktop system.

(As this is my first systemd patch, feel free to flak me for missing
something obvious.)

Regards,

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

[systemd-devel] [PATCH v2] timer: order OnCalendar units after timer-sync.target if DefaultDependencies=no

2014-08-04 Thread Tobias Geerinckx-Rice 
Avoids triggering timers prematurely on systems with significantly inaccurate
clocks, or some embedded platforms that lack one entirely.
---
v2:
  - Change systemd.timer.xml to clarify that only OnCalendar= timers are
affected. Lennart, I didn't use your wording because a) I had already
spotted the mistake before reading your e-mail and b) IMO it made the
sentence overly long and unclear;
  - use LIST_FOREACH to loop over all entries until an OnCalendar= directive
is found.

Regards,

T G-R

 TODO  |  2 --
 man/systemd.timer.xml | 17 +++--
 src/core/timer.c  | 10 ++
 src/shared/special.h  |  2 +-
 4 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/TODO b/TODO
index 1dbb9ff..7dad2ce 100644
--- a/TODO
+++ b/TODO
@@ -60,8 +60,6 @@ Features:
 
 * Add a new verb systemctl top
 
-* order OnCalendar timer units after timer-sync.target if 
DefaultDependencies=no so that we don't trigger them prematurely
-
 * refuse mounting on symlinks
 
 * logind: allow users to kill or lock their own sessions
diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml
index d82b9bd..a7aeb75 100644
--- a/man/systemd.timer.xml
+++ b/man/systemd.timer.xml
@@ -78,15 +78,20 @@
 varnameUnit=/varname (see below)./para
 
 paraUnless varnameDefaultDependencies=/varname
-is set to optionfalse/option, timer units will
+is set to optionfalse/option, all timer units will
 implicitly have dependencies of type
 varnameConflicts=/varname and
 varnameBefore=/varname on
-filenameshutdown.target/filename. These ensure
-that timer units are stopped cleanly prior to system
-shutdown. Only timer units involved with early boot or
-late system shutdown should disable this
-option./para
+filenameshutdown.target/filename to ensure that
+they are stopped cleanly prior to system shutdown.
+Timer units with at least one
+varnameOnCalendar=/varname directive will have an
+additional varnameAfter=/varname dependency on
+filenametimer-sync.target/filename to avoid
+being started before the system clock has been
+correctly set. Only timer units involved with early
+boot or late system shutdown should disable the
+   varnameDefaultDependencies=/varname option./para
 /refsect1
 
 refsect1
diff --git a/src/core/timer.c b/src/core/timer.c
index a5a33a6..dc0f289 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -95,6 +95,7 @@ static int timer_verify(Timer *t) {
 
 static int timer_add_default_dependencies(Timer *t) {
 int r;
+TimerValue *v;
 
 assert(t);
 
@@ -106,6 +107,15 @@ static int timer_add_default_dependencies(Timer *t) {
 r = unit_add_two_dependencies_by_name(UNIT(t), UNIT_AFTER, 
UNIT_REQUIRES, SPECIAL_SYSINIT_TARGET, NULL, true);
 if (r  0)
 return r;
+
+LIST_FOREACH(value, v, t-values) {
+if (v-base == TIMER_CALENDAR) {
+r = unit_add_dependency_by_name(UNIT(t), 
UNIT_AFTER, SPECIAL_TIME_SYNC_TARGET, NULL, true);
+if (r  0)
+return r;
+break;
+}
+}
 }
 
 return unit_add_two_dependencies_by_name(UNIT(t), UNIT_BEFORE, 
UNIT_CONFLICTS, SPECIAL_SHUTDOWN_TARGET, NULL, true);
diff --git a/src/shared/special.h b/src/shared/special.h
index 2fe5db5..b045047 100644
--- a/src/shared/special.h
+++ b/src/shared/special.h
@@ -57,13 +57,13 @@
 #define SPECIAL_REMOTE_FS_PRE_TARGET remote-fs-pre.target
 #define SPECIAL_SWAP_TARGET swap.target
 #define SPECIAL_NETWORK_ONLINE_TARGET network-online.target
+#define SPECIAL_TIME_SYNC_TARGET time-sync.target   /* LSB's $time */
 #define SPECIAL_BASIC_TARGET basic.target
 
 /* LSB compatibility */
 #define SPECIAL_NETWORK_TARGET network.target   /* LSB's $network */
 #define SPECIAL_NSS_LOOKUP_TARGET nss-lookup.target /* LSB's $named */
 #define SPECIAL_RPCBIND_TARGET rpcbind.target   /* LSB's $portmap */
-#define SPECIAL_TIME_SYNC_TARGET time-sync.target   /* LSB's $time */
 
 /*
  * Rules regarding adding further high level targets like the above:
-- 
2.0.4

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

[systemd-devel] [PATCH v3] timer: order OnCalendar units after timer-sync.target if DefaultDependencies=no

2014-08-04 Thread Tobias Geerinckx-Rice 
Avoids triggering timers prematurely on systems with significantly inaccurate
clocks, or some embedded platforms that lack one entirely.
---
v2:
  - Change systemd.timer.xml to clarify that only OnCalendar= timers are
affected. Lennart, I didn't use your wording because a) I had already
spotted the mistake before reading your e-mail and b) IMO it made the
sentence overly long and unclear;
  - use LIST_FOREACH to loop over all entries until an OnCalendar= directive
is found.
v3:
  - Fix a stupid tabbo in man/systemd.timer.xml

Regards,

T G-R

 TODO  |  2 --
 man/systemd.timer.xml | 17 +++--
 src/core/timer.c  | 10 ++
 src/shared/special.h  |  2 +-
 4 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/TODO b/TODO
index 1dbb9ff..7dad2ce 100644
--- a/TODO
+++ b/TODO
@@ -60,8 +60,6 @@ Features:
 
 * Add a new verb systemctl top
 
-* order OnCalendar timer units after timer-sync.target if 
DefaultDependencies=no so that we don't trigger them prematurely
-
 * refuse mounting on symlinks
 
 * logind: allow users to kill or lock their own sessions
diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml
index d82b9bd..a7aeb75 100644
--- a/man/systemd.timer.xml
+++ b/man/systemd.timer.xml
@@ -78,15 +78,20 @@
 varnameUnit=/varname (see below)./para
 
 paraUnless varnameDefaultDependencies=/varname
-is set to optionfalse/option, timer units will
+is set to optionfalse/option, all timer units will
 implicitly have dependencies of type
 varnameConflicts=/varname and
 varnameBefore=/varname on
-filenameshutdown.target/filename. These ensure
-that timer units are stopped cleanly prior to system
-shutdown. Only timer units involved with early boot or
-late system shutdown should disable this
-option./para
+filenameshutdown.target/filename to ensure that
+they are stopped cleanly prior to system shutdown.
+Timer units with at least one
+varnameOnCalendar=/varname directive will have an
+additional varnameAfter=/varname dependency on
+filenametimer-sync.target/filename to avoid
+being started before the system clock has been
+correctly set. Only timer units involved with early
+boot or late system shutdown should disable the
+varnameDefaultDependencies=/varname option./para
 /refsect1
 
 refsect1
diff --git a/src/core/timer.c b/src/core/timer.c
index a5a33a6..dc0f289 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -95,6 +95,7 @@ static int timer_verify(Timer *t) {
 
 static int timer_add_default_dependencies(Timer *t) {
 int r;
+TimerValue *v;
 
 assert(t);
 
@@ -106,6 +107,15 @@ static int timer_add_default_dependencies(Timer *t) {
 r = unit_add_two_dependencies_by_name(UNIT(t), UNIT_AFTER, 
UNIT_REQUIRES, SPECIAL_SYSINIT_TARGET, NULL, true);
 if (r  0)
 return r;
+
+LIST_FOREACH(value, v, t-values) {
+if (v-base == TIMER_CALENDAR) {
+r = unit_add_dependency_by_name(UNIT(t), 
UNIT_AFTER, SPECIAL_TIME_SYNC_TARGET, NULL, true);
+if (r  0)
+return r;
+break;
+}
+}
 }
 
 return unit_add_two_dependencies_by_name(UNIT(t), UNIT_BEFORE, 
UNIT_CONFLICTS, SPECIAL_SHUTDOWN_TARGET, NULL, true);
diff --git a/src/shared/special.h b/src/shared/special.h
index 2fe5db5..b045047 100644
--- a/src/shared/special.h
+++ b/src/shared/special.h
@@ -57,13 +57,13 @@
 #define SPECIAL_REMOTE_FS_PRE_TARGET remote-fs-pre.target
 #define SPECIAL_SWAP_TARGET swap.target
 #define SPECIAL_NETWORK_ONLINE_TARGET network-online.target
+#define SPECIAL_TIME_SYNC_TARGET time-sync.target   /* LSB's $time */
 #define SPECIAL_BASIC_TARGET basic.target
 
 /* LSB compatibility */
 #define SPECIAL_NETWORK_TARGET network.target   /* LSB's $network */
 #define SPECIAL_NSS_LOOKUP_TARGET nss-lookup.target /* LSB's $named */
 #define SPECIAL_RPCBIND_TARGET rpcbind.target   /* LSB's $portmap */
-#define SPECIAL_TIME_SYNC_TARGET time-sync.target   /* LSB's $time */
 
 /*
  * Rules regarding adding further high level targets like the above:
-- 
2.0.4

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