Joe Zeff writes:
> On 06/22/2013 06:49 PM, lee wrote:
>> Joe Zeff writes:
>>
>>> On 06/21/2013 09:19 PM, lee wrote:
And how would I disable it? Mdmonitor is stopped and disabled, and md
is still running.
>>>
>>> systemctl stop SERVICENAME.service
>>> systemctl mask SERVICENAME.service
Am 23.06.2013 04:45, schrieb Joe Zeff:
> On 06/22/2013 06:49 PM, lee wrote:
>> Joe Zeff writes:
>>
>>> On 06/21/2013 09:19 PM, lee wrote:
And how would I disable it? Mdmonitor is stopped and disabled, and md
is still running.
>>>
>>> systemctl stop SERVICENAME.service
>>> systemctl ma
On 23.06.2013 04:45, Joe Zeff wrote:
> On 06/22/2013 06:49 PM, lee wrote:
>> Joe Zeff writes:
>>
>>> On 06/21/2013 09:19 PM, lee wrote:
And how would I disable it? Mdmonitor is stopped and disabled, and md
is still running.
>>>
>>> systemctl stop SERVICENAME.service
>>> systemctl mask S
On 06/22/2013 06:49 PM, lee wrote:
Joe Zeff writes:
On 06/21/2013 09:19 PM, lee wrote:
And how would I disable it? Mdmonitor is stopped and disabled, and md
is still running.
systemctl stop SERVICENAME.service
systemctl mask SERVICENAME.service
Thank you, that would work if there was a s
Joe Zeff writes:
> On 06/21/2013 09:19 PM, lee wrote:
>> And how would I disable it? Mdmonitor is stopped and disabled, and md
>> is still running.
>
> systemctl stop SERVICENAME.service
> systemctl mask SERVICENAME.service
Thank you, that would work if there was a service called "md", but ther
On 06/21/2013 09:19 PM, lee wrote:
And how would I disable it? Mdmonitor is stopped and disabled, and md
is still running.
systemctl stop SERVICENAME.service
systemctl mask SERVICENAME.service
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
ht
Reindl Harald writes:
> Am 18.06.2013 04:41, schrieb lee:
>> Joe Zeff 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
>> any
Reindl Harald writes:
> Am 21.06.2013 08:39, schrieb lee:
>> Reindl Harald 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 eviden
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...
--
[tim@localh
Reindl Harald 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
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.
Joe Zeff writes:
> On 06/17/2013 07:21 PM, lee wrote:
>> Joe Zeff 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
Am 18.06.2013 04:41, schrieb lee:
> Joe Zeff 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 t
On 06/18/2013 12:41 AM, Joe Zeff wrote:
On 06/17/2013 07:21 PM, lee wrote:
Joe Zeff 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, t
On 06/17/2013 07:41 PM, lee wrote:
Joe Zeff 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
On 06/17/2013 07:21 PM, lee wrote:
Joe Zeff 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 log
Joe Zeff 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
Joe Zeff 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 reas
;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 someth
an 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 professio
edicate (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 real
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
Am 17.06.2013 02:25, schrieb lee:
> Joe Zeff 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
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 p
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.
--
users mai
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 fo
"T.C. Hollingsworth" writes:
> On Sun, Jun 16, 2013 at 5: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?
>
> In this situation I'd be much more concerned about al
ifferent 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
On Sun, Jun 16, 2013 at 5: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?
In this situation I'd be much more concerned about all the data I lost
since my last backup
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
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 assumpt
Joe Zeff 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
> har
Reindl Harald writes:
> Am 17.06.2013 02:25, schrieb lee:
>> Joe Zeff 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 prob
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 yo
Joe Zeff 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
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,
Joe Zeff 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 s
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 h
Frank Murphy writes:
> On Sat, 15 Jun 2013 11:55:53 +0200
> lee 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 on
On Sat, 15 Jun 2013 11:55:53 +0200
lee 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
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 ther
41 matches
Mail list logo
