Re: [systemd-devel] Trying to turn off a UPS with home-made service unit

2013-09-15 Thread Roger Price

On Wed Sep 11 10:45:48 PDT 2013 Lennart Poettering wrote:

So, it's a really bad idea to turn off UPS from userspace, simply 
because you will race against the kernel's fs sync() code, and you never 
know what will finish first: your UPS shutdown timeout or your fs 
sync(). Doing this from userspace is hence racy.

If you want to use a hack like this then at least do it via the 
/usr/lib/systemd/system-shutdown/ drop-in directory which is called very 
late during shutdown. It will shorten the race window, but not erase it, 
since the kernel will flush various buffers only after the reboot() 
system call is invoked.

Here is the effect on a simple openSUSE 12.3 test rig of replacing my 
home-made service unit /lib/systemd/system/ups-delayed-shutdown.service 
with a script in the /usr/lib/systemd/system-shutdown/ drop-in directory. 
I used the default UPS offdelay of 20 secs. The X's indicate the race 
window. (Sorry for the ascii art.)

1) My bad idea ups-delayed-shutdown.service

systemctl   system
poweroff halt
   | ||
   0   2 | 4   6   8  10  12  14  16  18  20  22  24  26  28  30  32 secs
 |   |
  upsdrvctl UPS

2) Replaced by script in /usr/lib/systemd/system-shutdown/

systemctl   system
poweroff halt
   | ||
   0   2   4   6   8 |10  12  14  16  18  20  22  24  26  28  30  32 secs
 |   |
 upsdrvctl  UPS
 shutdown shutdown

The script solution has the advantage of reducing the race window from 9 
to 3 secs.  Note that the same security can also be achieved by the 
service unit by setting offdelay = 26 in ups.conf.  My script is

   #! /bin/bash
   # Delayed turn off for the UPS unit.
   # Needed for automatic system restart when wall power returns.
   $UPSDRVCTL_BIN shutdown

I tried adding

   echo `date -I` `date +%T` $0 calls $UPSDRVCTL_BIN shutdown  

to get a trace of the activity, but nothing is written in 

systemd-devel mailing list

Re: [systemd-devel] systemd shutdown vs ostree

2013-09-15 Thread Koen Kooi

Op 14 sep. 2013, om 11:04 heeft Jan Alexander Steffens 
het volgende geschreven:

 On Sat, Sep 14, 2013 at 10:52 AM, Koen Kooi 
 Please keep in mind that pstore is x86 only. EFI isn't x86 only, but 
 exceedingly rare outside of that arch.
 What? Pstore itself isn't. It's a generic interface to persistent
 platform storage. There are backends using EFI variables, NVRAM
 (PowerPC) or the APEI ERST (x86). As a last resort there's also a
 platform-independent RAM backend which may at least survive a simple

OK, so x86 and ppc only. That will leaves out arm, mips and others.
systemd-devel mailing list

Re: [systemd-devel] [RFC] mount/automount/swap: unify the remaining default dependency handling

2013-09-15 Thread Tom Gundersen
Please disregard these patches for now, I'll have to rethink and resubmit them.



On Fri, Sep 13, 2013 at 12:55 PM, Tom Gundersen wrote:
 This moves the last bits of the default dependency handling from the fstab
 generator to core, and uses it also in the gpt-auto generator; making the
 logic the same no matter how you set up your mount points.

 The first patch may be controversial as it changes the semantics of automount
 points quite a bit. I think it makes more sense this way, but coments welcome.



  src/core/automount.c|  14 ++
  src/core/mount.c|  53 
  src/fstab-generator/fstab-generator.c   | 111 
  src/gpt-auto-generator/gpt-auto-generator.c |  28 
  4 files changed, 86 insertions(+), 120 deletions(-)

systemd-devel mailing list

Re: [systemd-devel] [PATCH 1/5] cgroup: add the setting memory.use_hierarchy support for systemd

2013-09-15 Thread Gao feng
On 09/13/2013 08:26 PM, Lennart Poettering wrote:
 On Fri, 13.09.13 17:49, Gao feng ( wrote:
 Some programs need to set the memory.use_hierarchy(such as libvirt),
 Add this feature.
 Hmm, should this really be an option? Shouldn't we much rather turn this
 on unconditionally if the memory controller is used for a unit?
 This appears like an option that would go a way in Tejun's new sane
 cgroup tree logic anyway, no?

So, systemd has no job to deal with memory hierarchy? the kernel will
support memory hierarchy unconditionally? right?
systemd-devel mailing list

[systemd-devel] [PATCH] cgroup: add missing equals for BlockIOWeight

2013-09-15 Thread Gao feng
 src/core/cgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 1f41efc..9277dd6 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -92,7 +92,7 @@ void cgroup_context_dump(CGroupContext *c, FILE* f, const 
char *prefix) {
 %sMemoryLimit=% PRIu64 \n
 %sMemorySoftLimit=% PRIu64 \n

systemd-devel mailing list

[systemd-devel] Question: who should set up the cpuset cgroup

2013-09-15 Thread Gao feng

I'm working on adding set cpuset cgroup support for systemd.
this work almost finished. but I faced a problem.

As we know, if we create a machine,the cgroup for this machine
will be created as well. and the cgroup of this machine is a
sub-directory of machine.slice(or other slices..). And if the
cpuset of machine.slice is unset. the setting of cpuset for this
machine will failed. since the cpuset.mems and cpuset.cpus of
machine.slice is null.

The question is who should set up the cpuset cgroup of machine.slice?

1, set up when systemd creates cpuset cgroup for machine.slice?
2, the programs which create the machines?
3, other ideas? kernel?

systemd-devel mailing list