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
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
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
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
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
On 11-11-02 14:32, Lennart Poettering wrote:
What we do right now is this:
kill_all_processes();
do {
umount_all_file_systems_we_can();
read_only_mount_all_remaining_file_systems();
} while (we_had_some_success_with_that());
jump_into_initrd();
As long as mdmon references a file fro
On Mon, Nov 7, 2011 at 4:00 AM, Lennart Poettering
wrote:
> On Mon, 07.11.11 13:52, NeilBrown (ne...@suse.de) wrote:
>
>> > Why doesn't the kernel do that on its own?
>>
>> Because the kernel doesn't know about the format of the metadata that
>> describes the array.
>
> Yupp, my suggestion would b
On Mon, 07.11.11 13:52, NeilBrown (ne...@suse.de) wrote:
> > Why doesn't the kernel do that on its own?
>
> Because the kernel doesn't know about the format of the metadata that
> describes the array.
Yupp, my suggestion would be to change that.
> > What we do right now is this:
> >
> > kill_
On Mon, 7 Nov 2011 04:42:54 +0100 Kay Sievers wrote:
> On Mon, Nov 7, 2011 at 03:52, NeilBrown wrote:
>
> > However there is an important piece missing. When you remount,ro a
> > filesystem, the block device doesn't get told so it thinks it is still open
> > read/write. So md cannot tell mdmo
On Mon, Nov 7, 2011 at 03:52, NeilBrown wrote:
> However there is an important piece missing. When you remount,ro a
> filesystem, the block device doesn't get told so it thinks it is still open
> read/write. So md cannot tell mdmon that the array is now read-only
That ro/rw flag is visible in
On Wed, 2 Nov 2011 14:32:25 +0100 Lennart Poettering
wrote:
> On Wed, 02.11.11 13:03, NeilBrown (ne...@suse.de) wrote:
> > Each instance of mdmon manages a set of arrays and must remain running
> > until all of those arrays are readonly (or shut down). This allows it to
> > record that all writ
On Wed, Nov 2, 2011 at 4:39 PM, Lennart Poettering
wrote:
> On Wed, 02.11.11 15:18, Williams, Dan J (dan.j.willi...@intel.com) wrote:
>
>>
>> On Wed, Nov 2, 2011 at 8:29 AM, Lennart Poettering
>> wrote:
>> > On Wed, 02.11.11 16:21, Kay Sievers (kay.siev...@vrfy.org) wrote:
>> >
>> >>
>> >> On Wed
On Wed, 02.11.11 15:18, Williams, Dan J (dan.j.willi...@intel.com) wrote:
>
> On Wed, Nov 2, 2011 at 8:29 AM, Lennart Poettering
> wrote:
> > On Wed, 02.11.11 16:21, Kay Sievers (kay.siev...@vrfy.org) wrote:
> >
> >>
> >> On Wed, Nov 2, 2011 at 16:17, Lennart Poettering
> >> wrote:
> >> > Kern
On Wed, 02.11.11 10:21, Williams, Dan J (dan.j.willi...@intel.com) wrote:
> > That means we'd:
> >
> > a) patch systemd to check whether argv[0][0] of a process is '@' and
> > owned by root and exclude it from killing on shutdown.
> >
> > b) patch mdmon to set argv[0][0] of itself to '@' iff it is
On Wed, Nov 2, 2011 at 8:29 AM, Lennart Poettering
wrote:
> On Wed, 02.11.11 16:21, Kay Sievers (kay.siev...@vrfy.org) wrote:
>
>>
>> On Wed, Nov 2, 2011 at 16:17, Lennart Poettering
>> wrote:
>> > Kernel threads we detect by checking whether /proc/$PID/cmdline is
>> > empty, hence I'd suggest w
On Wed, Nov 2, 2011 at 20:31, Williams, Dan J wrote:
> On Wed, Nov 2, 2011 at 11:49 AM, Kay Sievers wrote:
>> On Wed, Nov 2, 2011 at 19:16, Williams, Dan J
>> wrote:
>>> On Wed, Nov 2, 2011 at 7:33 AM, Kay Sievers wrote:
People who like to put their rootfs on a userspace managed raid devi
On Wed, Nov 2, 2011 at 11:49 AM, Kay Sievers wrote:
> On Wed, Nov 2, 2011 at 19:16, Williams, Dan J
> wrote:
>> On Wed, Nov 2, 2011 at 7:33 AM, Kay Sievers wrote:
>>> People who like to put their rootfs on a userspace managed raid device
>>> just get what they asked for. :)
>>
>> Proper care an
On Wed, Nov 2, 2011 at 19:16, Williams, Dan J wrote:
> On Wed, Nov 2, 2011 at 7:33 AM, Kay Sievers wrote:
>> People who like to put their rootfs on a userspace managed raid device
>> just get what they asked for. :)
>
> Proper care and feeding of mdmon and userspace managed block devices /
> file
On Wed, Nov 2, 2011 at 7:33 AM, Kay Sievers wrote:
> People who like to put their rootfs on a userspace managed raid device
> just get what they asked for. :)
Proper care and feeding of mdmon and userspace managed block devices /
filesystems is a solvable problem. To me the ":)" runs the risk of
On Wed, Nov 2, 2011 at 8:17 AM, Lennart Poettering
wrote:
> On Wed, 02.11.11 15:33, Kay Sievers (kay.siev...@vrfy.org) wrote:
>
>> > The big thing is that if things are done that way you'll always have the
>> > chicken and egg problem: you really need to shut down mdmon before
>> > unmounting root
On Wed, 02.11.11 16:21, Kay Sievers (kay.siev...@vrfy.org) wrote:
>
> On Wed, Nov 2, 2011 at 16:17, Lennart Poettering
> wrote:
> > Kernel threads we detect by checking whether /proc/$PID/cmdline is
> > empty, hence I'd suggest we use the first char of argv[0][0] here, to
> > detect whether som
On Wed, Nov 2, 2011 at 16:17, Lennart Poettering wrote:
> Kernel threads we detect by checking whether /proc/$PID/cmdline is
> empty, hence I'd suggest we use the first char of argv[0][0] here, to
> detect whether something is a process to avoid killing. Question is
> which char to choose for that
On Wed, 02.11.11 15:33, Kay Sievers (kay.siev...@vrfy.org) wrote:
> > The big thing is that if things are done that way you'll always have the
> > chicken and egg problem: you really need to shut down mdmon before
> > unmounting root, but currently you require us to do it in the other
> > order to
On Wed, Nov 2, 2011 at 14:32, Lennart Poettering wrote:
> On Wed, 02.11.11 13:03, NeilBrown (ne...@suse.de) wrote:
>
>> > I'd really prefer if we could somehow make it something that isn't
>> > special and we could just shutdown
>>
>> It must remain running until the array that it manages is read-
On Wed, 02.11.11 13:03, NeilBrown (ne...@suse.de) wrote:
> > I'd really prefer if we could somehow make it something that isn't
> > special and we could just shutdown
>
> It must remain running until the array that it manages is read-only and will
> never be written to again. Then it can be shut
On Wed, 2 Nov 2011 02:16:15 +0100 Lennart Poettering
wrote:
> On Wed, 02.11.11 11:44, NeilBrown (ne...@suse.de) wrote:
>
> > > We nowadays jump back into the initrd when we shut down, so that the
> > > initrd disassembles everything it assembled at boot time. This for the
> > > first time enable
On Wed, 02.11.11 11:44, NeilBrown (ne...@suse.de) wrote:
> > We nowadays jump back into the initrd when we shut down, so that the
> > initrd disassembles everything it assembled at boot time. This for the
> > first time enables us to ensure that all layers of our stack are in a
> > sane state (i.e
On Mon, 31 Oct 2011 12:06:13 +0100 Lennart Poettering
wrote:
> On Sun, 23.10.11 01:00, Dan Williams (dan.j.willi...@intel.com) wrote:
>
> > > Well, it would be nice if the md utils would offer something doing this
> > > without spawning multiple processes and killing them again.
> > >
> >
> > /
On Mon, 31.10.11 12:06, Lennart Poettering (lenn...@poettering.net) wrote:
> We actually try to disassemble md already, i.e. we call the
> DM_DEV_REMOVE ioctl for all left-over devices. I am not really
> interested to link against libdm itself.
Sorry, wasn't fully woken up yet and mixed up dm and
On Sun, 23.10.11 01:00, Dan Williams (dan.j.willi...@intel.com) wrote:
> > Well, it would be nice if the md utils would offer something doing this
> > without spawning multiple processes and killing them again.
> >
>
> /me wonders why his raid5 resyncs every boot on Fedora 15 and has
> found this
On Sun, 23 Oct 2011 01:00:36 -0700 Dan Williams
wrote:
> On Tue, Feb 8, 2011 at 9:28 AM, Lennart Poettering
> wrote:
> > On Tue, 08.02.11 16:54, Andrey Borzenkov (arvidj...@mail.ru) wrote:
> >
> >> >> a) mdmon is perfectly capable of restarting, it is already used to
> >> >> take over mdmon laun
On Sunday, 23. October 2011 10:00:36 Dan Williams wrote:
> Is it time for a libmd.so, so systemd can invoke the "--wait-clean --scan"
> process itself? Probably simpler to just SIGTERM mdmon and wait for it.
The mdadm code makes good use of non-reentrant functions like ctime(),
readdir() and oth
On Tue, Feb 8, 2011 at 9:28 AM, Lennart Poettering
wrote:
> On Tue, 08.02.11 16:54, Andrey Borzenkov (arvidj...@mail.ru) wrote:
>
>> >> a) mdmon is perfectly capable of restarting, it is already used to
>> >> take over mdmon launched in initrd. The problem is to know when to
>> >> restart - i.e. w
On Tue, 08.02.11 12:07, Lennart Poettering (lenn...@poettering.net) wrote:
> > At this point we know it is container, know that it has external
> > metadata and know that we need external metadata handler (mdmon). But
> > it is too late for systemd.
>
> Kay, do you know why this "change" event is
On Tue, 08.02.11 16:54, Andrey Borzenkov (arvidj...@mail.ru) wrote:
> >> a) mdmon is perfectly capable of restarting, it is already used to
> >> take over mdmon launched in initrd. The problem is to know when to
> >> restart - i.e. when respective libraries are changed. This is a job
> >> for pack
On Tue, Feb 8, 2011 at 2:07 PM, Lennart Poettering
wrote:
> On Tue, 08.02.11 13:52, Andrey Borzenkov (arvidj...@mail.ru) wrote:
>
>> I am probably the wrong one to ask, but here is what happens when
>> array is started (from udev perspective)
>
> [...]
>
>> After this event device goes "plugged" a
On Tue, 08.02.11 13:52, Andrey Borzenkov (arvidj...@mail.ru) wrote:
> I am probably the wrong one to ask, but here is what happens when
> array is started (from udev perspective)
[...]
> After this event device goes "plugged" and SYSTEMD_WANTS (if any) are
> triggered. But at this point we have
On Tue, Feb 8, 2011 at 12:48 PM, Lennart Poettering
wrote:
> On Fri, 04.02.11 22:55, Andrey Borzenkov (arvidj...@mail.ru) wrote:
>
>> >> That's right, but the names are not known in advance and can change
>> >> between reboots. This means such units have to be generated
>> >> dynamically, exist un
On Fri, 04.02.11 22:55, Andrey Borzenkov (arvidj...@mail.ru) wrote:
> >> That's right, but the names are not known in advance and can change
> >> between reboots. This means such units have to be generated
> >> dynamically, exist until reboot (ramfs?) and be removed when array is
> >> destroyed. N
On Tue, Jan 25, 2011 at 7:28 AM, Lennart Poettering
wrote:
> On Tue, 25.01.11 06:58, Andrey Borzenkov (arvidj...@mail.ru) wrote:
>
>> > systemd supports instantiated services, for example to deal with the
>> > gettys (e.g. "getty@tty5.service"). It should be trivial to use the same
>> > for mdmon
On Tue, 25.01.11 06:58, Andrey Borzenkov (arvidj...@mail.ru) wrote:
> > systemd supports instantiated services, for example to deal with the
> > gettys (e.g. "getty@tty5.service"). It should be trivial to use the same
> > for mdmon (e.g. "mdmon@md3.service").
> >
> That's right, but the names are
On Tue, Jan 25, 2011 at 6:44 AM, Lennart Poettering
wrote:
> On Sat, 22.01.11 20:55, Andrey Borzenkov (arvidj...@mail.ru) wrote:
>
>> >> mdmon does not belong to user. User is not even aware that it is
>> >> started. And it is likely not the last case. So systemd does need some
>> >> framework whi
On Sat, 22.01.11 20:55, Andrey Borzenkov (arvidj...@mail.ru) wrote:
> >> mdmon does not belong to user. User is not even aware that it is
> >> started. And it is likely not the last case. So systemd does need some
> >> framework which can move such processes out of user session. It
> >> probably n
2010/12/4 Tomasz Torcz :
> On Sat, Dec 04, 2010 at 03:08:05PM +0300, Andrey Borzenkov wrote:
>> > (/etc/pam.d/system-auth), which automatically creates cgroups by login
>> > session, which in turn gets killed when the user has "completely logged
>> > out".
>> > That is why your mdadm gets terminat
On Fri, 07.01.11 12:16, NeilBrown (ne...@suse.de) wrote:
>
> On Fri, 7 Jan 2011 01:38:27 +0100 Lennart Poettering
> wrote:
>
> > On Sat, 04.12.10 11:41, Andrey Borzenkov (arvidj...@gmail.com) wrote:
> >
> > > If user starts array manually (mdadm -A -s as example) from within
> > > user session
On Fri, 7 Jan 2011 02:09:32 +0100
Michael Biebl wrote:
> 2011/1/7 Lennart Poettering :
> >
> > Well, I have been discussing this with Kay and we'll most likely add
> > something like DontKillOnShutdown=yes or so, which if added to a unit
>
> Make that KillOnShutdown=no, please.
Agreed :) That r
On Fri, 7 Jan 2011 01:38:27 +0100 Lennart Poettering
wrote:
> On Sat, 04.12.10 11:41, Andrey Borzenkov (arvidj...@gmail.com) wrote:
>
> > If user starts array manually (mdadm -A -s as example) from within
> > user session and array needs mdmon, mdmon becomes part of user session
> > control grou
2011/1/7 Lennart Poettering :
>
> Well, I have been discussing this with Kay and we'll most likely add
> something like DontKillOnShutdown=yes or so, which if added to a unit
Make that KillOnShutdown=no, please.
--
Why is it that all of the instruments seeking intelligent life in the
universe a
On Sat, 04.12.10 15:08, Andrey Borzenkov (arvidj...@gmail.com) wrote:
> >> It is then killed by systemd during shutdown as part of user session.
> >> It results in dirty array on next boot.
> >>
> >> Is there any magic that allows daemon to be exempted from killing?
> >
> > While your raid should
On Sat, 04.12.10 11:41, Andrey Borzenkov (arvidj...@gmail.com) wrote:
> If user starts array manually (mdadm -A -s as example) from within
> user session and array needs mdmon, mdmon becomes part of user session
> control group:
Are you suggesting that mdadm forks off mdmon from within the user
s
On Sat, Dec 04, 2010 at 03:08:05PM +0300, Andrey Borzenkov wrote:
> > (/etc/pam.d/system-auth), which automatically creates cgroups by login
> > session, which in turn gets killed when the user has "completely logged
> > out".
> > That is why your mdadm gets terminated, too.
>
> Sure.
>
> > You
On Sat, Dec 4, 2010 at 12:12 PM, Christian Parpart wrote:
> On Saturday, December 04, 2010 09:41:26 am Andrey Borzenkov wrote:
>> If user starts array manually (mdadm -A -s as example) from within
>> user session and array needs mdmon, mdmon becomes part of user session
>> control group:
>>
>> ├ u
On Saturday, December 04, 2010 09:41:26 am Andrey Borzenkov wrote:
> If user starts array manually (mdadm -A -s as example) from within
> user session and array needs mdmon, mdmon becomes part of user session
> control group:
>
> ├ user
> │ └ root
> │ └ 1
> │ ├ 1916 login -- root
> │ ├ 1
If user starts array manually (mdadm -A -s as example) from within
user session and array needs mdmon, mdmon becomes part of user session
control group:
├ user
│ └ root
│ └ 1
│ ├ 1916 login -- root
│ ├ 1930 -bash
│ ├ 1964 gpg-agent --keep-display --daemon --write-env-file /root/.gnup
54 matches
Mail list logo
