FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 08-22-2011, 09:54 AM
"Stefan G. Weichinger"
 
Default systemd

Am 22.08.2011 10:26, schrieb Stefan G. Weichinger:

> What I wonder: what changes between running into that timeout and my
> pressing Ctrl-D?

To me it seems that the underlying RAID-device (which is the PV inside
the LVM-VG) isn't up fast enough.

Trying to figure it out now.
 
Old 08-22-2011, 10:26 AM
Joost Roeleveld
 
Default systemd

On Monday, August 22, 2011 11:54:48 AM Stefan G. Weichinger wrote:
> Am 22.08.2011 10:26, schrieb Stefan G. Weichinger:
> > What I wonder: what changes between running into that timeout and my
> > pressing Ctrl-D?
>
> To me it seems that the underlying RAID-device (which is the PV inside
> the LVM-VG) isn't up fast enough.
>
> Trying to figure it out now.

Are they actually started in the right order?
In other words, first RAID, then LVM?

--
Joost
 
Old 08-22-2011, 10:31 AM
"Stefan G. Weichinger"
 
Default systemd

Am 22.08.2011 12:26, schrieb Joost Roeleveld:

> Are they actually started in the right order?
> In other words, first RAID, then LVM?

I don't know ;-)

I still try to understand all this.
There is no specific RAID-service-file, so it seems to be done by udev
and the related target/service somehow.


lvm.service says

After=udev-settle.service

so udev should detect all devices first, then lvm.service gets started.

But somehow this doesn't work here, only after hitting that timeout one
time.

Stefan
 
Old 08-22-2011, 11:42 AM
Joost Roeleveld
 
Default systemd

On Monday, August 22, 2011 12:31:19 PM Stefan G. Weichinger wrote:
> Am 22.08.2011 12:26, schrieb Joost Roeleveld:
> > Are they actually started in the right order?
> > In other words, first RAID, then LVM?
>
> I don't know ;-)
>
> I still try to understand all this.
> There is no specific RAID-service-file, so it seems to be done by udev
> and the related target/service somehow.
>
>
> lvm.service says
>
> After=udev-settle.service
>
> so udev should detect all devices first, then lvm.service gets started.
>
> But somehow this doesn't work here, only after hitting that timeout one
> time.

That's unfortunate. The stop-service might be started to try to clean up when
it fails.

What kind of RAID are you using? Does it perhaps rely on a module that is
loaded in the background?
In which case you could try adding that module as a dependency?

--
Joost
 
Old 08-22-2011, 04:55 PM
"Stefan G. Weichinger"
 
Default systemd

Am 2011-08-22 13:42, schrieb Joost Roeleveld:

> That's unfortunate. The stop-service might be started to try to clean
> up when it fails.

Hm, yes, I understand.

> What kind of RAID are you using? Does it perhaps rely on a module
> that is loaded in the background? In which case you could try adding
> that module as a dependency?

This is plain RAID1 and the kernel has that built in, so no, there is no
module used here for RAID.

There are LVM-options as modules:

crypt target, snapshot target, mirror target ... but that should not
play a role here.

S
 
Old 08-22-2011, 05:03 PM
Joost Roeleveld
 
Default systemd

On Monday, August 22, 2011 06:55:21 PM Stefan G. Weichinger wrote:
> Am 2011-08-22 13:42, schrieb Joost Roeleveld:
> > That's unfortunate. The stop-service might be started to try to clean
> > up when it fails.
>
> Hm, yes, I understand.
>
> > What kind of RAID are you using? Does it perhaps rely on a module
> > that is loaded in the background? In which case you could try adding
> > that module as a dependency?
>
> This is plain RAID1 and the kernel has that built in, so no, there is no
> module used here for RAID.
>
> There are LVM-options as modules:
>
> crypt target, snapshot target, mirror target ... but that should not
> play a role here.

Not really, unless you actually have any of these defined...
I do hope you can figure this one out as I do like the idea of systemd. But I
need RAID and LVM to work correctly for my system to boot.

--
Joost
 
Old 08-22-2011, 06:24 PM
"Stefan G. Weichinger"
 
Default systemd

Am 22.08.2011 19:03, schrieb Joost Roeleveld:

> I do hope you can figure this one out as I do like the idea of systemd. But I
> need RAID and LVM to work correctly for my system to boot.

Got it.

Compared this one:

https://github.com/falconindy/initscripts-systemd/blob/master/lvm.service

w/ the lvm.service in the gentoo wiki.

The line:

Requires=udev-settle.service

missed, I added it and now it boots up straight and fast.

Gotta re-test it right now ;-)

S
 
Old 08-22-2011, 06:29 PM
"Stefan G. Weichinger"
 
Default systemd

Am 22.08.2011 20:24, schrieb Stefan G. Weichinger:

> The line:
>
> Requires=udev-settle.service
>
> missed, I added it and now it boots up straight and fast.

update: edited the example in the gentoo-wiki now.

S
 
Old 08-22-2011, 09:09 PM
"Stefan G. Weichinger"
 
Default systemd

Am 22.08.2011 20:29, schrieb Stefan G. Weichinger:

> update: edited the example in the gentoo-wiki now.

replying to myself once more, which makes it feel more like a wiki or
blog than a mailing-list ;-)

additional thoughts:

* as there is readahead-support in systemd I assume I could get rid of
preload:

http://packages.gentoo.org/package/sys-apps/preload?arches=all

As it isn't maintained actively anymore it maybe isn't of much use
anymore anyway?

As there is no related service-file for preload here, it is deactivated
for now anyway (as long as I choose the systemd-using GRUB-line).

* remember those cgroup-hacks back then?

http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups

Is that stuff still valid?

With systemd the whole use of cgroups changes fundamentally, I don't
have the knowledge to decide if to use both in parallel.

For now I disabled the stuff from the wiki (stop sourcing
/etc/bash/local/cgrouprc) as it only gives me warnings ...

* found this blog-entry against systemd:

http://monolight.cc/2011/05/the-systemd-fallacy/

I agree, it might be more useful on desktops ... so far I am still
exploring and learning to get to the point to make a decision where and
if to use.

-

regards, Stefan
 
Old 08-23-2011, 06:27 AM
Joost Roeleveld
 
Default systemd

On Monday, August 22, 2011 11:09:02 PM Stefan G. Weichinger wrote:
> Am 22.08.2011 20:29, schrieb Stefan G. Weichinger:
> > update: edited the example in the gentoo-wiki now.
>
> replying to myself once more, which makes it feel more like a wiki or
> blog than a mailing-list ;-)

There wasn't much to add. You provided a solution and the only reply I could
come up with "Well done" would sound condescending. Which is why I decided not
to.

> additional thoughts:
>
> * as there is readahead-support in systemd I assume I could get rid of
> preload:
>
> http://packages.gentoo.org/package/sys-apps/preload?arches=all
>
> As it isn't maintained actively anymore it maybe isn't of much use
> anymore anyway?

I don't tend to use preload. Is it usefull in a non-systemd environment?

> As there is no related service-file for preload here, it is deactivated
> for now anyway (as long as I choose the systemd-using GRUB-line).
>
> * remember those cgroup-hacks back then?
>
> http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups
>
> Is that stuff still valid?

Maybe, if you want to group stuff you're running yourself into seperate
groups. The different services are grouped already.

> With systemd the whole use of cgroups changes fundamentally, I don't
> have the knowledge to decide if to use both in parallel.
>
> For now I disabled the stuff from the wiki (stop sourcing
> /etc/bash/local/cgrouprc) as it only gives me warnings ...

What kind of warnings? Systemd already mounts the filesystem for it and starts
poulating it. If your script does similar things, they might try to duplicate
work?

> * found this blog-entry against systemd:
>
> http://monolight.cc/2011/05/the-systemd-fallacy/
>
> I agree, it might be more useful on desktops ... so far I am still
> exploring and learning to get to the point to make a decision where and
> if to use.

I think it is more useful on desktops and laptops, which get rebooted
regularly. On a server that tends to run for months without a reboot, a fast
init-system is important.

And I don't really see the point of D-BUS on a server either. All the services
that need to talk to each other already have working communication paths.

I do intend to implement it on my desktop and netbook as I'd like to have
those booting as fast as possible.

--
Joost
 

Thread Tools




All times are GMT. The time now is 09:13 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org