Discuss

discuss@lists.centos.org

5 participants
34752 discussions

Re: [CentOS] Reboots
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > Also, run-levels are standarized, and should be the same on all unix-like > platforms. ??? Debian and Solaris run-levels differ from Red Hat. And some distros, like Solaris and SuSe, also have a "rcS.d" directory that runs in addition to, and before, the run-level. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Reboots
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Ken Godee <ken(a)perfect-image.com> > The "POST" routine can give you early warnings of pending > hardware failures that might go un-noticed until complete > failure otherwise. In such cases where that is a worry, I'm going to want to deploy real-time hardware management instead. It's worth the extra few bucks. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Reboots
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > That, my friend, is very much true. > Depending on the kind of server you are running (mumber of different > processes), a reboot will be much easier. Did that myself a few times. As far as examining running processes, one should have _good_ operational procedures and practices to track what is and isn't running on your system. If you can, stick with Sys-V start/kill init scripts for everything, and document anything that can't be (as well as why). I don't like to rely on reboots to do such things. In fact, when building a new, standard system configuration, I like to shunt to "init 1" and back to "init 3" (run-levels assume distro is Fedora-based) several times to ensure that all my start/kill init scripts are proper. That way I can stop and start user-space services piecemeal and completely. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 2

How many supported DNS IP addresses maybe configured in /etc/resolv.conf ?
by Prasad Pillarisetti 02 Jun '05

02 Jun '05

How many supported DNS IP addresses maybe configured in /etc/resolv.conf ? Is it only 3, or can I configure more?

3 2

RE: [CentOS] How many supported DNS IP addresses maybe configured in/etc/resolv.conf ?
by Marc Powell 02 Jun '05

02 Jun '05

> -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf Of Prasad Pillarisetti > Sent: Thursday, June 02, 2005 12:32 PM > To: centos(a)centos.org > Subject: [CentOS] How many supported DNS IP addresses maybe configured > in/etc/resolv.conf ? > > How many supported DNS IP addresses maybe configured in /etc/resolv.conf ? > > Is it only 3, or can I configure more? There is no limit that I am aware of to the number of 'nameserver' directives if that's what you're asking. They'll all be tried in sequence until a response is received. From the resolv.conf man page -- "The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made" IMHO, if 2 or 3 aren't sufficient then you should really consider the root cause why you need more and correct that ;) -- Marc

1 0

Re: Reboots -- Reboot Logic ...
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

The main reason I see this topic come up over and over is because people who are new to UNIX coming from Windows don't realize that they have been "programmed" into thinking what reboots are for. Prior to the proliferation of Windows, barring hardware failure, reboots were pretty limited to scheduled maintenance. Sure, user-space programs have memory leaks, new options are buggy, etc... And sometimes you have to stop, start, debug, etc... those services. But for the most part, the core, kernel in just about any UNIX system has not only been fairly devoid of major issues because of the inherit attitude of its developers. _Nothing_ goes into the kernel that is not required, and that means _not_ putting in services for performance or other hacks. So that means that memory leaks and other things that are very problematic in newer services or changes are typically left to only user-space services which can be fully pre-emptive. Even NT 3.1 put things into kernel space that should have never been in there. It got worse with NT 3.51 "Daytona" for "Chicago" (DOS7.0 aka "Windows 95") compatibility, and NT 4.0 "Cario" was the ultimate bastard prior until NT 5.1 (XP/2003). In the UNIX world, you can stop all sorts of user-spaces -- pretty much all of them if you wish -- which many admins do to resolve issues. Take down nmb/smb, take down ldapd, etc... to deal with issues. The system usually stays up and continues servicing many other capabilities -- because they are not part of the kernel space itself. This is very much unlike the NT world. The server, spooler and other services are tied into the kernel. Restarting them is typically impossible or ineffective when there is an issue, because the issue is in the kernel, and the user-space component restart doesn't help. Then there are the "Chicago" components that have been tacked on since NT 3.51, 4.0 and, probably most deadly, in NT 5.1 (XP/2003). These services and libraries -- designed for the "free for all" of "Chicago" (including MS IE) -- wreak havoc on the protected NT kernel's space. KEY POINT: This is why you should _never_ reboot UNIX/Linux in the hope that it solves the problem like it typically does Windows. In the Windows world, it typically fixes the issue -- even if temporary -- because even the user space components typically have kernel-space services for performance, etc... -- e.g., IIS, SMB, etc... Although Microsoft seems to be putting IIS and other things into the "Indigo .NET Sandbox" in NT6.0 Longhorn, the ADS, SMB and other non-.NET services are still going to be 100% Legacy Win32+Chicago code. So it's not getting any better anytime soon, and reboots will still be required to "clean things out." In the UNIX world, if you reboot, you are typically presented with _no_ resolution. You're best bet is to find the root cause and fix it, instead of wasting time rebooting. Plus, there is also the additional consideration of additional issues a UNIX reboot can introduce. E.g., UNIX/Linux systems are rebooted so infrequently that many boot-time configurations can change but not be known for months, or even years! So it's best to _only_ reboot UNIX/Linux when you have time for scheduled maintenance. So if there is one thing I highly deter new UNIX/Linux administrators from doing, it is doing an "impulsive reboot." It's better to just work the problem, then to reboot, waste time (in the best case) and possibly introduce even more, unforseen issues in changes (in the worst case). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Vote For CentOS :) -- entitlements are to subscriptions, not products ...
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Simon Perreault <nomis80(a)lqt.ca> > Isn't it acceptable for Red Hat to sell SLAs on a per-computer basis? > I really don't get where you're going. The main problem people have in understanding RHEL is that they don't understand it is a subscription with guarantees and, optionally, service level agreements (SLAs). It's _not_ a product at all. Red Hat has been wanting to get away from a "product" every since they came out with Red Hat Linux 6.2 "E" Service Level Agreements. E.g., you _never_ pay for an "upgrade," if you have an active entitlement, you are entitled to whatever product, current or past, that is still actively supported. You could even subscribe while RHEL 4 is current today and install RHEL 2.1 and be supported until it is retired (in another year or so). At the same time, you will get RHEL 5 if you have entitlements when it comes out. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Vote For CentOS :)
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > That's a rather different case. The MS software doesn't start with a > license that ensures your right to copy it except in the case where > you impose additional restrictions. You are asserting things the GPL does not guarantee. Rights to additional IP is one of them. You do not need the Red Hat trademarks for the software to function. So they can be legally bundled with GPL software. This is not a Red Hat-only issue. But it is one that Red Hat got into real trouble with for failing to enforce their trademarks prior with Cobalt, Sun, etc... -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

RE: [CentOS] Reboots
by Marc Powell 02 Jun '05

02 Jun '05

> -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf Of Prasad Pillarisetti > Sent: Thursday, June 02, 2005 11:42 AM > To: centos(a)centos.org > Subject: [CentOS] Reboots > > > ***Do you perform downtimes just for the purpose of rebooting the systems? It's a matter of policy. We do not but all of our customer facing systems are load balanced. If they weren't and the reboot wasn't of an emergency nature then yes, we would reboot during a maintenance window. > ***Is there a recommended interval Linux system should be rebooted? Ideally never. You should only need to reboot for hardware or kernel changes. We have internal machines that have been up for over 3 years without interruption (let the uptime contest begin). -- Marc

2 1

auditd logs
by Dave 02 Jun '05

02 Jun '05

I've noticed my disk space filling up rapidy on my mail server, I noticed that /var/log/audit.d is using 2.1 G. Is it safe to remove those log files?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss