[gentoo-user] Runlevels, ordering initscripts and running them in background

[gentoo-user] Runlevels, ordering initscripts and running them in background

[Ignas Anikevicius]

Hello everybody,

I was wondering if the following is possible:
    - Add a lot of daemons to a newly created runlevel post-default
    - Switch to it after the xdm is started (or after some time)

I want to do this, so that I do not have to wait while non-crucial
services are being started (e.g. fcron, bitlbee, ntpd to name a few).
Maybe it is possible to somehow prioritize the initscripts?

Another related question is that I come from Arch and there I could just
give the *order* of the daemons/initscripts to start and some of them
could be started and 'in background'. Is it possible to do that with
openrc? I saw the rc_parallel option in rc.conf, but I do not know,
whether I need anything else.

Thanks for help,
Ignas A.

Re: [gentoo-user] Runlevels, ordering initscripts and running them in background

[Canek Peláez Valdés]

On Wed, May 16, 2012 at 3:40 AM, Ignas Anikevicius
<anikevicius@gmail.com> wrote:
> Hello everybody,
>
> I was wondering if the following is possible:
>    - Add a lot of daemons to a newly created runlevel post-default
>    - Switch to it after the xdm is started (or after some time)
>
> I want to do this, so that I do not have to wait while non-crucial
> services are being started (e.g. fcron, bitlbee, ntpd to name a few).
> Maybe it is possible to somehow prioritize the initscripts?
>
> Another related question is that I come from Arch and there I could just
> give the *order* of the daemons/initscripts to start and some of them
> could be started and 'in background'. Is it possible to do that with
> openrc? I saw the rc_parallel option in rc.conf, but I do not know,
> whether I need anything else.

Be aware that the rc_parallel option has never been really supported,
and it actually doesn't appear in the /etc/rc.conf of the one machine
I have access to that still uses OpenRC.

You may want to try systemd, it sounds like it does (out of the box)
exactly what you want to.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Runlevels, ordering initscripts and running them in background

[Dale]

Canek Peláez Valdés wrote:
> On Wed, May 16, 2012 at 3:40 AM, Ignas Anikevicius
> <anikevicius@gmail.com> wrote:
>> Hello everybody,
>>
>> I was wondering if the following is possible:
>>    - Add a lot of daemons to a newly created runlevel post-default
>>    - Switch to it after the xdm is started (or after some time)
>>
>> I want to do this, so that I do not have to wait while non-crucial
>> services are being started (e.g. fcron, bitlbee, ntpd to name a few).
>> Maybe it is possible to somehow prioritize the initscripts?
>>
>> Another related question is that I come from Arch and there I could just
>> give the *order* of the daemons/initscripts to start and some of them
>> could be started and 'in background'. Is it possible to do that with
>> openrc? I saw the rc_parallel option in rc.conf, but I do not know,
>> whether I need anything else.
> 
> Be aware that the rc_parallel option has never been really supported,
> and it actually doesn't appear in the /etc/rc.conf of the one machine
> I have access to that still uses OpenRC.
> 
> You may want to try systemd, it sounds like it does (out of the box)
> exactly what you want to.
> 
> Regards.


Just to add for the OP, this was discussed on -dev and it was removed,
although you can still try it if you want, a good while back because it
was causing problems.  I don't know anything much about systemsd but
according to the devs, you shouldn't use the parallel option with openRC
unless you want to keep up with the problems.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Runlevels, ordering initscripts and running them in background

[Ignas Anikevicius]

On 16/05/12 13:13, Canek Peláez Valdés wrote:
> On Wed, May 16, 2012 at 3:40 AM, Ignas Anikevicius
> <anikevicius@gmail.com> wrote:
>> Hello everybody,
>>
>> I was wondering if the following is possible:
>>    - Add a lot of daemons to a newly created runlevel post-default
>>    - Switch to it after the xdm is started (or after some time)
>>
>> I want to do this, so that I do not have to wait while non-crucial
>> services are being started (e.g. fcron, bitlbee, ntpd to name a few).
>> Maybe it is possible to somehow prioritize the initscripts?
>>
>> Another related question is that I come from Arch and there I could just
>> give the *order* of the daemons/initscripts to start and some of them
>> could be started and 'in background'. Is it possible to do that with
>> openrc? I saw the rc_parallel option in rc.conf, but I do not know,
>> whether I need anything else.
> 
> Be aware that the rc_parallel option has never been really supported,
> and it actually doesn't appear in the /etc/rc.conf of the one machine
> I have access to that still uses OpenRC.
> 
> You may want to try systemd, it sounds like it does (out of the box)
> exactly what you want to.
> 
> Regards.

I did know, that this was removed. If I experience problems I'll remove
the option, but maybe I'll remove it all together.

I have systemd installed as I wanted to try, but I do not like the way
everything is managed. I like the idea of simple bash initscripts, which
can be easily extended if needed. I can also write bash scripts, which
configure my system the way I want (i.e. set battery charging thresholds
or something similar).

I do not care for a split second advantage, but I just do not see a lot
of point in waiting for bitlbee to start before xdm so that I might need
maybe a while after I boot into my computer.

Thanks for suggestions to everybody.

Cheers,
Ignas

[gentoo-user] Re: Runlevels, ordering initscripts and running them in background

[walt]

On 05/16/2012 01:40 AM, Ignas Anikevicius wrote:

> I want to do this, so that I do not have to wait while non-crucial
> services are being started 

I can barely remember when I was young enough to care about saving
a few seconds.  (But, good for you :)

Have you heard of systemd?  Yet another evil conspiracy spawned by
Lennart Poettering, father of pulseaudio and scourge of old fossils
(like many of us here) who avoid any form of progress.

http://en.wikipedia.org/wiki/Systemd

My evil twin, Walter Dnes, has been agitating for systemd in this
mailing list for months.  He actually knows how systemd works and
can be persuaded to... well, I expect he'll be along shortly to
tell you about it.

Re: [gentoo-user] Re: Runlevels, ordering initscripts and running them in background

[Walter Dnes]

On Wed, May 16, 2012 at 05:43:50AM -0700, walt wrote

On 05/16/2012 01:40 AM__Ignas Anikevicius wrote:
                _    (  )   __      ____
> I want to do ( )s, s\ (ha(  \do n(    )e to wait while non-crucial
> services are__)\ng __) \ed) (   __)  /
      __   __(   (__/     )(   \ (     )
I can(  \ (              (__)  ( y)     \ou_h to care about saving
a few )  \_)                    )/       )( )
   _ (__                        '       (_/(__   ___
Ha(_)y__)                                     )n(   )cy spawned by
Lenna(___            S P L O R F           _ /cou)  )of old fossils
(like ma(       ___                   ____/f))ro(__/s.
    _(\  ) _   (   )  __      ____  __)  _ ( \_
htt(___)(_/i)   \i(  (g/\    (yste)(   _/ ) \__)
           (_____) \  ) (   __)  / /  (  (_
My evil twin_ Walter)(nes\ (as b(_/ agi)   )g for systemd in this
mailing lis(_)or mo(__). (  )actually (___/ how systemd works and
can be persuaded to... wel)/ I(_)pect he'll be along shortly to
tell you about it.        '

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-user] Re: Runlevels, ordering initscripts and running them in background

[walt]

On 05/16/2012 05:41 PM, Walter Dnes wrote:
> On Wed, May 16, 2012 at 05:43:50AM -0700, walt wrote
> 
> On 05/16/2012 01:40 AM__Ignas Anikevicius wrote:
>                 _    (  )   __      ____
>> I want to do ( )s, s\ (ha(  \do n(    )e to wait while non-crucial
>> services are__)\ng __) \ed) (   __)  /
>       __   __(   (__/     )(   \ (     )
> I can(  \ (              (__)  ( y)     \ou_h to care about saving
> a few )  \_)                    )/       )( )
>    _ (__                        '       (_/(__   ___
> Ha(_)y__)                                     )n(   )cy spawned by
> Lenna(___            S P L O R F           _ /cou)  )of old fossils
> (like ma(       ___                   ____/f))ro(__/s.
>     _(\  ) _   (   )  __      ____  __)  _ ( \_
> htt(___)(_/i)   \i(  (g/\    (yste)(   _/ ) \__)
>            (_____) \  ) (   __)  / /  (  (_
> My evil twin_ Walter)(nes\ (as b(_/ agi)   )g for systemd in this
> mailing lis(_)or mo(__). (  )actually (___/ how systemd works and
> can be persuaded to... wel)/ I(_)pect he'll be along shortly to
> tell you about it.        '


I love it! :-D

Naturally I immediately started planning to use it on other people,
but haven't figured out a way to automate it with sed or perl or
one of the other usual suspects.  Very clever :)

Suspend to {RAM,Disk] (was: Re: [gentoo-user] Re: Runlevels, ordering initscripts and running them in background)

[Alex Schuster]

walt writes:

> On 05/16/2012 01:40 AM, Ignas Anikevicius wrote:
> 
> > I want to do this, so that I do not have to wait while non-crucial
> > services are being started 
> 
> I can barely remember when I was young enough to care about saving
> a few seconds.  (But, good for you :)

Isn't rebooting uncool nowadays anyway? Apart from the time for booting,
you have to log in, and open all the stuff you need to do your work. At
least for me, this is a lot. My PC runs all day, because it runs some
services others need, so this is not an issue. But when I will no longer
need to do this, I will try to make suspend to {ram,disk} work.

Of course, while this seems to work just fine for most people, it doesn't
for me. I had trouble with suspending to disk (using tuxonice-sources) in
the past, when I was using ati-drivers (fglrx) instead of the open
source radeon drivers, which were not working for me at that time.
Sometimes it just worked, sometimes I had to try suspending for multiple
times, sometimes it did not work at all. Then I experienced file system
corruption of my root partition, and did not try again. Such a corruption
also happened on another PC, so I do not really dare to try this again
soon.

Suspend to ram (using the hibernate-ram command from
sys-power/hibernate-script) seems to work better. It is much faster, and
needs only a few watts for standby. But there seem to be side effects. My
ISDN setup does not work after suspending to RAM. Well, it doesn't work
anyway, but at least I can see incoming calls normally, which does not
work afterwards. And I cannot remove the ISDN modules before suspending,
maybe I should try an older kernel, where this was working. And one time
I I had trouble with any USB devices after suspend, but I'm not really
sure this was related, I cannot reproduce this now. Didn't try very often
yet, though.

I hope to get this working soon. I just found the rtcwake command
(sys-apps/util-linux), this allows to suspend to RAM and automatically
wake up at a specified date. Nice, I can set the PC to sleep, and it
wakes up before I have to :)

	Wonko

[gentoo-user] Re: Suspend to {RAM,Disk]

[Ignas Anikevicius]

On 18/05/12 20:59, Alex Schuster wrote:
> Suspend to ram (using the hibernate-ram command from
> sys-power/hibernate-script) seems to work better. 

What about pm-utils? Does it work better or worse than hibernate-script.
I had 0 problems with it during entire usage of linux, whereas with the
hibernate script package I had some issues...

And yes, I am usually suspending to ram, but I was just thinking about
possibilities to make my computer boot faster in the cases I really need
to do a restart. :)

Cheers,
Ignas

Re: [gentoo-user] Re: Suspend to {RAM,Disk]

[Volker Armin Hemmann]

Am Freitag, 18. Mai 2012, 22:42:59 schrieb Ignas Anikevicius:
> On 18/05/12 20:59, Alex Schuster wrote:
> > Suspend to ram (using the hibernate-ram command from
> > sys-power/hibernate-script) seems to work better.
> 
> What about pm-utils? Does it work better or worse than hibernate-script.
> I had 0 problems with it during entire usage of linux, whereas with the
> hibernate script package I had some issues...
> 
> And yes, I am usually suspending to ram, but I was just thinking about
> possibilities to make my computer boot faster in the cases I really need
> to do a restart. :)
> 
> Cheers,
> Ignas

I just do echo mem > ... or click on the 'Ruhezustand' button in KDE. Results 
in the same. Well working suspend-to-ram. With fglrx. X running etc pp. 

-- 
#163933

Re: [gentoo-user] Re: Suspend to {RAM,Disk]

[Canek Peláez Valdés]

On Fri, May 18, 2012 at 5:09 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Freitag, 18. Mai 2012, 22:42:59 schrieb Ignas Anikevicius:
>> On 18/05/12 20:59, Alex Schuster wrote:
>> > Suspend to ram (using the hibernate-ram command from
>> > sys-power/hibernate-script) seems to work better.
>>
>> What about pm-utils? Does it work better or worse than hibernate-script.
>> I had 0 problems with it during entire usage of linux, whereas with the
>> hibernate script package I had some issues...
>>
>> And yes, I am usually suspending to ram, but I was just thinking about
>> possibilities to make my computer boot faster in the cases I really need
>> to do a restart. :)
>>
>> Cheers,
>> Ignas
>
> I just do echo mem > ... or click on the 'Ruhezustand' button in KDE. Results
> in the same. Well working suspend-to-ram. With fglrx. X running etc pp.

With upower to suspend-to-ram you can just:

dbus-send --system --print-reply --dest="org.freedesktop.UPower"
/org/freedesktop/UPower org.freedesktop.UPower.Suspend

or use the "Suspend" option in GNOME 3 (GNOME uses upower). That I
already knew. What I didn't knew was that

dbus-send --system --print-reply --dest="org.freedesktop.UPower"
/org/freedesktop/UPower org.freedesktop.UPower.Hibernate

works as well for suspend-to-disk. I hadn't hibernated my laptop in
ages, it's good to know it still works. I use systemd+dracut, which I
suppose it matters for the hibernate option.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Suspend to {RAM,Disk]

[Volker Armin Hemmann]

Am Freitag, 18. Mai 2012, 17:26:10 schrieb Canek Peláez Valdés:
> On Fri, May 18, 2012 at 5:09 PM, Volker Armin Hemmann
> 
> <volkerarmin@googlemail.com> wrote:
> > Am Freitag, 18. Mai 2012, 22:42:59 schrieb Ignas Anikevicius:
> >> On 18/05/12 20:59, Alex Schuster wrote:
> >> > Suspend to ram (using the hibernate-ram command from
> >> > sys-power/hibernate-script) seems to work better.
> >> 
> >> What about pm-utils? Does it work better or worse than hibernate-script.
> >> I had 0 problems with it during entire usage of linux, whereas with the
> >> hibernate script package I had some issues...
> >> 
> >> And yes, I am usually suspending to ram, but I was just thinking about
> >> possibilities to make my computer boot faster in the cases I really need
> >> to do a restart. :)
> >> 
> >> Cheers,
> >> Ignas
> > 
> > I just do echo mem > ... or click on the 'Ruhezustand' button in KDE.
> > Results in the same. Well working suspend-to-ram. With fglrx. X running
> > etc pp.
> With upower to suspend-to-ram you can just:
> 
> dbus-send --system --print-reply --dest="org.freedesktop.UPower"
> /org/freedesktop/UPower org.freedesktop.UPower.Suspend
> 

which is way harder to type and memorize than:
echo mem > /sys/power/state

> or use the "Suspend" option in GNOME 3 (GNOME uses upower). That I
> already knew. What I didn't knew was that
> 
> dbus-send --system --print-reply --dest="org.freedesktop.UPower"
> /org/freedesktop/UPower org.freedesktop.UPower.Hibernate
> 
> works as well for suspend-to-disk. I hadn't hibernated my laptop in
> ages, it's good to know it still works. I use systemd+> dracut, which I
> suppose it matters for the hibernate option.

no, not really...
.
-- 
#163933

Re: [gentoo-user] Re: Suspend to {RAM,Disk]

[Canek Peláez Valdés]

On Fri, May 18, 2012 at 5:37 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Freitag, 18. Mai 2012, 17:26:10 schrieb Canek Peláez Valdés:
>> On Fri, May 18, 2012 at 5:09 PM, Volker Armin Hemmann
>>
>> <volkerarmin@googlemail.com> wrote:
>> > Am Freitag, 18. Mai 2012, 22:42:59 schrieb Ignas Anikevicius:
>> >> On 18/05/12 20:59, Alex Schuster wrote:
>> >> > Suspend to ram (using the hibernate-ram command from
>> >> > sys-power/hibernate-script) seems to work better.
>> >>
>> >> What about pm-utils? Does it work better or worse than hibernate-script.
>> >> I had 0 problems with it during entire usage of linux, whereas with the
>> >> hibernate script package I had some issues...
>> >>
>> >> And yes, I am usually suspending to ram, but I was just thinking about
>> >> possibilities to make my computer boot faster in the cases I really need
>> >> to do a restart. :)
>> >>
>> >> Cheers,
>> >> Ignas
>> >
>> > I just do echo mem > ... or click on the 'Ruhezustand' button in KDE.
>> > Results in the same. Well working suspend-to-ram. With fglrx. X running
>> > etc pp.
>> With upower to suspend-to-ram you can just:
>>
>> dbus-send --system --print-reply --dest="org.freedesktop.UPower"
>> /org/freedesktop/UPower org.freedesktop.UPower.Suspend
>>
>
> which is way harder to type and memorize than:
> echo mem > /sys/power/state

Yeah. However, he Dbus method works as a simple user; the
/sys/power/state thing you can only do it as root. At least in my
system.

>> or use the "Suspend" option in GNOME 3 (GNOME uses upower). That I
>> already knew. What I didn't knew was that
>>
>> dbus-send --system --print-reply --dest="org.freedesktop.UPower"
>> /org/freedesktop/UPower org.freedesktop.UPower.Hibernate
>>
>> works as well for suspend-to-disk. I hadn't hibernated my laptop in
>> ages, it's good to know it still works. I use systemd+> dracut, which I
>> suppose it matters for the hibernate option.
>
> no, not really...

The restore-from-hibernate requires booting the kernel in a special
way to load the memory state from the swap partition. That requires
special handling from the init process and the initramfs; we had a
discussion some weeks ago about genkernel not handling this correctly.

Maybe systemd has nothing to do with restore-from-hibernate working (I
don't know); but dracut surely does. It has a module called "resume"
that seems to handle this.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Suspend to {RAM,Disk]

[Canek Peláez Valdés]

On Fri, May 18, 2012 at 6:36 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Fri, May 18, 2012 at 5:37 PM, Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
>> Am Freitag, 18. Mai 2012, 17:26:10 schrieb Canek Peláez Valdés:
>>> On Fri, May 18, 2012 at 5:09 PM, Volker Armin Hemmann
>>>
>>> <volkerarmin@googlemail.com> wrote:
>>> > Am Freitag, 18. Mai 2012, 22:42:59 schrieb Ignas Anikevicius:
>>> >> On 18/05/12 20:59, Alex Schuster wrote:
>>> >> > Suspend to ram (using the hibernate-ram command from
>>> >> > sys-power/hibernate-script) seems to work better.
>>> >>
>>> >> What about pm-utils? Does it work better or worse than hibernate-script.
>>> >> I had 0 problems with it during entire usage of linux, whereas with the
>>> >> hibernate script package I had some issues...
>>> >>
>>> >> And yes, I am usually suspending to ram, but I was just thinking about
>>> >> possibilities to make my computer boot faster in the cases I really need
>>> >> to do a restart. :)
>>> >>
>>> >> Cheers,
>>> >> Ignas
>>> >
>>> > I just do echo mem > ... or click on the 'Ruhezustand' button in KDE.
>>> > Results in the same. Well working suspend-to-ram. With fglrx. X running
>>> > etc pp.
>>> With upower to suspend-to-ram you can just:
>>>
>>> dbus-send --system --print-reply --dest="org.freedesktop.UPower"
>>> /org/freedesktop/UPower org.freedesktop.UPower.Suspend
>>>
>>
>> which is way harder to type and memorize than:
>> echo mem > /sys/power/state
>
> Yeah. However, he Dbus method works as a simple user; the
> /sys/power/state thing you can only do it as root. At least in my
> system.
>
>>> or use the "Suspend" option in GNOME 3 (GNOME uses upower). That I
>>> already knew. What I didn't knew was that
>>>
>>> dbus-send --system --print-reply --dest="org.freedesktop.UPower"
>>> /org/freedesktop/UPower org.freedesktop.UPower.Hibernate
>>>
>>> works as well for suspend-to-disk. I hadn't hibernated my laptop in
>>> ages, it's good to know it still works. I use systemd+> dracut, which I
>>> suppose it matters for the hibernate option.
>>
>> no, not really...
>
> The restore-from-hibernate requires booting the kernel in a special
> way to load the memory state from the swap partition. That requires
> special handling from the init process and the initramfs; we had a
> discussion some weeks ago about genkernel not handling this correctly.
>
> Maybe systemd has nothing to do with restore-from-hibernate working (I
> don't know)

Oh, and less than two weeks ago systemd added suspend/hibernate targets on git:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=6edd7d0a09171ea5ae8e01b7b1cbcb0bdfbfeb16

Which of course is not necessary for suspend/hibernate to work, but it
is cool nonetheless.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Suspend to {RAM,Disk]

[Alex Schuster]

Ignas Anikevicius writes:

> On 18/05/12 20:59, Alex Schuster wrote:
> > Suspend to ram (using the hibernate-ram command from
> > sys-power/hibernate-script) seems to work better. 
> 
> What about pm-utils? Does it work better or worse than hibernate-script.
> I had 0 problems with it during entire usage of linux, whereas with the
> hibernate script package I had some issues...

I thought hibernate-ram and pm-suspend do the same... anyway, in my case
the ISDN stuff gets borked with either method. Too bad. Maybe I have to
switch to mISDN, as I cannot make the fcpci driver work to make outgoing
ISDN PPP connections. At the moment, I have to use another PC for that,
which still runs the old udev.
Or I can try another ISDN card I have (Cologne Chip Designs GmbH ISDN
network controller [HFC-PCI]), maybe I have more luck with this.

> And yes, I am usually suspending to ram, but I was just thinking about
> possibilities to make my computer boot faster in the cases I really need
> to do a restart. :)

Opening all my LUKS partitions takes so long anyway, I do not care much
about gaining a few seconds :)

	Wonko

Re: [gentoo-user] Runlevels, ordering initscripts and running them in background

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Wed, 16 May 2012 09:40:26 +0100, Ignas Anikevicius wrote:

> I want to do this, so that I do not have to wait while non-crucial
> services are being started (e.g. fcron, bitlbee, ntpd to name a few).
> Maybe it is possible to somehow prioritize the initscripts?

Yes it is. The initscripts themselves have such a mechanism, using the
before and after statements, for example making sure that network
services are started after the network is brought up. You can add your
own rules to the daemons' config files in /etc/conf.d or to /etc/rc.conf.

To have bitlbee start after xdm either add

rc_after="xdm" 

to /etc/conf.d/bitlbee or put

rc_bitlbee_after="xdm"

in /etc/rc.conf. Both have the same effect, it depends on whether you
want to put all these settings together or in the individual services'
config files.


-- 
Neil Bothwick

Tact is for people who don't understand sarcasm.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Runlevels, ordering initscripts and running them in background

[Ignas Anikevicius]

On 16/05/12 14:15, Neil Bothwick wrote:
> On Wed, 16 May 2012 09:40:26 +0100, Ignas Anikevicius wrote:
> 
>> I want to do this, so that I do not have to wait while non-crucial
>> services are being started (e.g. fcron, bitlbee, ntpd to name a few).
>> Maybe it is possible to somehow prioritize the initscripts?
> 
> Yes it is. The initscripts themselves have such a mechanism, using the
> before and after statements, for example making sure that network
> services are started after the network is brought up. You can add your
> own rules to the daemons' config files in /etc/conf.d or to /etc/rc.conf.
> 
> To have bitlbee start after xdm either add
> 
> rc_after="xdm" 
> 
> to /etc/conf.d/bitlbee or put
> 
> rc_bitlbee_after="xdm"
> 
> in /etc/rc.conf. Both have the same effect, it depends on whether you
> want to put all these settings together or in the individual services'
> config files.
> 

Thanks for the tip!, I will use this to see how much difference do I
get. :)

Cheers,
Ignas

Re: [gentoo-user] Runlevels, ordering initscripts and running them in background

[Joost Roeleveld]

On Wednesday, May 16, 2012 02:15:19 PM Neil Bothwick wrote:
> On Wed, 16 May 2012 09:40:26 +0100, Ignas Anikevicius wrote:
> > I want to do this, so that I do not have to wait while non-crucial
> > services are being started (e.g. fcron, bitlbee, ntpd to name a few).
> > Maybe it is possible to somehow prioritize the initscripts?
> 
> Yes it is. The initscripts themselves have such a mechanism, using the
> before and after statements, for example making sure that network
> services are started after the network is brought up. You can add your
> own rules to the daemons' config files in /etc/conf.d or to /etc/rc.conf.
> 
> To have bitlbee start after xdm either add
> 
> rc_after="xdm"
> 
> to /etc/conf.d/bitlbee or put
> 
> rc_bitlbee_after="xdm"
> 
> in /etc/rc.conf. Both have the same effect, it depends on whether you
> want to put all these settings together or in the individual services'
> config files.

Putting them in /etc/rc.conf makes it simpler to maintain the init-scripts 
when updating packages.
I used to put these things in the init-scripts and occasionally forgot about 
some of these during an update.

--
Joost

Re: [gentoo-user] Runlevels, ordering initscripts and running them in background

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On Sun, 20 May 2012 19:59:40 +0200, Joost Roeleveld wrote:

> > To have bitlbee start after xdm either add
> > 
> > rc_after="xdm"
> > 
> > to /etc/conf.d/bitlbee or put
> > 
> > rc_bitlbee_after="xdm"
> > 
> > in /etc/rc.conf. Both have the same effect, it depends on whether you
> > want to put all these settings together or in the individual services'
> > config files.  
> 
> Putting them in /etc/rc.conf makes it simpler to maintain the
> init-scripts when updating packages.
> I used to put these things in the init-scripts and occasionally forgot
> about some of these during an update.

Don't put them in the init scripts, those are overwritten during an
update, either rc.conf or the config files in /etc/conf.d.

If you want to arrange the order of several items, rc.conf is the logical
place, but if you just want to make sure service A starts before service
B, /etc/conf.d/[AB] is more sensible IMO.


-- 
Neil Bothwick

Press every key to continue.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]