Hi,
is the mcelog.service of any use to me?
There's a package mcelog-1.0-0.6.6e4e2a00.fc18.x86_64 installed and listed as a leave by package-cleanup, the service is running; /var/log/mce doesn't exist (which is probably good).
In which way would it help me to log such errors if there were any?
On Sat, 15 Jun 2013 11:55:53 +0200 lee lee@yun.yagibdah.de wrote:
Hi,
is the mcelog.service of any use to me?
Yes, if you want to know about potential hardware problems cpu
the service is running;
/var/log/mce doesn't exist (which is probably good).
It doesn't use it's own log by default, but you can grep from /var/log/messages.
In which way would it help me to log such errors if there were any?
cat /var/log/messages | grep mce
You can try set up it own log /var/log/mcelog but selinux will barf.
Frank Murphy frankly3d@gmail.com writes:
On Sat, 15 Jun 2013 11:55:53 +0200 lee lee@yun.yagibdah.de wrote:
Hi,
is the mcelog.service of any use to me?
Yes, if you want to know about potential hardware problems cpu
Wouldn't it make much more sense to run this service only when there are problems to find out if it reports some?
the service is running;
/var/log/mce doesn't exist (which is probably good).
It doesn't use it's own log by default, but you can grep from /var/log/messages.
Well, I usually don't do that, so what's the point in running this service all the time?
On 06/15/2013 12:21 PM, lee wrote:
Well, I usually don't do that, so what's the point in running this service all the time?
Once your hardware's going bad it may be too late to start it, and having it always running may help you learn (if it matters) when things started going bad. (You may have thought you had a software issue, and finding that it's hardware can keep you from trying to track down a non-problem.) Even if your system isn't bootable any more, you may be able to extract forensics from your hard drive that can help you pinpoint what's happened. Think of it as the equivalent of having security cameras in a store; most of the time, there's nothing important in the tapes, but you keep them running anyway.
Joe Zeff joe@zeff.us writes:
On 06/15/2013 12:21 PM, lee wrote:
Well, I usually don't do that, so what's the point in running this service all the time?
Once your hardware's going bad it may be too late to start it, and having it always running may help you learn (if it matters) when things started going bad. (You may have thought you had a software issue, and finding that it's hardware can keep you from trying to track down a non-problem.) Even if your system isn't bootable any more, you may be able to extract forensics from your hard drive that can help you pinpoint what's happened. Think of it as the equivalent of having security cameras in a store; most of the time, there's nothing important in the tapes, but you keep them running anyway.
When the hardware has gone so bad that I can't start mcelog anymore, I very likely can't retrieve information from the logfiles, either, without fixing the problem first. It's very likely that I will notice a condition like this without running mcelog. I'm not sure in which way it would help me to be able to find out /when/ the hardware started going bad because when it is failing, it needs to be fixed anyway.
In case there's a weird problem that makes me wonder if it's software or hardware, I can still let mcelog run to see if something shows up.
Security cameras are an additional resource --- like another computer on the network dedicated to the monitoring --- which I don't have. If constantly recording security cameras were decreasing your sales and had very questionable benefit, you might ask yourself if it's worthwhile to keep them running all the time and whether it's better to install a button you can press to only start the recording when the store is actually being robbed :)
Such cameras might scare off potential robbers, no matter whether they are recording or not unless the robbers know what the cameras are doing, whereas running mcelog doesn't scare the hardware off from going bad, no matter whether it's recording or not ...
On 06/15/2013 08:40 PM, lee wrote:
When the hardware has gone so bad that I can't start mcelog anymore, I very likely can't retrieve information from the logfiles, either, without fixing the problem first.
As long as it's not the drive itself that went bad you can always connect it to another, working computer.
Joe Zeff joe@zeff.us writes:
On 06/15/2013 08:40 PM, lee wrote:
When the hardware has gone so bad that I can't start mcelog anymore, I very likely can't retrieve information from the logfiles, either, without fixing the problem first.
As long as it's not the drive itself that went bad you can always connect it to another, working computer.
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
Am 17.06.2013 02:25, schrieb lee:
Joe Zeff joe@zeff.us writes:
On 06/15/2013 08:40 PM, lee wrote:
When the hardware has gone so bad that I can't start mcelog anymore, I very likely can't retrieve information from the logfiles, either, without fixing the problem first.
As long as it's not the drive itself that went bad you can always connect it to another, working computer.
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
well, most people on Linux are using mdraid to avoid the useless question about "compatible hardware RAID controller" because it is pretty useless to have a RAID with a single-point-of-failure in form the controller
Reindl Harald h.reindl@thelounge.net writes:
Am 17.06.2013 02:25, schrieb lee:
Joe Zeff joe@zeff.us writes:
On 06/15/2013 08:40 PM, lee wrote:
When the hardware has gone so bad that I can't start mcelog anymore, I very likely can't retrieve information from the logfiles, either, without fixing the problem first.
As long as it's not the drive itself that went bad you can always connect it to another, working computer.
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
well, most people on Linux are using mdraid to avoid the useless question about "compatible hardware RAID controller" because it is pretty useless to have a RAID with a single-point-of-failure in form the controller
How do these people answer questions like how to connect 10+ SATA and/or SAS devices to their computers at the same time, how not to create a bottleneck with software raid and how to eliminate every possible single point of failure?
Are you assuming that most ppl using Linux have fallback systems with independent internet connections and emergency power generators standing by that automatically take over seamlessly when something with their used system or around it fails?
Am 17.06.2013 03:44, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
well, most people on Linux are using mdraid to avoid the useless question about "compatible hardware RAID controller" because it is pretty useless to have a RAID with a single-point-of-failure in form the controller
How do these people answer questions like how to connect 10+ SATA and/or SAS devices to their computers at the same time, how not to create a bottleneck with software raid and how to eliminate every possible single point of failure?
why should these people do this with local disks?
such things are done with SAN-storages with typically *two* conrollers for failover, if you rely on *one* single controller and nothing else can read your RAID you should hire someone with knowledge
but what the hell has this to do with mcelog.service since nobody but you is using 10 SAS disks local attached
hint: in such setups *you get* replacement controllers and disks by SLA's with the manufacturer within hours
*you said* how can a different machine read my RAID well, normally this question should be answered *before* put any data on it
Are you assuming that most ppl using Linux have fallback systems with independent internet connections and emergency power generators standing by that automatically take over seamlessly when something with their used system or around it fails?
pff you do not need independent internet connections and power generators to plug software-raids to whatever computer because you can plug them with any SATA-to-USB and mdraid will recognize the array based on UUID's
Reindl Harald h.reindl@thelounge.net writes:
Am 17.06.2013 03:44, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
well, most people on Linux are using mdraid to avoid the useless question about "compatible hardware RAID controller" because it is pretty useless to have a RAID with a single-point-of-failure in form the controller
How do these people answer questions like how to connect 10+ SATA and/or SAS devices to their computers at the same time, how not to create a bottleneck with software raid and how to eliminate every possible single point of failure?
why should these people do this with local disks?
Maybe because they want to find to a balance between cost and usefulness that they are happy with.
such things are done with SAN-storages with typically *two* conrollers for failover, if you rely on *one* single controller and nothing else can read your RAID you should hire someone with knowledge
Yay, sure, I'll send you the bills.
but what the hell has this to do with mcelog.service
It seems to be part of an attempt, directed by invalid assumptions, to explain how running mcelog all the time might be useful.
since nobody but you is using 10 SAS disks local attached
Why would you assume that I do this?
hint: in such setups *you get* replacement controllers and disks by SLA's with the manufacturer within hours
Ok, and I send you the bills.
*you said* how can a different machine read my RAID well, normally this question should be answered *before* put any data on it
Someone assumed that reading what mcelog might put into a log file was easily possible even when the hardware is too broken to allow this. I merely questioned this assumption.
Are you assuming that most ppl using Linux have fallback systems with independent internet connections and emergency power generators standing by that automatically take over seamlessly when something with their used system or around it fails?
pff you do not need independent internet connections and power generators to plug software-raids to whatever computer because you can plug them with any SATA-to-USB and mdraid will recognize the array based on UUID's
You're missing the point which was someones assumption that a particular component must be useless because it can be spf. I was merely asking if there's also the assumption that ppl go to all the considerable lengths required to avoid spfs (so that the components they are using aren't useless).
Don't try to hold me responsible for other ppls logic, flawed or not.
Am 17.06.2013 04:29, schrieb lee:
You're missing the point which was someones assumption that a particular component must be useless because it can be spf. I was merely asking if there's also the assumption that ppl go to all the considerable lengths required to avoid spfs (so that the components they are using aren't useless).
Don't try to hold me responsible for other ppls logic, flawed or not
it was *your* argumentation that *you* can not pull your disks in a different machine because there is only one controller on earth which can read your disks - this is usually *not* true for others because they have spare controllers or not using hardware RAID and if *you* do not need mcelog.service disable it and stop your uselles discussion why *you* can not read logfiles if your system does not boot, others can
hence in professional environment you even use the --syslog option and have logs on different machines where you can read them even if the machine including disks and controller is dead
Reindl Harald h.reindl@thelounge.net writes:
Am 17.06.2013 04:29, schrieb lee:
You're missing the point which was someones assumption that a particular component must be useless because it can be spf. I was merely asking if there's also the assumption that ppl go to all the considerable lengths required to avoid spfs (so that the components they are using aren't useless).
Don't try to hold me responsible for other ppls logic, flawed or not
it was *your* argumentation that *you* can not pull your disks in a different machine because there is only one controller on earth which can read your disks
I haven't said that anywhere.
- this is usually *not* true for others because they have spare
controllers or not using hardware RAID and if *you* do not need mcelog.service disable it and stop your uselles discussion why *you* can not read logfiles if your system does not boot, others can
Why don't you just stop claiming I said things I didn't say? Are you doing this so you have something to get upset about?
hence in professional environment you even use the --syslog option and have logs on different machines where you can read them even if the machine including disks and controller is dead
You can always do that if you have several computers at hand to direct log outputs to. What's your argument here? That I should get some more computers so that I can always read what mcelog might have to say? I'd have to disappoint you because I don't plan on running some kind of server farm just for that.
On 06/16/2013 06:44 PM, lee wrote:
Are you assuming that most ppl using Linux have fallback systems with independent internet connections and emergency power generators standing by that automatically take over seamlessly when something with their used system or around it fails?
I can't speak for anybody else. However, I have both a desktop and a laptop, both using Fedora. My sister has her own computers, although they use Ubuntu. If my desktop were in doornail mode[1] and there were files that I needed on my hard drive that I needed right now, I'm sure that (with the help of a friend of mine who does my hardware work) I could get the drive hooked up to another computer long enough to get the files.
You may not have a spare computer. However, you probably have at least one friend who could help, even if you had to use a Live CD because your friend only uses Windows. As long as the drive itself is working, there's a way to recover the data, although there may well not be an easy or fast way.
[1]as in "dead as a..."
Joe Zeff joe@zeff.us writes:
As long as the drive itself is working, there's a way to recover the data, although there may well not be an easy or fast way.
Imagine the power supply would fail so that I can't read logfiles anymore.
What do I do? Fix the hardware right away or waste a week or two trying to find a way to read logfiles because mcelog /might/ have logged something?
Am 18.06.2013 04:41, schrieb lee:
Joe Zeff joe@zeff.us writes:
As long as the drive itself is working, there's a way to recover the data, although there may well not be an easy or fast way.
Imagine the power supply would fail so that I can't read logfiles anymore.
What do I do? Fix the hardware right away or waste a week or two trying to find a way to read logfiles because mcelog /might/ have logged something?
imagine that there may be errors which are not so clear than a broken power supply - what you are doing in this thread is only trolling
Reindl Harald h.reindl@thelounge.net writes:
Am 18.06.2013 04:41, schrieb lee:
Joe Zeff joe@zeff.us writes:
As long as the drive itself is working, there's a way to recover the data, although there may well not be an easy or fast way.
Imagine the power supply would fail so that I can't read logfiles anymore.
What do I do? Fix the hardware right away or waste a week or two trying to find a way to read logfiles because mcelog /might/ have logged something?
imagine that there may be errors which are not so clear than a broken power supply
It is always possible that it's not easy to find out what's broken, and not even a broken PSU is necessarily easy to diagnose.
- what you are doing in this thread is only trolling
Ah yes, every time someone has good reasons for an opinion they have and is examining the opinions of others based on that, it is confused with trolling.
On 06/17/2013 07:41 PM, lee wrote:
Joe Zeff joe@zeff.us writes:
As long as the drive itself is working, there's a way to recover the data, although there may well not be an easy or fast way.
Imagine the power supply would fail so that I can't read logfiles anymore.
What do I do? Fix the hardware right away or waste a week or two trying to find a way to read logfiles because mcelog /might/ have logged something?
Nothing more than a strawman. If the power supply's failed completely, you don't need the logs; if it's slowly going bad, the logs might help you diagnose the issue and replace the supply before it's completely gone. And, if the computer's dead, the power supply isn't the only possibility and there are times that it's better (and cheaper) to spend a little time grovelling over the logs instead of swapping parts until it works again.
On 06/16/2013 05:25 PM, lee wrote:
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
Are you saying that you have the only computer in the world with that hardware? If so, you have only yourself to blame; if not, you're only looking for excuses.
Joe Zeff joe@zeff.us writes:
On 06/16/2013 05:25 PM, lee wrote:
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
Are you saying that you have the only computer in the world with that hardware? If so, you have only yourself to blame; if not, you're only looking for excuses.
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running.
Let me give you a hint: Imagine you were travelling in an airplane and the plane crashed, leaving you stranded in a flat desert with only a small bottle of water and nothing but sand around for 500 miles in all directions. You can blame yourself for not bringing more water, and it is pretty irrelevant that the water in your bottle may not be the only water that exists in the world. If you were to say that the amount of water you can carry on an airplane is limited, I could always tell you that you're looking for excuses. And if you had brought an altimeter, would that help you now in any way?
Am 17.06.2013 04:09, schrieb lee:
Joe Zeff joe@zeff.us writes:
On 06/16/2013 05:25 PM, lee wrote:
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
Are you saying that you have the only computer in the world with that hardware? If so, you have only yourself to blame; if not, you're only looking for excuses.
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running
*you* started this thread with "is the mcelog.service of any use to me?"
people explained you why it *could* be useable why do you ask if you are knowing it better? so disable it and stop trolling
is it really that hard?
P.S.: and do not forget to disable a couple of other services which are not hardly needed and enabled by default
Reindl Harald h.reindl@thelounge.net writes:
Am 17.06.2013 04:09, schrieb lee:
Joe Zeff joe@zeff.us writes:
On 06/16/2013 05:25 PM, lee wrote:
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
Are you saying that you have the only computer in the world with that hardware? If so, you have only yourself to blame; if not, you're only looking for excuses.
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running
*you* started this thread with "is the mcelog.service of any use to me?"
people explained you why it *could* be useable
No, they explained what it is supposed to do and made invalid assumptions. Their point seems to be that it could be useful for instances when the logged output of mcelog helps you to figure out what might be wrong with your hardware. I agree with that, yet my points that I'm better off fixing the hardware right away rather than going to the lengths that I'd have to go to to figure out what the logged output is in case the hardware is too badly broken to obtain the logged output and that, in case the hardware isn't broken that badly, I might still be able to run mcelog to get useful output, remain.
why do you ask if you are knowing it better? so disable it and stop trolling
If I did, I wouldn't have asked. Where's your argument here? Are you trying to say that when I'm left with badly broken hardware, I'd be better off going to lengths to retrieve logfiles --- which might tell me nothing --- rather than fixing the hardware right away so there would be a reason to keep mcelog running? If so, why or how would that be?
is it really that hard?
I don't know what your problem is.
P.S.: and do not forget to disable a couple of other services which are not hardly needed and enabled by default
I've done that with a few. Do you have any in particular in mind? I probably didn't find all the things I might not need.
On 06/16/2013 07:52 PM, lee wrote:
No, they explained what it is supposed to do and made invalid assumptions. Their point seems to be that it could be useful for instances when the logged output of mcelog helps you to figure out what might be wrong with your hardware.
Have you considered the possibility that there can be intermittent errors that might or might not be hardware related and that having the data from mcelog available could help you decide if it is or isn't your hardware *before* there's a catastrophic failure?
Joe Zeff joe@zeff.us writes:
On 06/16/2013 07:52 PM, lee wrote:
No, they explained what it is supposed to do and made invalid assumptions. Their point seems to be that it could be useful for instances when the logged output of mcelog helps you to figure out what might be wrong with your hardware.
Have you considered the possibility that there can be intermittent errors that might or might not be hardware related and that having the data from mcelog available could help you decide if it is or isn't your hardware *before* there's a catastrophic failure?
Yes, it would require me to constantly check some logfile. Which logfile that is, is not even documented. It might be /var/log/syslog when you look at the mcelog.service file. Lots of things are being logged there, and I usually don't look at that unless something isn't working. I could make something that greps the logfile for something mcelog might be logging, but what would I look for? And if this is so critically important, why is it set up in such a way that this vital information is never seen?
On 06/16/2013 07:09 PM, lee wrote:
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running.
I take it, then, that you've either never heard of logrotate or have some reason not to use it.
Joe Zeff joe@zeff.us writes:
On 06/16/2013 07:09 PM, lee wrote:
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running.
I take it, then, that you've either never heard of logrotate or have some reason not to use it.
What would be the relevance of logrotate here?
On 06/17/2013 07:21 PM, lee wrote:
Joe Zeff joe@zeff.us writes:
On 06/16/2013 07:09 PM, lee wrote:
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running.
I take it, then, that you've either never heard of logrotate or have some reason not to use it.
What would be the relevance of logrotate here?
You do know what it does, don't you? Just to be sure, it keeps your system from being buried under a mass of old logfiles by rotating them from current to compressed archive to gone. That means that when your hardware is working fine, all of the old data from mcelog goes away, but there's enough kept for you to search it for signs of trouble if you think you need to. (On a side note, waiting until you think your hardware's getting flaky before starting it isn't always a good idea, because unless you're lucky you probably won't have time to collect and examine the data before it's too late.)
I must admit, however, that I've begun to wonder why I'm bothering because you've clearly made up your mind that you don't need mcelog running and have no intention of admitting that there might be reasons to have it active. If so, do as you wish and stop bothering the rest of us. Or, if I'm wrong, stop rejecting everything everybody says without even bothering to examine it, as you've been doing ever since you started this thread.
On 06/18/2013 12:41 AM, Joe Zeff wrote:
On 06/17/2013 07:21 PM, lee wrote:
Joe Zeff joe@zeff.us writes:
On 06/16/2013 07:09 PM, lee wrote:
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running.
I take it, then, that you've either never heard of logrotate or have some reason not to use it.
What would be the relevance of logrotate here?
You do know what it does, don't you? Just to be sure, it keeps your system from being buried under a mass of old logfiles by rotating them from current to compressed archive to gone. That means that when your hardware is working fine, all of the old data from mcelog goes away, but there's enough kept for you to search it for signs of trouble if you think you need to. (On a side note, waiting until you think your hardware's getting flaky before starting it isn't always a good idea, because unless you're lucky you probably won't have time to collect and examine the data before it's too late.)
I must admit, however, that I've begun to wonder why I'm bothering because you've clearly made up your mind that you don't need mcelog running and have no intention of admitting that there might be reasons to have it active. If so, do as you wish and stop bothering the rest of us. Or, if I'm wrong, stop rejecting everything everybody says without even bothering to examine it, as you've been doing ever since you started this thread.
WOW!.......LoL!
EGO II
Joe Zeff joe@zeff.us writes:
On 06/17/2013 07:21 PM, lee wrote:
Joe Zeff joe@zeff.us writes:
On 06/16/2013 07:09 PM, lee wrote:
Just think it through and then explain to me how it would make sense to dedicate (a part of the limited) resources to have mcelog constantly running.
[...] (On a side note, waiting until you think your hardware's getting flaky before starting it isn't always a good idea, because unless you're lucky you probably won't have time to collect and examine the data before it's too late.)
That might very well be, so what do you suggest I should grep the logfile for to send myself a warning once mcelog logs something?
I must admit, however, that I've begun to wonder why I'm bothering because you've clearly made up your mind that you don't need mcelog running and have no intention of admitting that there might be reasons to have it active. If so, do as you wish and stop bothering the rest of us. Or, if I'm wrong, stop rejecting everything everybody says without even bothering to examine it, as you've been doing ever since you started this thread.
I haven't been rejecting anything without examining it and haven't made up my mind yet. I've merely been saying that I don't see much point in dedicating resources to log warnings which I wouldn't see until it's too late. With more and more stuff running in the background, it becomes increasingly difficult to figure out what might actually be required, useful or nice to have and not needed at all --- if you even can find out what something does to begin with.
Look at pulseaudio, for example. It can be useful *if* you actually have use for features it provides --- which I don't. As it's now, it just wastes some CPU time without any benefit, and I'd rather get rid of it. I can't even get sound when I'm not logged in on the console, and when I'm logged in as a different user, that user can't get any sound, either. I don't know if pulseaudio causes these issues or if it's some security policy Fedora has. In any case, it makes things more insecure because it forces me to run applications that need sound on my main account which I otherwise could run as a different user.
It's like installing all available packages just because they exist. I don't do that, and I don't want to have all kinds of things running I don't need. Why is md running? I'm not using software raid. Why is irqbalance running? Does it really do anything useful? What about rtkit-daemon? That sounds like something watching out for rootkits, but what does it actually do, and will it warn me? Why is goa-daemon running? I'm very likely not using whatever they call "online accounts". How do I disable that? The list goes on ... At some point, the system will be occupied with itself only because there's too much stuff running in the background I don't need.
mcelog is merely one of these questionable things, and I don't want to just turn it off when it might be actually useful.
Am 19.06.2013 17:01, schrieb lee:
Look at pulseaudio, for example. It can be useful *if* you actually have use for features it provides --- which I don't
most do
It's like installing all available packages just because they exist.
no
Why is md running? I'm not using software raid.
well, the system can not smell this you may have a softare-raid not involved at boot
Why is irqbalance running? Does it really do anything useful?
irqbalance is a daemon that evenly distributes IRQ load across multiple CPUs for enhanced performance.
What about rtkit-daemon? That sounds like something watching out for rootkits what does it actually do, and will it warn me?
*lol*
yum info rtkit Name : rtkit Arch : x86_64 Version : 0.11 Release : 3.fc18 Size : 130 k Repo : installed Summary : Realtime Policy and Watchdog Daemon URL : http://git.0pointer.de/?p=rtkit.git License : GPLv3+ and BSD Description : RealtimeKit is a D-Bus system service that changes the : scheduling policy of user processes/threads to SCHED_RR (i.e. realtime : scheduling mode) on request. It is intended to be used as a secure : mechanism to allow real-time scheduling to be used by normal user
Reindl Harald h.reindl@thelounge.net writes:
Am 19.06.2013 17:01, schrieb lee:
Look at pulseaudio, for example. It can be useful *if* you actually have use for features it provides --- which I don't
most do
Do you have any evidence for that?
It's like installing all available packages just because they exist.
no
sure is
Why is md running? I'm not using software raid.
well, the system can not smell this you may have a softare-raid not involved at boot
I don't have a software raid. Why is it kept running?
Why is irqbalance running? Does it really do anything useful?
irqbalance is a daemon that evenly distributes IRQ load across multiple CPUs for enhanced performance.
That's what it claims, but does it really?
What about rtkit-daemon? That sounds like something watching out for rootkits what does it actually do, and will it warn me?
*lol*
yum info rtkit Name : rtkit Arch : x86_64 Version : 0.11 Release : 3.fc18 Size : 130 k Repo : installed Summary : Realtime Policy and Watchdog Daemon URL : http://git.0pointer.de/?p=rtkit.git License : GPLv3+ and BSD Description : RealtimeKit is a D-Bus system service that changes the : scheduling policy of user processes/threads to SCHED_RR (i.e. realtime : scheduling mode) on request. It is intended to be used as a secure : mechanism to allow real-time scheduling to be used by normal user
And now you're going to claim that most users use it ...
Reindl Harald:
irqbalance is a daemon that evenly distributes IRQ load across multiple CPUs for enhanced performance.
lee:
That's what it claims, but does it really?
Okay, if you really want to know, it's a subversive program by the TLA to infiltrate computers in Iraq...
On Sun, Jun 16, 2013 at 5:25 PM, lee lee@yun.yagibdah.de wrote:
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
In this situation I'd be much more concerned about all the data I lost since my last backup and I would be extremely annoyed that several perfectly good drives are now paperweights. I wouldn't much care what exactly caused the machine to fail. ;-)
But really, this is an edge case. Most people have some means of plugging their disks into another machine for forensic purposes, so this is useful to many.
-T.C.
"T.C. Hollingsworth" tchollingsworth@gmail.com writes:
On Sun, Jun 16, 2013 at 5:25 PM, lee lee@yun.yagibdah.de wrote:
Where would I find a working computer which I could use and which has the same or at least a compatible hardware RAID controller to connect the drives to?
In this situation I'd be much more concerned about all the data I lost since my last backup and I would be extremely annoyed that several perfectly good drives are now paperweights. I wouldn't much care what exactly caused the machine to fail. ;-)
But really, this is an edge case. Most people have some means of plugging their disks into another machine for forensic purposes, so this is useful to many.
That's assuming that the controller fails? In that case, I'd have to replace it, just like any other piece of broken hardware. It's always annoying when you have to do that.
How would running mcelog help me in this case?
-
EGO-II.1 -
Frank Murphy -
Joe Zeff -
lee -
Reindl Harald -
T.C. Hollingsworth -
Tim