@hal @cron in rc.conf

fsckd · 2009-10-15 01:12:00

I was under the impression it is a bad idea to background hal in rc.conf. Yet, I have read some remarks here and there by people who have done so with no negative effects experienced.

Also, is it safe to background cron? I'm using dcron (Dillon's Cron Daemon).

Thanks.

fyi: DAEMONS=(syslog-ng @network @dnsmasq !netfs crond hal @sensors)

Inxsible · 2009-10-15 01:46:33

I have backgrounded everything except syslog-ng. Have been running since the last 4-5 yrs. No issues.

guzz46 · 2009-10-15 01:54:31

I'm no expert on the subject but i think if you are booting into a GUI it's best not to background hal, i have tried it before and ended up with a locked system (no mouse movement or keyboard input)

Also i think it's best if you start hal after syslog-ng
DAEMONS=(syslog-ng hal @network @dnsmasq !netfs @crond @sensors)

I have crond backgrounded and have experienced no problems

fsckd · 2009-10-15 03:27:44

Thanks for your suggestion guzz46. Is there any reason why that order is preferred?

Inxsible, do you boot to a GUI?

guzz46 · 2009-10-15 03:42:22

I think certain services and/or daemons depend on hal to be running before they start otherwise you could end up with problems.

Inxsible · 2009-10-15 03:42:52

fsckd wrote:

Thanks for your suggestion guzz46. Is there any reason why that order is preferred?
Inxsible, do you boot to a GUI?

I do not use any DM ...I use startx to directly take me to the desktop. And yes, my WM is musca and I do use a bunch of other GUI apps

gog · 2009-10-15 05:25:58

You can safely background hal if you put this in your ~/.bash_profile:

if test -z $DISPLAY && test -e /var/run/hald.pid; then
                startx
                logout
else
               echo "bash: HAL isn't running, it's not a good idea to startx, kthx"
fi

edit: This one is less ugly

Last edited by gog (2009-10-15 06:06:02)

bernarcher · 2009-10-15 07:54:24

You should never background hal and call it as early as possible, even if obviously no problems do occur in one installation or another. This is because hal is responsible for some basic I/O setup. It must have finished its work before others can make full use of the system.

On the other hand it should be safe to background cron as its services are used after system startup.

Thus this setup looks good to me:

DAEMONS=(syslog-ng hal @network @dnsmasq !netfs @crond  @sensors)

Last edited by bernarcher (2009-10-15 07:55:39)

fsckd · 2009-10-15 15:27:02

Thank you everyone for the information and suggestions. For the sake of curiosity I backgrounded hal to see what happens. Nothing bad occurred in terms of services. Part of the bootup was much, much faster. However, my desktop still appeared at the usual time mark with a longer interval after init. With no real benefit, I've decided to keep hal unbackgrounded. (Are there real words for this?) Better to be safe than sorry. My DAEMONS line is now as suggested:

DAEMONS=(syslog-ng hal @network @dnsmasq !netfs @crond @sensors)

Inxsible · 2009-10-15 15:49:54

Among all the backgrounded daemons ...they will start in order. So from the above examples , network will start before ...and etc..

so as long as hal is the FIRST backgrounded daemon and there are no daemons before that which need hal, backgrounding it is not a problem. Also, the time needed for you to reach your desktop and are able to do anything with the system, is sufficient for all the backgrounded daemons to start.

bernarcher · 2009-10-15 23:42:57

Inxsible wrote:

Among all the backgrounded daemons ...they will start in order. So from the above examples , network will start before ...and etc..
so as long as hal is the FIRST backgrounded daemon and there are no daemons before that which need hal, backgrounding it is not a problem.

It is not that easy, because it does not depend on when hal was started but when hal's setup actions did proceed far enough so that when some later process needs those services, they are really available,

Thus you may be lucky but there is no guarantee. The behaviour might change even with a simple software update.

fsckd · 2009-10-16 15:45:43

Inxsible wrote:

Also, the time needed for you to reach your desktop and are able to do anything with the system, is sufficient for all the backgrounded daemons to start.

My assumption is when the tty login screen appears, init has finished with it's boot up work. After that, the system switches to tty7 and x starts followed by my desktop. Without backgrounding hal, the desktop appears 28 seconds after bootup and about 3 or 4 seconds after the tty login appears. When I background hal, the tty login appears at the 20 second mark and I'm sitting at a blank screen for about 5 or 6 seconds before my desktop appears, still at the 28 second mark. My guess is x.org waits for hal to start before it does anything. I believe x checks hal for hardware detection. I may have to change its settings to not auto-detect hardware but I'm a lazy guy .

lustikus · 2009-11-17 13:53:48

ist it safe to background network?
network is by far the longest one to load on my system.
I also have ifplugd and privoxy in my daemon list, so it's probably not a good idea?

Arch Linux

#1 2009-10-15 01:12:00

@hal @cron in rc.conf

#2 2009-10-15 01:46:33

Re: @hal @cron in rc.conf

#3 2009-10-15 01:54:31

Re: @hal @cron in rc.conf

#4 2009-10-15 03:27:44

Re: @hal @cron in rc.conf

#5 2009-10-15 03:42:22

Re: @hal @cron in rc.conf

#6 2009-10-15 03:42:52

Re: @hal @cron in rc.conf

#7 2009-10-15 05:25:58

Re: @hal @cron in rc.conf

#8 2009-10-15 07:54:24

Re: @hal @cron in rc.conf

#9 2009-10-15 15:27:02

Re: @hal @cron in rc.conf

#10 2009-10-15 15:49:54

Re: @hal @cron in rc.conf

#11 2009-10-15 23:42:57

Re: @hal @cron in rc.conf

#12 2009-10-16 15:45:43

Re: @hal @cron in rc.conf

#13 2009-11-17 13:53:48

Re: @hal @cron in rc.conf

Board footer