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-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
 
Old 08-23-2011, 08:30 AM
"Stefan G. Weichinger"
 
Default systemd

Am 2011-08-23 08:27, schrieb Joost Roeleveld:
> 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.

ok, yes

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

I always had the impression that things started faster with preload,
yes. Might be less of an impact with the new SSD I have in my desktop
machine now.

I didn't really miss it when switching to systemd (where I don't have a
service-file for it yet).

>> 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?

The code tries to write to its own dir:

mkdir -p -m 0700 $cdir/user/$$ > /dev/null 2>&1
/bin/echo $$ > $cdir/user/$$/tasks
/bin/echo '1' > $cdir/user/$$/notify_on_release

But somehow the mkdir seems to fail as I get warnings from the two
echo-statements, that their "target-files" do not exist, which lead me
to the fact that $cdir/user/$$ does not exist.

> 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.

You mean, "not so 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.

Yep, I agree.
Stefan
 
Old 08-23-2011, 09:04 AM
Joost Roeleveld
 
Default systemd

On Tuesday, August 23, 2011 10:30:38 AM Stefan G. Weichinger wrote:
> Am 2011-08-23 08:27, schrieb Joost Roeleveld:
> > On Monday, August 22, 2011 11:09:02 PM Stefan G. Weichinger wrote:
> >> Am 22.08.2011 20:29, schrieb Stefan G. Weichinger:
> > I don't tend to use preload. Is it usefull in a non-systemd
> > environment?
>
> I always had the impression that things started faster with preload,
> yes. Might be less of an impact with the new SSD I have in my desktop
> machine now.
>
> I didn't really miss it when switching to systemd (where I don't have a
> service-file for it yet).

Guess it doesn't have much of an improvement anymore?

> >> 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?
>
> The code tries to write to its own dir:
>
> mkdir -p -m 0700 $cdir/user/$$ > /dev/null 2>&1
> /bin/echo $$ > $cdir/user/$$/tasks
> /bin/echo '1' > $cdir/user/$$/notify_on_release
>
> But somehow the mkdir seems to fail as I get warnings from the two
> echo-statements, that their "target-files" do not exist, which lead me
> to the fact that $cdir/user/$$ does not exist.

You could try adding ls-statements to see if it can set that op?
Or try to run those commands.

Where is $cdir pointing to?

> > 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.
>
> You mean, "not so important" ?

Yes, that's what I meant

> > 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.
>
> Yep, I agree.
> Stefan
 
Old 08-23-2011, 09:17 AM
"Stefan G. Weichinger"
 
Default systemd

Am 2011-08-23 11:04, schrieb Joost Roeleveld:
>> The code tries to write to its own dir:
>>
>> mkdir -p -m 0700 $cdir/user/$$ > /dev/null 2>&1 /bin/echo $$ >
>> $cdir/user/$$/tasks /bin/echo '1' >
>> $cdir/user/$$/notify_on_release
>>
>> But somehow the mkdir seems to fail as I get warnings from the two
>> echo-statements, that their "target-files" do not exist, which lead
>> me to the fact that $cdir/user/$$ does not exist.
>
> You could try adding ls-statements to see if it can set that op? Or
> try to run those commands.
>
> Where is $cdir pointing to?

/sys/fs/cgroup which exists.

I removed the "> /dev/null..." part and now I see that I have a
permission problem, my user isn't allowed to mkdir there.

Will solve that ...

otoh it might be overkill to create my own cgroups as systemd does it
anyway, correct?

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

Am 2011-08-23 11:17, schrieb Stefan G. Weichinger:

> I removed the "> /dev/null..." part and now I see that I have a
> permission problem, my user isn't allowed to mkdir there.
>
> Will solve that ...

Rather easy to see:

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

brings the script /usr/local/sbin/cgroup_start which is started by
openrc, but not by systemd. In there the perms would be set up for my
user ...


So the solution will be to teach systemd to start that script as well.
 
Old 08-23-2011, 05:17 PM
Stroller
 
Default systemd

On 23 August 2011, at 07:27, Joost Roeleveld wrote:
> ...
>> * 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.

Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros.

Stroller.
 
Old 08-23-2011, 05:49 PM
Canek Peláez Valdés
 
Default systemd

On Tue, Aug 23, 2011 at 1:17 PM, Stroller
<stroller@stellar.eclipse.co.uk> wrote:
>
> On 23 August 2011, at 07:27, Joost Roeleveld wrote:
>> ...
>>> * 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.
>
> Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros.

I don't see the problem with D-Bus. It's small (the only hard
dependency it has is an XML parser), and it provides the Linux/UNIX
(de facto) standard interprocess communication system.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 08-23-2011, 06:57 PM
Alan McKinnon
 
Default systemd

On Tue 23 August 2011 18:17:17 Stroller did opine thusly:
> On 23 August 2011, at 07:27, Joost Roeleveld wrote:
> > ...
> >
> >> * 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.
> Reading that blog entry I found discouraging the idea that dbus
> might be required on my servers in the future, if systemd becomes
> popular with distros.

What's your objection to dbus? It gives you a standard message bus, is
small, light, consumes minimal resources and provides a nice standard
way to do IPC. Probably easier than reinventing the wheel with named
pipes and other bits over and over.

Now if it had similarities to say hal, I would instantly understand.
But dbus is good and useful in all the ways that hal isn't.

--
alan dot mckinnon at gmail dot com
 
Old 08-23-2011, 07:06 PM
Canek Peláez Valdés
 
Default systemd

On Tue, Aug 23, 2011 at 2:57 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Tue 23 August 2011 18:17:17 Stroller did opine thusly:
>> On 23 August 2011, at 07:27, Joost Roeleveld wrote:
>> > ...
>> >
>> >> * 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.
>> Reading that blog entry I found discouraging the idea that dbus
>> might be required on my servers in the future, if systemd becomes
>> popular with distros.
>
> What's your objection to dbus? It gives you a standard message bus, is
> small, light, consumes minimal resources and provides a nice standard
> way to do IPC. Probably easier than reinventing the wheel with named
> pipes and other bits over and over.
>
> Now if it had similarities to say hal, I would instantly understand.
> But dbus is good and useful in all the ways that hal isn't.

Wasn't. HAL is dead. From http://www.freedesktop.org/wiki/Software/hal

"HAL is in maintenance mode - no new features are added. All future
development focuses on udisks, upower and other parts of the stack.
See Software/DeviceKit for more information."

HAL was an experiment, and it failed. At some point, dbus was an
experiment, and I think it succeeded. Most technologies (KDE, GNOME,
pulseaudio, udev, devfs, ALSA, systemd, upstart) start as experiments.
Some fail, some succeed, and some are replaced by even newer
experiments.

It's the only way new and interesting stuff gets created.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 08-23-2011, 07:43 PM
Alan McKinnon
 
Default systemd

On Tue 23 August 2011 15:06:25 Canek Peláez Valdés did opine thusly:
> > Now if it had similarities to say hal, I would instantly
> > understand. But dbus is good and useful in all the ways that
> > hal isn't.
> Wasn't. HAL is dead. From
> http://www.freedesktop.org/wiki/Software/hal

Sadly, HAL is not yet dead. It lives still.

It lives on the production database server I just happen to be
rebooting as I type this (another story for another time) and will
continue to live here for a very very long time indeed.

Dale can confirm this. Dale will swear in a court of law with hand on
bible than hal lives on in zombie form, infesting all the matter of
his house and computers, infecting them with their undead zombieness.

Ye gods, it's been a long hard day....



--
alan dot mckinnon at gmail dot com
 

Thread Tools




All times are GMT. The time now is 01:51 PM.

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