hd led blinking
hd led blinking
Hello, I have noticed that when Slacko is on without any program running, the HD led blinks fast about every 5-6 seconds is it normal and what does it do?
Is your Slacko connected to the web?
When I'm connected to the web...
I believe my ISP is periodically, at frequent intervals, checking to see if I'm still here/connected.
That would cause some activity at my end I guess.
Where that activity takes place [RAM or internal HDD?] would depend on the kind of installation methinks.
My Slacko is set up to NOT periodically-auto-write-back-during-the-session [from RAM where things are running] to the slackosave on the internal HDD, so no HDD activity to be expected there.
If I clicked the "Save..." icon on the desktop, it would be reasonable to then see resulting activity on the HDD as the HDD was written to.
[I also have my Slacko set up to treat the slackosave on the internal HDD as though it's a slackosave on a Flash Drive, which is why there is a "Save.." icon on the desktop]
Is your Slacko installed to the internal HDD or what?
When I'm connected to the web...
I believe my ISP is periodically, at frequent intervals, checking to see if I'm still here/connected.
That would cause some activity at my end I guess.
Where that activity takes place [RAM or internal HDD?] would depend on the kind of installation methinks.
My Slacko is set up to NOT periodically-auto-write-back-during-the-session [from RAM where things are running] to the slackosave on the internal HDD, so no HDD activity to be expected there.
If I clicked the "Save..." icon on the desktop, it would be reasonable to then see resulting activity on the HDD as the HDD was written to.
[I also have my Slacko set up to treat the slackosave on the internal HDD as though it's a slackosave on a Flash Drive, which is why there is a "Save.." icon on the desktop]
Is your Slacko installed to the internal HDD or what?
Hi,
I boot from a multisession CD into RAM and use a mounted
flash stick where I store any data I want to save as I work.
I also have folders on my flash stick which are linked back
to the CD/RAM (e.g. wine, .wine and .mozilla)
I have also wondered why my LED HD light blinks when I
don't have any HD partitions mounted (and I don't use Swap).
Strangely, at the moment it is blinking at about six second
intervals. I had never counted the intervals before now.
The blink rate is constant, with or without any browser
loaded and with no apps loaded.
My regards
I boot from a multisession CD into RAM and use a mounted
flash stick where I store any data I want to save as I work.
I also have folders on my flash stick which are linked back
to the CD/RAM (e.g. wine, .wine and .mozilla)
I have also wondered why my LED HD light blinks when I
don't have any HD partitions mounted (and I don't use Swap).
Strangely, at the moment it is blinking at about six second
intervals. I had never counted the intervals before now.
The blink rate is constant, with or without any browser
loaded and with no apps loaded.
My regards
If that action of the hard drive led was happening in Windows, I would assume that the defrag utility was running in the background.
But with Puppy, what background actions does it have that would cause that action?
Could it just be a matter of the pmount or simular background function periodically looking for new devices such as a CD/DVD disk or a USB device that was plugged in?
In other words, a periodic update check for attached devices like checking to see if a USB device had been plugged in.
If one is concerned about the possibility of a hacking attempt via the net to access the drive, just click on the internet icon on the task bar and select "Disconnect from network" and see if the hard drive led stops flashing.
The last thing a Puppy user wants to think is that some process is accessing his hard drive data/ personal information without his knowledge!
But with Puppy, what background actions does it have that would cause that action?
Could it just be a matter of the pmount or simular background function periodically looking for new devices such as a CD/DVD disk or a USB device that was plugged in?
In other words, a periodic update check for attached devices like checking to see if a USB device had been plugged in.
If one is concerned about the possibility of a hacking attempt via the net to access the drive, just click on the internet icon on the task bar and select "Disconnect from network" and see if the hard drive led stops flashing.
The last thing a Puppy user wants to think is that some process is accessing his hard drive data/ personal information without his knowledge!
couple bash programs may help you here.
iotop (its python based) will let you know what program accessing your drive.
iostat will let you know what dev is being accessed.
lsof will let you know what files are currently in use by the system.
IOtop is not included with puppy, so you'll have to get it online.
IOstat and lsof may be included... will depend on what puppy you are running.
iotop (its python based) will let you know what program accessing your drive.
iostat will let you know what dev is being accessed.
lsof will let you know what files are currently in use by the system.
IOtop is not included with puppy, so you'll have to get it online.
IOstat and lsof may be included... will depend on what puppy you are running.
interisting... I thought I remember during beta stages that lsof was included in slacko. (I specifically asked about it since it would help debug problems when we are trying to help users with no linux experience)8-bit wrote:In Puppy Slacko 5.4.1, iostat is present. The other two utilities are not.
So I will have to do a web search for them.
But thank you for the suggestions.
Here they are. But as I mentioned.. iotop requires python to run. (its a python script)
- Attachments
-
- iotop-0.4.4.pet
- (36.1 KiB) Downloaded 750 times
-
- lsof-4.83.pet
- (51.51 KiB) Downloaded 710 times
The partition where the Puppy files are located is mounted read-write all of the time. If there is a filesystem driver managing the partition loaded (mostly built into the vmlinuz kernel directly) , it will always do some operations on the partition, especially if it is a journal 'ed filesystem ie ntfs, ext3 .
As far as I know the long red flash is the USA gov...the short flashing is the Israeli gov and the middle is the Arab gov along with the Chinese and Russians so no need to worry....it's just the "Watcher".Just the government spying on your computer, nothing to worry about
I had this as well to be honest....If you don't mind, then, they won't mind.
It's a browser thing.
Eric
PS...I run without a hdd so no matter to me...you see.
[color=darkred][i]Be not afraid to grow slowly, only be afraid of standing still.[/i]
Chinese Proverb[/color]
Chinese Proverb[/color]
In former times i have read , that the linux kernel created a virtual ramdisk of a fixed size,
that can be adjusted at kernel compile time,
( also the amount of automatically created ramdisks in /dev/ram* )
to load the initrd.gz into.
That's where the bootparameter root=/dev/ram0 derives from.
Puppy's older kernels up to 2.6.33.2 and above had a ramdisk size of 12-13KiB .
Very recent kernel configurations have that increased since such a ramdisk is used for full installations to perform the file system check,
since a full installation does not use an initrd.gz,
so loads all the needed programs and libraries into that ramdisk,
unmounts the partition and performs the filesystem check ending with a reboot,
but the sizes of the libraries have incresed already from 4.3 to Lupu
and now they wont fit anymore into the 12-13kib ramdisk .
I worked around it myself by using two ramdisks : one for /lib and one for all the other programs in /etc, /bin, /sbin .
You could test it like
bash-3.00# ls /dev/ram*
/dev/ram0 /dev/ram11 /dev/ram14 /dev/ram3 /dev/ram6 /dev/ram9
/dev/ram1 /dev/ram12 /dev/ram15 /dev/ram4 /dev/ram7
/dev/ram10 /dev/ram13 /dev/ram2 /dev/ram5 /dev/ram8
bash-3.00# disktype /dev/ram0
--- /dev/ram0
Block device, size 16 MiB (16777216 bytes)
Blank disk/medium
and of course create an ext2 filesystem like
The point is now, that the kernel nowerdays loads the initrd.gz directly into a temporary tmpfs filesystem, that has no fixed size,
so no "real physical ramdisk" is used anymore by default and the kernel manages this all in ram and discards the initrd.gz after it had finished switching root.
I believe that since the HDD LED in the front side of a computer case is attached to the mobo, the BIOS/CHIP/CPU is sending the impulses to that joint, not the HDD directly. Whatever the real cause is, it might be that the BIOS simply is programmed to expect a HDD and therfore sends signals, or the cable is wrongly attached/damaged .
that can be adjusted at kernel compile time,
( also the amount of automatically created ramdisks in /dev/ram* )
to load the initrd.gz into.
That's where the bootparameter root=/dev/ram0 derives from.
Puppy's older kernels up to 2.6.33.2 and above had a ramdisk size of 12-13KiB .
Very recent kernel configurations have that increased since such a ramdisk is used for full installations to perform the file system check,
since a full installation does not use an initrd.gz,
so loads all the needed programs and libraries into that ramdisk,
unmounts the partition and performs the filesystem check ending with a reboot,
but the sizes of the libraries have incresed already from 4.3 to Lupu
and now they wont fit anymore into the 12-13kib ramdisk .
I worked around it myself by using two ramdisks : one for /lib and one for all the other programs in /etc, /bin, /sbin .
You could test it like
bash-3.00# ls /dev/ram*
/dev/ram0 /dev/ram11 /dev/ram14 /dev/ram3 /dev/ram6 /dev/ram9
/dev/ram1 /dev/ram12 /dev/ram15 /dev/ram4 /dev/ram7
/dev/ram10 /dev/ram13 /dev/ram2 /dev/ram5 /dev/ram8
bash-3.00# disktype /dev/ram0
--- /dev/ram0
Block device, size 16 MiB (16777216 bytes)
Blank disk/medium
and of course create an ext2 filesystem like
Code: Select all
mkfs.ext2 /dev/ram0 && mkdir -p /mnt/ram0 && mount /dev/ram0 /mnt/ram0 && cd /mnt/ram0 && echo "HUHU, I am in $PWD : )"
The point is now, that the kernel nowerdays loads the initrd.gz directly into a temporary tmpfs filesystem, that has no fixed size,
so no "real physical ramdisk" is used anymore by default and the kernel manages this all in ram and discards the initrd.gz after it had finished switching root.
I believe that since the HDD LED in the front side of a computer case is attached to the mobo, the BIOS/CHIP/CPU is sending the impulses to that joint, not the HDD directly. Whatever the real cause is, it might be that the BIOS simply is programmed to expect a HDD and therfore sends signals, or the cable is wrongly attached/damaged .
-
- Posts: 9
- Joined: Tue 12 Apr 2011, 14:16
Sorry for the thread resurrection, but I'm having a similar issue, except my HD access is a lot more intense, about once per second. I can hear the heads move as something accesses data. I have a 2GB swap partition, but according to swapon -s it is currently mounted but not being used.
I'm running Slacko 5.5.
According to the package manager it is installed, but running iotop returns:Q5sys wrote: Here they are. But as I mentioned.. iotop requires python to run. (its a python script)
Code: Select all
bash: /bin/iotop: /usr/bin/python: bad interpreter: No such file or directory