Re: [systemd-devel] Trying to turn off a UPS with home-made service unit
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 shutdownshutdown 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=/usr/lib/ups/driver/upsdrvctl $UPSDRVCTL_BIN shutdown I tried adding echo `date -I` `date +%T` $0 calls $UPSDRVCTL_BIN shutdown /var/log/UPS.log to get a trace of the activity, but nothing is written in /var/log/UPS.log. Roger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd shutdown vs ostree
Op 14 sep. 2013, om 11:04 heeft Jan Alexander Steffens jan.steff...@gmail.com het volgende geschreven: On Sat, Sep 14, 2013 at 10:52 AM, Koen Kooi k...@dominion.thruhere.net wrote: 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 reboot. OK, so x86 and ppc only. That will leaves out arm, mips and others. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] mount/automount/swap: unify the remaining default dependency handling
Please disregard these patches for now, I'll have to rethink and resubmit them. Cheers, Tom On Fri, Sep 13, 2013 at 12:55 PM, Tom Gundersen t...@jklm.no 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. Cheers, Tom 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] cgroup: add the setting memory.use_hierarchy support for systemd
On 09/13/2013 08:26 PM, Lennart Poettering wrote: On Fri, 13.09.13 17:49, Gao feng (gaof...@cn.fujitsu.com) 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cgroup: add missing equals for BlockIOWeight
---
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) {
%sBlockIOAccounting=%s\n
%sMemoryAccounting=%s\n
%sCPUShares=%lu\n
-%sBlockIOWeight%lu\n
+%sBlockIOWeight=%lu\n
%sMemoryLimit=% PRIu64 \n
%sMemorySoftLimit=% PRIu64 \n
%sDevicePolicy=%s\n,
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question: who should set up the cpuset cgroup
Hi 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? Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
