dbus and hal: start 'em?

fuscia · 2008-11-12 13:21:09

should these two be on my list of daemons to be started, or not?

peets · 2008-11-12 13:55:33

Do you need them? They will be useless if none of your apps use them.
I added them recently because I switched to the evdev input driver for x.org which needs hal.
But the less software you have running, the safer and faster your system is; don't add them if everything is running fine I guess.

Gullible Jones · 2008-11-12 14:00:45

If you have hal on your daemon list, you don't need dbus; the hal script starts that automatically.

fuscia · 2008-11-12 14:16:50

Gullible Jones wrote:

If you have hal on your daemon list, you don't need dbus; the hal script starts that automatically.

whoa! either way, that's good to know.

here's my list - syslog-ng network netfs crond alsa. can i do without any of those? would putting @ in front of any of them make a difference? am i missing something key?

i appreciate the answers. i try to read about this stuff, but it can be so foreign, at times, i still have no sense of judgment about it.

elmer_42 · 2008-11-12 14:38:46

For me, network takes a long time to start up. I added an @ to the front of it just so it wouldn't take so long to boot up.

fuscia · 2008-11-12 14:58:48

elmer_42 wrote:

For me, network takes a long time to start up. I added an @ to the front of it just so it wouldn't take so long to boot up.

wow! that took about ten seconds off boot up time. thanks.

kclive18 · 2008-11-12 15:09:44

Yeah, I background all the services in my DAEMONS array in /etc/rc.conf. It saves a lot of time, especially since this laptop has a wireless connection and it takes a good amount of time to associate with the nearest AP.

ashyanbhog · 2008-11-12 15:26:28

fuscia wrote:

Gullible Jones wrote:
If you have hal on your daemon list, you don't need dbus; the hal script starts that automatically.
whoa! either way, that's good to know.
here's my list - syslog-ng network netfs crond alsa. can i do without any of those? would putting @ in front of any of them make a difference? am i missing something key?
i appreciate the answers. i try to read about this stuff, but it can be so foreign, at times, i still have no sense of judgment about it.

You can disable daemons with ! like !crond and see if you are losing functionality in everyday usage. Check what each daemon does, crond is for task scheduling, so if u dont have tasks, u can disable it and re-enable it if u want to add tasks sometime in future.

daemons like alsa, crond can boot in background. even my network is background

I would recommend having Arch CD nearby just so you can CD boot and chroot if somehow (unlikely) the system gets screwed,

besides, u would have got better answers if u were more specific on system usage profile,

Last edited by ashyanbhog (2008-11-12 15:27:14)

fuscia · 2008-11-12 15:37:35

ashyanbhog wrote:

besides, u would have got better answers if u were more specific on system usage profile,

i don't know what you're talking about. i asked the question i wanted to and got the type of answer i was looking for.

edit: my question is really out of a need for a sense of perspective than specific details. my problem with open source documentation is that it generally seems to be missing chapter one.

Last edited by fuscia (2008-11-12 15:57:17)

fuscia · 2008-11-12 16:39:54

update (i'm sure you've all been on the edge of your seats): looks like all i needed hal for was k3b. i'm gonna try tcdr instead. that should up my minimalist cred a few notches. good times.

thayer · 2008-11-12 17:52:54

@syslog-ng @hal @network !netfs @crond @alsa

That's my take. It should speed things up a bit too. netfs is enabled by default (why I don't know) but is almost certainly wasted on most installations. If you aren't connecting to netfs shares (and you'd know if you were) then you can safely remove or disable (!) this daemon. Everything else can be sent to the background (@).

fuscia · 2008-11-12 18:07:05

i looked up netfs and didn't understand a word of it.

Misfit138 · 2008-11-12 18:10:28

Do you use cron for anything?
If not, disable it.

string · 2008-11-12 18:39:38

I believe in a recent thread a user was complaining about his log sizes. From this point of view (at least) I'd keep crond.

fuscia · 2008-11-12 18:53:43

the last thing i need is bigger logs.

fuscia · 2008-11-12 20:58:10

uh, would i know if i used crond? in other words, is it something that i would have to initiate directly, or is it something some other daemon/app/whatever would use that i wouldn't know about because i don't know about such things?

Profjim · 2008-11-12 22:49:19

When the crond service is running, the scripts in /etc/cron.{hourly,daily,weekly,monthly} get run at the appropriate intervals. These scripts do useful things like update your locate database, rotate your logs, and so on. You may not have put anything of your own in there, but at least a few packages are likely to have done so. Having crond turned off for a week or two is no big deal. I wouldn't want to work on a system that hasn't run any of the crond scripts in months.

Myself, I've added my own jobs to these folders, to do backups, download a list of what packages are on AUR, and so on.

I think the crond daemon itself will be a really negligible drag on your system. When the scripts are running though, your system will temporarily see a burst of activity (depending on what the script is doing).

shazeal · 2008-11-13 00:56:36

If you have a decent amount of ram, I wouldnt worry about minimizing the daemons running. Apart from a bit of memory usage most of them will be in sleep mode 99% of the time and the scheduler will give them a low prio as far as cpu goes anyway.
Removing stuff like crond is a really bad idea, a better idea is to learn what it does and use it. As far as dbus/hal, its far easier to just run them and then when something needs them you dont even know it rather than messing about later on wondering why some program is not working.

moljac024 · 2008-11-13 01:07:49

shazeal wrote:

If you have a decent amount of ram, I wouldnt worry about minimizing the daemons running. Apart from a bit of memory usage most of them will be in sleep mode 99% of the time and the scheduler will give them a low prio as far as cpu goes anyway.
Removing stuff like crond is a really bad idea, a better idea is to learn what it does and use it. As far as dbus/hal, its far easier to just run them and then when something needs them you dont even know it rather than messing about later on wondering why some program is not working.

Totally agree with this opinion. Some people just go too far with optimization.

"So, you've cut down your memory and cpu usage to below 1% have you ? Nice.... how much did that Core2Quad and those 4 gigs of memory cost btw ? "

elmer_42 · 2008-11-13 01:30:40

Personally, I don't really mind daemons running. I just mind them taking forever at startup, which is why I have so many of them backgrounded.

thayer · 2008-11-13 03:13:05

Every application poses some security risk while it's running. Most daemons run with administrative privileges and quite a few also monitor network ports for incoming connections and react accordingly--these pose a significant security risk. My philosophy is to disable everything I don't need.

shazeal · 2008-11-13 05:58:53

Every application poses some security risk while it's running. Most daemons run with administrative privileges and quite a few also monitor network ports for incoming connections and react accordingly--these pose a significant security risk. My philosophy is to disable everything I don't need.

Paranoia can be taken too far. If I was setting up a server that would be exposed to unknown users, which I do quite often. Sure I would make sure daemons are locked down, and that only stuff needed is running, thats just common sense.
However for a home computer, running behind a firewall, Its just plain overkill and actually a bad philosophy. Setting up your box correctly, securing it, and understanding what the things running do is far more important than just shutting stuff down, ignorance is the biggest security risk not daemons

fuscia · 2008-11-13 06:29:25

turning off netfs and loading network in the background made a time difference in the boot. the rest of it did nothing (although, i think when i loaded crond and alsa in the background, it took 2 seconds longer).

the problem i have with finding out what everything does is that most of the explanations mention a whole bunch of other things i've never heard of. i end up even more at a loss than i had been before i read it. it's not just a few things, it's almost everything i read about open source software.
for me, aside from being minimalist in a lot of areas in my life, keeping a minimal setup means there's just that much less for me to be bewildered by. recently, i got curious about slackware. i started reading the slackbook and realized just how spoiled i'd become by the arch documentation (i don't care if you have a 1st edition copy of mao's red book, just tell me what i need to know).

Arch Linux

#1 2008-11-12 13:21:09

dbus and hal: start 'em?

#2 2008-11-12 13:55:33

Re: dbus and hal: start 'em?

#3 2008-11-12 14:00:45

Re: dbus and hal: start 'em?

#4 2008-11-12 14:16:50

Re: dbus and hal: start 'em?

#5 2008-11-12 14:38:46

Re: dbus and hal: start 'em?

#6 2008-11-12 14:58:48

Re: dbus and hal: start 'em?

#7 2008-11-12 15:09:44

Re: dbus and hal: start 'em?

#8 2008-11-12 15:26:28

Re: dbus and hal: start 'em?

#9 2008-11-12 15:37:35

Re: dbus and hal: start 'em?

#10 2008-11-12 16:39:54

Re: dbus and hal: start 'em?

#11 2008-11-12 17:52:54

Re: dbus and hal: start 'em?

#12 2008-11-12 18:07:05

Re: dbus and hal: start 'em?

#13 2008-11-12 18:10:28

Re: dbus and hal: start 'em?

#14 2008-11-12 18:39:38

Re: dbus and hal: start 'em?

#15 2008-11-12 18:53:43

Re: dbus and hal: start 'em?

#16 2008-11-12 20:58:10

Re: dbus and hal: start 'em?

#17 2008-11-12 22:49:19

Re: dbus and hal: start 'em?

#18 2008-11-13 00:56:36

Re: dbus and hal: start 'em?

#19 2008-11-13 01:07:49

Re: dbus and hal: start 'em?

#20 2008-11-13 01:30:40

Re: dbus and hal: start 'em?

#21 2008-11-13 03:13:05

Re: dbus and hal: start 'em?

#22 2008-11-13 05:58:53

Re: dbus and hal: start 'em?

#23 2008-11-13 06:29:25

Re: dbus and hal: start 'em?

Board footer