Re: [systemd-devel] modprobe in service file

2011-11-08 Thread Lennart Poettering
On Tue, 08.11.11 10:14, Michael D. Berger (m.d.ber...@ieee.org) wrote: > In my /etc/init.d/filterDaemon, I have, for example, >modprobe -q ip_queue > How do I do this in a new filterDaemon.service? So, ideally all kmods these days can be autoloaded on use. And for the few ones which cannot be

Re: [systemd-devel] systemd kills mdmon if it was started manually by user

2011-11-08 Thread Williams, Dan J
On Tue, Nov 8, 2011 at 6:43 AM, Lennart Poettering wrote: > On Mon, 07.11.11 11:09, Williams, Dan J (dan.j.willi...@intel.com) wrote: >> So I think mdmon should always try to escape itself from cgroup based >> killing.  It follows the lifespan of the array, and if the array is >> not stopped by th

Re: [systemd-devel] systemd kills mdmon if it was started manually by user

2011-11-08 Thread Williams, Dan J
On Tue, Nov 8, 2011 at 12:32 PM, Michal Soltys wrote: > On 11-11-08 17:46, Michal Soltys wrote: >> >> Then even existing intiramfs image could (probably) be mdmon-agnostic. > > Actually: > > chroot /run/initramfs mdmon --takeover --all One of the suggestion earlier in the thread is not mess with

Re: [systemd-devel] systemd kills mdmon if it was started manually by user

2011-11-08 Thread Michal Soltys
On 11-11-08 17:46, Michal Soltys wrote: Then even existing intiramfs image could (probably) be mdmon-agnostic. Actually: chroot /run/initramfs mdmon --takeover --all worked just fine (after preparing new root - so after all mount --binds, and before pivot_root(8)). So in context of systemd

Re: [systemd-devel] modprobe in service file

2011-11-08 Thread Tomasz Torcz
On Tue, Nov 08, 2011 at 10:14:03AM -0500, Michael D. Berger wrote: > In my /etc/init.d/filterDaemon, I have, for example, >modprobe -q ip_queue > How do I do this in a new filterDaemon.service? You can use ExecStartPre=, but nowadays it's better to load the modules at bootup, by echo ip_queu

Re: [systemd-devel] systemd kills mdmon if it was started manually by user

2011-11-08 Thread Michal Soltys
On 11-11-08 01:11, Michal Soltys wrote: I've peeked into systemd, and from what I can see, it /only/ jumps back to initramfs (prepare_new_root() and pivot_to_new_root()) if shutdown "binary" is present on initramfs. And whenever mdmon is still running or not, is not in any way determinent for pi

Re: [systemd-devel] modprobe in service file

2011-11-08 Thread Michael Olbrich
On Tue, Nov 08, 2011 at 10:14:03AM -0500, Michael D. Berger wrote: > In my /etc/init.d/filterDaemon, I have, for example, >modprobe -q ip_queue > How do I do this in a new filterDaemon.service? This runs before the actual service is started, right? ExecStartPre=/sbin/modprobe -q ip_queue Reg

[systemd-devel] modprobe in service file

2011-11-08 Thread Michael D. Berger
In my /etc/init.d/filterDaemon, I have, for example, modprobe -q ip_queue How do I do this in a new filterDaemon.service? Thanks, Mike. -- Michael D. Berger m.d.ber...@ieee.org http://www.rosemike.net/ ___ systemd-devel mailing list systemd-devel@l

Re: [systemd-devel] [PATCH] cryptsetup-generator: avoid ordering cycle on swap

2011-11-08 Thread Frederic Crozat
Le mardi 01 novembre 2011 à 23:53 +0100, Lennart Poettering a écrit : > On Mon, 17.10.11 17:28, Tom Gundersen (t...@jklm.no) wrote: > > > > > On Mon, Oct 17, 2011 at 4:24 PM, Lennart Poettering > > wrote: > > > On Mon, 17.10.11 13:01, Tom Gundersen (t...@jklm.no) wrote: > > > > > >> Devices with

Re: [systemd-devel] systemd kills mdmon if it was started manually by user

2011-11-08 Thread Lennart Poettering
On Mon, 07.11.11 11:09, Williams, Dan J (dan.j.willi...@intel.com) wrote: > >> What exactly is "kill_all_processes()"?   is it SIGTERM or SIGKILL or both > >> with a gap or ??? > > > > SIGTERM followed by SIGKILL after 5s if the programs do not react to > > that in time. But note that this logic o

Re: [systemd-devel] [PATCH 0/3] watchdog handling with systemd

2011-11-08 Thread Michael Olbrich
Hi, On Fri, Nov 04, 2011 at 03:38:39PM +0100, Michael Olbrich wrote: > here is a new version of the first 3 patches updated as suggested. > The actual /dev/watchdog handling is not part of this series. It needs some > more work to finish. so I tried to implement the /dev/watchdog handling inside