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 01-16-2009, 08:26 AM
Susan Dridi
 
Default Daemons

I'm curious about some daemons that are running. Do I need the icecast
server or the portmap daemon for anything? I noticed those two in the
boot messages, not sure what other daemons are running or if I need them.


I'm trying to figure out what is accessing my hard drive a couple of
times a second. The blue light in the front of my computer is constantly
flashing, even when I'm not doing anything and don't have any
applications open.


Thanks!

-Susan

P.S. - Daniel, can't wait to get your book!

_______________________________________________
64studio-devel mailing list
64studio-devel@64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 01-17-2009, 02:17 PM
Gustin Johnson
 
Default Daemons

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Susan Dridi wrote:
> I'm curious about some daemons that are running. Do I need the icecast
> server or the portmap daemon for anything? I noticed those two in the
> boot messages, not sure what other daemons are running or if I need them.
>
> I'm trying to figure out what is accessing my hard drive a couple of
> times a second. The blue light in the front of my computer is constantly
> flashing, even when I'm not doing anything and don't have any
> applications open.
>
Icecast is for broadcasting mp3s and the like accross the net, so it
does not need to be running all the time. Portmap is used by a number
of things (anything that makes use of RPC), most notably NFS and should
not really be a problem. It should still be safe to run
"/etc/init.d/portmap stop" to see if that helps.

For tracking down disk I/O usage, I start with iostat:
For a better formated version:
http://pastebin.com/f4625c32e

iostat -x
Linux 2.6.24-19-generic (midwinter) 17/01/09

avg-cpu: %user %nice %system %iowait %steal %idle
17.55 5.18 14.45 1.03 0.00 61.79

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
avgrq-sz avgqu-sz await svctm %util
sda 0.09 0.08 0.01 0.00 1.27 0.69
140.81 0.00 18.12 8.36 0.01
sdb 0.01 8.93 0.21 2.73 1.81 93.26
32.39 0.02 5.22 0.45 0.13
sdc 0.48 24.34 1.74 6.30 29.84 245.33
34.21 0.35 43.61 1.60 1.29
sdd 0.09 0.06 1.46 0.68 333.57 190.40
244.28 0.06 27.14 3.10 0.66
sde 0.05 1.11 4.01 5.09 75.26 304.43
41.69 0.02 2.15 12.50 11.38
dm-0 0.00 0.00 1.55 0.74 333.57 190.40
228.56 0.09 37.15 2.90 0.67
sr0 0.00 0.00 0.00 0.00 0.00 0.00
11.69 0.00 51.08 49.54 0.00

You could always use sar -d but you have to make sure that
/etc/default/sysstat has the "enabled" option set to true. You can then
start and stop monitoring with "/etc/init.d/sysstat start". Sar -d will
give you the partition so I usually use it. I also usually stop
performance monitoring while doing low latency work. I have not tested
the overhead in a while but back when I had a PIII/AMD Thunderbird, it
did make a difference.

- From here I can see which block device (hard drive) is busy. So now I
am going to try and track down which process(es) are responsible.

If you use sar -d you have the major and minor number for the disk in
question, otherwise you need to find it:
ls -l /dev/sda*
brw-rw---- 1 root disk 8, 1 2008-10-07 17:48 /dev/sda1

lsof | grep "8,1" | awk '{print $1" "$2}' | uniq -c | sort -n -r
7 vmware-vm 15491
1 bash 8188
1 bash 8137

So in my case vmware has 7 files open, and is the likely candidate.

You can also look at htop and atop. htop is pretty good for looking
through your system and it can be resorted on the fly.

I would also get to know lsof, probably one of the least known and yet
most useful utilities ever made. Second only to screen IMO.

You can get more info on lsof here:
http://dmiessler.com/study/lsof/

I originally got that long lsof command line from a web site. I can't
remember which one, but a google for disk IO linux should find it (or
one like it).

Hth,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJcfZxwRXgH3rKGfMRAvsVAJ4uE07EYCtRb8Iv40/KHLgLbsWr8ACfa4cR
z3qAqjZ8HhFXSDRCTOxQwx4=
=RvMS
-----END PGP SIGNATURE-----
_______________________________________________
64studio-devel mailing list
64studio-devel@64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 01-17-2009, 02:27 PM
"Gabriel M. Beddingfield"
 
Default Daemons

On Fri, January 16, 2009 3:26 am, Susan Dridi wrote:
> I'm curious about some daemons that are running. Do I need the icecast
> server or the portmap daemon for anything? I noticed those two in the
> boot messages, not sure what other daemons are running or if I need them.
>
> I'm trying to figure out what is accessing my hard drive a couple of
> times a second. The blue light in the front of my computer is constantly
> flashing, even when I'm not doing anything and don't have any
> applications open.

Have you checked your logs? /var/log/syslog, 'dmesg', /var/log/auth, etc.

Ofen, when I see this happen it's because there's an error of some sort
that is spamming the logs. I've seen it a lot with CD-ROM drives when
there's a bad disk... or when KsCD is trying to access an audio disk (but
there's a data disk in the tray). I would see errors like "I/O read error
on /dev/hdc at sector 23456."

HTH,
Gabriel

--
G a b r i e l M B e d d i n g f i e l d

_______________________________________________
64studio-devel mailing list
64studio-devel@64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 05-04-2010, 09:40 AM
 
Default Daemons

I have several running daemons that write some data to files
What happens with these open files when INIT 6 command is issued?
Are these files that are used by daemons deleted? Or are they closed regularly and saved ?
And what happens, if the Linux box is shut down in a dirty way( out of electricity)?
Thanks
L.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BE0079D.4796.6039ABB@export.hope.cz">http://lists.debian.org/4BE0079D.4796.6039ABB@export.hope.cz
 
Old 05-04-2010, 11:06 AM
Anand Sivaram
 
Default Daemons

normally as a part during reboot/shutdown procedure, sigterm is sentto all processes. *This causes processes to terminate during which file descriptors are closed down flushing their cache. *This is written to disk during filesytem sync.
So these files are preserved. *But when the system goes down because of a power glitch, there are chances that you lose your data from last filesystem sync.

On Tue, May 4, 2010 at 15:10, <export@hope.cz> wrote:

I have several running daemons *that write some data to files

What happens with these open files when INIT 6 command *is issued?

Are these files that are used by daemons deleted? Or are they closed regularly and saved ?

And what happens, if the *Linux box is shut down in a dirty way( out of electricity)?

Thanks

L.





--

To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: http://lists.debian.org/4BE0079D.4796.6039ABB@export.hope.cz
 
Old 05-04-2010, 03:21 PM
Ron Johnson
 
Default Daemons

Since SIGTERM is catchable, your code should nicely clean itself up.

On 05/04/2010 06:06 AM, Anand Sivaram wrote:

normally as a part during reboot/shutdown procedure, sigterm is sent
to all processes. This causes processes to terminate during which file
descriptors are closed down flushing their cache. This is written to disk
during filesytem sync.
So these files are preserved. But when the system goes down because of a
power glitch, there are chances that you lose your data from last filesystem
sync.


On Tue, May 4, 2010 at 15:10,<export@hope.cz> wrote:


I have several running daemons that write some data to files
What happens with these open files when INIT 6 command is issued?
Are these files that are used by daemons deleted? Or are they closed
regularly and saved ?
And what happens, if the Linux box is shut down in a dirty way( out of
electricity)?
Thanks
L.


--
Dissent is patriotic, remember?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4BE03B6D.2010008@cox.net">http://lists.debian.org/4BE03B6D.2010008@cox.net
 
Old 05-04-2010, 03:24 PM
"Boyd Stephen Smith Jr."
 
Default Daemons

On Tuesday 04 May 2010 04:40:13 export@hope.cz wrote:
> I have several running daemons that write some data to files
> What happens with these open files when INIT 6 command is issued?

Depends on the daemon. Prior to a clean reboot, a process is sent the TERM
signal, which it may handle however it likes. Sometime later it is sent the
KILL signal, which cannot be caught normally, and terminates the process.

> Are these files that are used by daemons deleted? Or are they closed
> regularly and saved ?

When the kernel terminates the process, they are closed, but not normally.
There's no C-language close() call or even a kernel-level "close" syscall.

Any data in buffers above the file system layer are lost.

> And what happens, if the Linux box is shut down in
> a dirty way( out of electricity)? Thanks

In this case, no software can really do anything, although things do happen
for a few milliseconds. Any data in a buffer that doesn't have a battery is
lost. Writes to disk that are in process my even get incorrect data.

Depending on the file system(s) in use, recovery from this state should result
in something like the kernel terminating every process with a KILL signal at
some point *prior* to the power loss.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 

Thread Tools




All times are GMT. The time now is 09:38 PM.

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