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

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-05-2010, 09:22 PM
Merciadri Luca
 
Default Debian/kernel's policy for fatal errors, etc.

Hi,

When a computer stays turned on for a long amount of time, some problems
could arise. I have the following questions:

1. What habitually makes a computer 'running Linux) go down (except
electric problems)?
2. What are Debian/kernel's adaptations to prevent such problems from
arising?

Thanks.

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.
 
Old 07-06-2010, 05:28 AM
Bob Proulx
 
Default Debian/kernel's policy for fatal errors, etc.

Merciadri Luca wrote:
> When a computer stays turned on for a long amount of time, some problems
> could arise. I have the following questions:
>
> 1. What habitually makes a computer 'running Linux) go down (except
> electric problems)?

One possibility is soft memory errors in the RAM. Using ECC RAM
reduces the likely to a vanishingly small probability and has long
been the normal hardware for high quality systems. But cheaper
commodity hardware desktops designed to run a well known commercial OS
these days uses cheaper non-ECC RAM since it doesn't make sense to be
more reliable than the target OS. Linux tends to expose these systems
since it is very reliable in and of itself.

Another possibility is a kernel bug either in the main kernel core or
in a device driver. Device drivers have a higher incidence of bugs
especially for unique low use niche hardware. Popular devices are
better tested than hardware that only three people in the world use.
But kernel bugs in the public code are rare. When found those are
fixed pretty quickly.

A third more common case is when closed source proprietary drivers are
loaded into the kernel such as a vendor's graphics driver. Because
those are closed source there isn't any public review. Bugs there are
frustrating to all since they can't be debugged by anyone but the
vendor and the vendor doesn't usually have access to your system nor
motivation to debug your system. For high reliability you should
avoid loading any closed source proprietary driver, unless you
yourself are the author of it.

> 2. What are Debian/kernel's adaptations to prevent such problems from
> arising?

Debian adds few patches over and above the standard stock Linux
kernel. Basically in this area (as far as I know) you are getting the
stock upstream Linux kernel capability.

Bob
 
Old 07-06-2010, 05:38 AM
Merciadri Luca
 
Default Debian/kernel's policy for fatal errors, etc.

Bob Proulx wrote:
> Merciadri Luca wrote:
>
>> When a computer stays turned on for a long amount of time, some problems
>> could arise. I have the following questions:
>>
>> 1. What habitually makes a computer 'running Linux) go down (except
>> electric problems)?
>>
>
> One possibility is soft memory errors in the RAM. Using ECC RAM
> reduces the likely to a vanishingly small probability and has long
> been the normal hardware for high quality systems. But cheaper
> commodity hardware desktops designed to run a well known commercial OS
> these days uses cheaper non-ECC RAM since it doesn't make sense to be
> more reliable than the target OS. Linux tends to expose these systems
> since it is very reliable in and of itself.
>
Thanks.
> Another possibility is a kernel bug either in the main kernel core or
> in a device driver. Device drivers have a higher incidence of bugs
> especially for unique low use niche hardware. Popular devices are
> better tested than hardware that only three people in the world use.
> But kernel bugs in the public code are rare. When found those are
> fixed pretty quickly.
>
Okay.
> A third more common case is when closed source proprietary drivers are
> loaded into the kernel such as a vendor's graphics driver. Because
> those are closed source there isn't any public review. Bugs there are
> frustrating to all since they can't be debugged by anyone but the
> vendor and the vendor doesn't usually have access to your system nor
> motivation to debug your system. For high reliability you should
> avoid loading any closed source proprietary driver, unless you
> yourself are the author of it.
>
Sure.
>> 2. What are Debian/kernel's adaptations to prevent such problems from
>> arising?
>>
> Debian adds few patches over and above the standard stock Linux
> kernel. Basically in this area (as far as I know) you are getting the
> stock upstream Linux kernel capability.
>
Okay. Well, I'm using, on the computer which `should never fail,' Silcon
Labs' drivers for a Davis Vantage Pro 2 Wireless station (which is
connected to the computer by USB). I'm not sure if they are the CP210x
(because this is not really UART, at least to me), but they seem to be
pretty correctly integrated into the kernel. I should not worry like
this, but for a computer which needs to be turned on 24h/24, 7d/7, etc.,
it's an important thing because, for meteorological data capture, we
shall all depend on the computer's `good-will.'

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.


All flowers are not in one garden.
 
Old 07-06-2010, 05:48 AM
Bob Proulx
 
Default Debian/kernel's policy for fatal errors, etc.

Merciadri Luca wrote:
> pretty correctly integrated into the kernel. I should not worry like
> this, but for a computer which needs to be turned on 24h/24, 7d/7, etc.,
> it's an important thing because, for meteorological data capture, we
> shall all depend on the computer's `good-will.'

I have personally seen Linux based systems run for several years
without a reboot. Of course that isn't recommended since security
vulnerabilities are usually patched at least a few times a year and
security upgrades should be installed and rebooted to activate. But
just the same old "uptime wars" have been around for a while and
machines running for years without a reboot are not that unusual.

If uptime is critical, critical, critical then you would need to plan
for it and use more redundancy. But for most applications it is good
enough to plan scheduled reboots for installations of security
upgrades. It is all your choice.

Bob
 
Old 07-06-2010, 06:46 AM
Alan Chandler
 
Default Debian/kernel's policy for fatal errors, etc.

On 05/07/10 22:22, Merciadri Luca wrote:

Hi,

When a computer stays turned on for a long amount of time, some problems
could arise. I have the following questions:

1. What habitually makes a computer 'running Linux) go down (except
electric problems)?
2. What are Debian/kernel's adaptations to prevent such problems from
arising?

Thanks.




I have had a Debian based server at home running 24/7 for about 7 or 8
years. Living near London, we seem to have a reasonably stable
electricity supply (I don't do anything special) and I have had uptimes
of nearly a year, with the only downtime in the year being when my wife
made me turn it off as we went on holiday.


Of course upgrades to the kernel have required bringing it down, and
more recently I have had several updgrades of hardware to increase disk
space and increase performance with a faster processes so I could build
in mythtv.


From November 2009 to 10 days ago I went through a phase of using a
Sheeva plug computer as the server (in order to use less electricity),
but I am sad to say its (hardware) reliability wasn't good and I have
now abandoned that. Putting the old server back it has now been running
24/7 for the last 10 days.


It runs exim and apache and mythtv as the three key applications
supported by both mysql and postgres, but it is also a git server, dns
server (along with dhcp and tftp - using dnsmasq), time server,
firewall/router/internet gateway and automatically supports most of the
backups via cron (when it is master of the process) or via rsyncd (when
it is the slave). I have never seen a memory leak or anything else that
has required attention.



--
Alan Chandler
http://www.chandlerfamily.org.uk


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

Archive: 4C32D150.70601@chandlerfamily.org.uk">http://lists.debian.org/4C32D150.70601@chandlerfamily.org.uk
 
Old 07-06-2010, 08:21 PM
Merciadri Luca
 
Default Debian/kernel's policy for fatal errors, etc.

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

Alan Chandler <alan@chandlerfamily.org.uk> writes:

> I have had a Debian based server at home running 24/7 for about 7 or 8
> years. Living near London, we seem to have a reasonably stable
> electricity supply (I don't do anything special) and I have had
> uptimes of nearly a year, with the only downtime in the year being
> when my wife made me turn it off as we went on holiday.
I suppose you were sad that the asked you to turn it off.

> Of course upgrades to the kernel have required bringing it down, and
> more recently I have had several updgrades of hardware to increase
> disk space and increase performance with a faster processes so I could
> build in mythtv.
>
> From November 2009 to 10 days ago I went through a phase of using a
> Sheeva plug computer as the server (in order to use less electricity),
> but I am sad to say its (hardware) reliability wasn't good and I have
> now abandoned that. Putting the old server back it has now been
> running 24/7 for the last 10 days.
>
> It runs exim and apache and mythtv as the three key applications
> supported by both mysql and postgres, but it is also a git server, dns
> server (along with dhcp and tftp - using dnsmasq), time server,
> firewall/router/internet gateway and automatically supports most of
> the backups via cron (when it is master of the process) or via rsyncd
> (when it is the slave). I have never seen a memory leak or anything
> else that has required attention.

Thanks for this. (Thanks to Mr. Proulx too.)
- --
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- --

Failure is not falling down, you fail when you don't get back up.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAkwzkDkACgkQM0LLzLt8MhyCLQCfUi2YARZdTe gMhCzgliu+uanS
K6EAn3Zwl/1TTFn7PP5ZjLlC4ZKUAj9V
=6BtI
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqz0mkee.fsf@merciadriluca-station.MERCIADRILUCA">http://lists.debian.org/87pqz0mkee.fsf@merciadriluca-station.MERCIADRILUCA
 

Thread Tools




All times are GMT. The time now is 02:52 PM.

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