basic proccess
 

Hi everyone

I use fc2 and rh9 in my servers. They run very slowly now since many proccesses are running. I want to kill most of them but i don't know which one is system proccess and which one belong to users. Pls. give me a list of basic proccesses, which system need to run and how to know which proccess belong to which user.

Thank you

Check the man page for the ps command - it can give you all this info, except which processes you should not kill. Basically, don't kill init, and don't kill anything you want to keep running. If in doubt, check the man page for the command to see if it's something safe to kill. syslogd and klogd are good processes to leave running!

Fedora Core 3 - uneccessary processes?
 

As far as I can tell, the man page for PS will not tell you what all of these processes are .... unless I missed something in those 15 pages ... :)

I am a newbie as well and I am trying to work out what processes to leave running etc and what to kill.

I did a minimal install of FC3 with the following caveats, I want to run:
- DNS (though I can't see the named daemon running yet ... !)
- DHCP (only temporary)
- portmap (will do some security stuff)
- SSH (for remote management)
- email (send only - do I need all of sendmail to do this?)
Think that was all I wanted to run.

Here is waht is currently running on my server. I have tried to research all of the prcesses, but I am sure at least a few are wrong ... :(

init - KERNEL
ksoftirqd/0 - KERNEL
events/0 - KERNEL???
khelper - KERNEL
kblockd/0 - KERNEL
khubd - KERNEL
pdflush - KERNEL; (page dirty flush; something to do with page file/swap??)
pdflush - KERNEL; (page dirty flush; second copy)
aio/0 - NFI!!
kapmd - NFi!!
kswapd0 - KERNEL (swap??)
kseriod - KERNEL
exec-osm/0 - Pretty sure this is my SCSI RAID driver
block-osm/0 - Pretty sure this is my SCSI RAID driver
kmirrord/0 - NFI
kjournald - KERNEL; (Journalling file system ?)
kjournald - KERNEL; (not sure why I have so many running ....)
kjournald
kjournald
kjournald
kjournald
udevd - "part of the hotplug subsystem" (USb support etc)
dhclient - DHCP client
syslogd - syslog daemon (writes system events to disk)
klogd - "Control which kernel messages are displayed on the console" (like syslog .. but different)
portmap - "Portmap is a server that converts RPC program numbers into DARPA protocol port numbers." (not too sure .. sounds obvious, but is it necessary?)
rpc.statd - "reboot notification service." (used by NFS)
rpc.idmapd - something to do with NFS
apmd - advanced power management system (I swear I didn't ask for this to be installed ...)
cupsd - printer daemon
sshd- SSH Daemon
xinetd - replacement for inetd, the internet services daemon
sendmail - mail server
sendmail - another copy of the mail server! (just in case we need two??)
gpm - general purpose mouse support
crond - daemon to execute scheduled commands
anacron - daemon to execute scheduled commands (doesn't assume the machine is up 24/7 9so it will run 'missed' tasks)
atd - atd daemon which runs commands at a specified time as scheduled by the "at" command
dbus-daemon-1 - Message bus daemon; provides one-to-one communication between any two applications
hald - Hardware Abstraction Layer Daemon (plug and play stuff from the looks of it)
login - login daemon
mingetty - mingetty is a minimal getty for use on virtual consoles; getty monitors serial lines, waiting for a connection; (you need it to login)
mingetty - why are there so manY???
mingetty
mingetty
bash - born again shell (?) - "A "shell" is a program which interprets commands" (you need this to execute stuff in console)
sshd - another SSH daemon ... coz one ain't enough
bash - more bash ...
makewhatis - makewhatis extracts the name and a short description from unformatted manpages and creates the whatis(1) database. (not always running .. just appears from time to time)
ps - command to show this output (i.e. all running processes etc)

The stuff I was thinking of removing/uninstalling:
- udevd: won't be running any plug and play stuff
- hald: won't be running any plug and play stuff
- dhclient: I will manually set the IP address soon enough
- klogd: do I need this if syslog is running?
- rpc.statd : I am not using NFS (at least I don't think I am!)
- rpc.idmapd : I am not using NFS (at least I don't think I am!)
- apmd: this is not a laptop!
- cupsd: I have no printer!
- gpm: I only use SSH, no GUI
- makewhatis: never even heard of this .. only use Man pages anyway (I just need to work out how the hell it started up anyway!)

Stuff I am not sure about:
- sendmail: I want to be able to send emails, but not receive them; Do I need to run all of sendmail? Can I run the equivalent of outlook (bad example I know) to connect to a mail server in oder to send email, rather than running a whole mail server?
- dbus-daemon-1: what the hell uses this???

I would appreciate any comments on either what some of those processes are (especially if I got the description wrong) and/or which processes I need to leave running.

Thanks in advance.

Ant

I think I wasn't very clear in what I said... the man page for ps will tell you all about how to use ps to find which user started what, how long it's been running, etc etc. If you want to know what a process does, check the man page for THAT instead. That is, if you want to know whether it should be safe to kill syslogd, check the man page for syslogd to find out what it does. Unfortunately, some processes don't have man pages :(

Plug and play is not the only thing udev is used for. You should be able to remove it if you are happy to stick to the old method of having every possible node under /dev, or if you're going to switch to devfs.

I really have no idea what this is. I found a mention of a HAL project on freedesktop.org, but whether this is the same thing or not, I don't know. Use RPM to find out which package the file came from, and then check which packages depend on that. That will go a long way toward figuring out whether you can remove it. In fact, that's probably good advice for any package.

If you switch to a static, you can get rid of this safely.

Yes. klogd logs kernel messages - the kernel cannot rely on syslog running, so it doesn't use that mechanism for its error messages.

I think you would know if you were using NFS, as you would have had to set it up :) Removing these should be fine.

APM is not limited to laptops... check whether apmd provides any functionality you care about (putting your computer in suspend mode and such)

Yeah, Redhat always did want to keep installing that damn thing as a prereq for other packages. I used to remove it with no hassles (but I now have a printer and no Redhat)

GPM offers mouse support for terminals - if you'd like to use mouse-based copy and paste on the terminal itself, leave GPM installed (it is quite handy if you need to fix the machine without a network connection, and doesn't consume many resources when it's not being used)

makewhatis generates a man page keyword database. If you've ever found 'apropos' useful, you should leave this alone. It shouldn't be running all the time anyway, it would be a scheduled task that takes a few minutes to complete.

Yes, you can configure your mail client to use your ISP's SMTP server instead of a local one, but other services on the machine may try to email status information to you via the local mail delivery. If you don't like sendmail (and who does?), you could switch to postfix with a minimal config.


Looks like another freedesktop.org app... have a read of this: http://linux.com.hk/PenguinWeb/manpa...=dbus-daemon-1

More detail
 

which option you use with ps command to get that ps main page you talked about ?
ps -A : give list of all ps only
ps --user name : list of ps of name
...

Which one give us the list of system ps, which clean system uses to start up ?

CroMagnon: thanks for the reply, that clears up quite a few things. One question though, what is a node? You talked about it in reference to udevd.

acrors: not sure what you mean ... I mentioned the man page for PS, which gives you all 15 pages of info. To get that type: man ps

You can pretty much use man <insert_command> to get info on most commands.

Regarding ps:
ps (gives you a list of processes running under your credentials)
ps -U root (processes running under root credentials)
ps r (only running processes)
ps -eM (shows user/security info for running processes)

There is no ps command that is going to show you which system processes boot or use to boot. You need to check init.d for which things are started on boot (at least I think that is where it is all kept):
/etc/rc.d/init.d/ (contains scripts that get run at start up)

More info on what udev does .... don't think I will be disabling this!

Fedora Core 3 includes a new subsystem for managing devices called udev, which replaces devfs. Udev makes it easier to manage hot-plug devices such as USB (Universal Serial Bus) peripherals, in part by allowing these devices to have persistent user- or system-definable names. For instance, under devfs, it could be difficult to distinguish connected USB devices, information you had to know to mount them for use.

Users have reported udev-related problems, including an issue with Nvidia Corp.'s graphics card driver, for which a workaround is available at fedora.redhat.com/ docs/udev.

I am not sure that killing processes is the way to go about this.

What you should do is edit your services file (etc/service) to disable those services that you do not want to start. You could also just remove them from /etc/init.d and then reboot.

Unless you are very skilled, which you have indicated that you are not, just willie-nillie killing processes will undoubtably lead to a faulty system. To make things worse, when you are forced to reboot because you have crushed your system, they will all just start up again anyway.

If you are concerned about running a lean mean server, you should set your system up that way from the start.

Shane

I would agree with scmason on determining what services are required and which ones can be removed. On RH 9 and Fedora you can look over what services are running using the Service Configuration app under the System menu. As you click on each service it will give you a short summary of what it does so you can decide what stays and what goes.

On another note perhaps you should take a look at what is consuming your resources. A quick way to do this is to use the top command. There are other ways, but top will give you a place to start. It really isn't a good practice to kill things unless you know how they were started. Afterall, what's to stop them from starting up again if you don't know where they came from?

Bill

Every piece of hardware under linux has a corresponding 'node' under /dev. For example, each IDE device gets a node like hda, hdb, hdc etc etc. These look like files, but they're a little different - if you read /dev/hda, you will actually get the raw data that's sitting on your first IDE drive. The old way of making sure the appropriate nodes were present was to try and make sure every possible node you might need is already created - that's why you'll find hdd, hde, hdf etc etc under the /dev directory on older installs, even when you don't have that many drives. The idea behind devfs and udev (at least, I think) was to have a more fluid setup that only had nodes for the devices you actually had (which means updating /dev when you plug in a USB device, or whatever).

As for the recent comments about killing things, they're pretty much right, except that the original comment mentioned killing before uninstalling things, so I assume they want to kill certain processes and see if their machine is still functional before uninstalling the packages. If anything goes wrong, a reboot is all you need to fix it again, whereas if something goes wrong after uninstalling the package(s), you have to repair the less functional system by hand.

Of course, where possible, using the appropriate shutdown script for any process is a better idea. Check /etc/init.d (or /etc/rc.d/init.d) for a script that matches the process, and try "/etc/init.d/script stop".

scmason: Thanks for the input. I think my slang may have gotten in the way a little - I was actually talking about stopping the services/daemons from running by editing the /etc/init.d directory/scripts rather than just using the command 'kill'. Shutting down stuff randomly may be the way to solve problems in the windows world ("55 processes running?? Bah! Shut down everything that you can!"), but I understand that under unix we like to keep things a bit 'cleaner'. I didn't realise though that you could disable daemons by modifying the services file though - which method is preffered and why? Is it better to disable the daemon via the services file and leave the scripts in place so that if you decide to re-enable the service all you do is uncomment the service in the services file? I had actually thought that the services file was simply a list of services and the ports that they commonly ran on ....

wmakowski: Thanks also. I am aiming to run the minimal amount of services not because my machine is under strain (it is really only sitting at around 5 - 10 % utilisation), but because I want to learn more about what processes/daemons are actually needed to run a linux box, and also because I want to limit my exposure to security vulnerabilities. So, I would try out the Service Configuration app if I could ... but I did not install a GUI ;)

CroMagnon: Thanks for the update on Udev & nodes - had no idea what the hell they were for.

As a side not, can I just say that if you have never ever used YUM before, drop what you are doing right now and go and try it out! I patched my machine last night with two commands:

rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora
yum update

A few minutes later, it had downloaded and installed all of the following:
Installed: kernel.i686 0:2.6.9-1.681_FC3
Dependency Installed: desktop-file-utils.i386 0:0.9-2
Updated: bash.i386 0:3.0-18 hotplug.i386 3:2004_04_01-8 initscripts.i386 0:7.93.5-1 ipsec-tools.i386 0:0.3.3-2 iptables.i386 0:1.2.11-3.1.FC3 jwhois.i386 0:3.2.2-6.FC3.1 libselinux.i386 0:1.19.1-8 libxml2.i386 0:2.6.16-3 libxml2-python.i386 0:2.6.16-3 man.i386 0:1.5o1-7 policycoreutils.i386 0:1.18.1-2 prelink.i386 0:0.3.3-0.fc3 redhat-menus.noarch 0:3.7.1-1.fc3 selinux-policy-targeted.noarch 0:1.17.30-2.34 shadow-utils.i386 2:4.0.3-40 slang.i386 0:1.4.9-13 system-config-securitylevel-tui.i386 0:1.4.18-2 udev.i386 0:039-10.FC3.2 wireless-tools.i386 1:27-0.pre25.3 words.noarch 0:3.0-2 xorg-x11-Mesa-libGL.i386 0:6.8.1-12.FC3.1 xorg-x11-libs.i386 0:6.8.1-12.FC3.1 zip.i386 0:2.3-26.3

And all I had to do was press Y once! Amazing!

Heh, Debian and FreeBSD ports would blow your mind ;) But seriously, it'll be good to know about yum if I ever use an RPM based distro again.

Oh, and /etc/services is just a list of ports and names. I think the original poster was referring to something like /etc/inetd.conf, but fewer services seem to use inetd these days.

kava_kicks: Since you are using terminal mode rather than a GUI you will want to check out the command chkconfig. This tool will allow you to list what services are running as well as perform any modifications. It is best to leave the init scripts in /etc/init.d alone. That way if you decide to add the service later on you don't have to create a script for it.

chkconfig functions by adding and removing symbolic links in the run level directories. You are most likely starting up in runlevel 3 which means that the symbolic links under /etc/rc.d/rc3.d control what services start and stop during bootup and shutdown. To check the default runlevel your system uses look at file /etc/inittab for a line similar to id:3:initdefault: the 3 means runlevel 3 if by chance it has a different number that is your runlevel.

The chkconfig man page is for the most part self explainatory. Just post a question if you run into any issues. The /etc/services file links up services to the ports they use. It is used mainly by xinetd which is the extended Internet Services daemon. CroMagnon referred to inetd which is a precursor to xinetd and still used in a number of Linux distributions. They both do basicly the same thing which is start services when they are requested by an application. It allows you to set up on demand services. For example, you may not want your ftp daemon to run all the time so you set it up in xinetd. When someone wants to use it the service starts and when they are done it shutsdown. You shouldn't have to mess with /etc/services file unless you are adding a custom service or securing a port.

Bill

Hey CroMagnon, are you referrring to APT? A lot of people I consulted with before deciding on a distro were advocating Debian because of its strong package management support and purely open-source nature. I also wanted to have a bash at BSD becuase I like the idea of running such a secure OS. Actually, I was originally trying to get a copy of Debian running, but I was struggling to find support for my SCSI RAID card (a DPT card). I spoke to a couple of people and it seemed like it was not supported - even in Sarge (I was trying to install Woody at the time). I then found some stuff on 3rd party drivers ... but decided that I didn't really want to have to recompile the kernel on my first attempt at a linux install!

Now that I have installed FC3 though, I have to say that I am pretty damn impressed: both at the package management (thank god for YUM) and with the security enhancements that are in place as a result of SELinux (though my firewalll is currently a wide-open gate .. but i will deal with that in another thread!).

wmakowski: thanks for the tip on chkconfig - I had never seen it before. I ran it just then and it certainly looks pretty good. I was actually going to ask you why commands appear there that are not currently running (e.g. Yum), but you already answered my question! I also just found ntsysv (text-based GUI equivalent of chkconfig) .... but I think I will stick to the CLI! Text-based GUIs freak me right out (anyone ever worked on an old Cisco IOS? Painful). One thing I was not sure of though: if you set something to run at runlevel 1, will it run at runlevel 2, 3, etc? Or will it *only* run when the machine is at runlevel 1??

If anyone is reading and had no idea how run-levels worked (like me!), check this out:
http://www.redhat.com/docs/manuals/l...down-init.html

Thanks again guys.

Any modifications made when using chkconfig will only apply to the runlevel(s) you specify. You can modify multiple runlevels at the same time. For example, if I wanted to turn identd on in runlevels 3 and 5 I could use the command.

chkconfig --levels 35 identd on

Bill