Bad function number.

[Jose Lerebours]

On 09/23/2016 04:48 PM, Brian K. White via Filepro-list wrote:
> On 9/22/2016 6:45 PM, Jose Lerebours via Filepro-list wrote:
>> On 09/22/2016 06:40 PM, Fairlight via Filepro-list wrote:
>>> "My system has been kicking out errors. And today it's not behaving
>>> correctly."
>>>
>>> "When did the errors start?"
>>>
>>> "It goes back as far as the logs do."
>>>
>>> "What happened in the day before the first error appeared?"
>>>
>>> "There are no days before the errors.  Jose told me I didn't need the
>>> logs."
>>>
>>> "Sorry, but I can't tell you why your system is misbehaving. The
>>> critical
>>> data has been deleted.  Maybe Jose will look at your system for you."
>> I already conceded to this, no need to fuss about it ... but, there is
>> the ability to archive/save them.
>>
>> Some flavors of Linux do this automatically.
>
> ---
> No, they don't.
>
> This is just another perfect example of the sloppiness they are 
> talking about, and why it matters.
>
> Barring cases so special that they don't count, like a live ram distro 
> that loses everything when the ram loses power, they *rotate* logs, 
> not purge them. There is *always* some large amount of the most recent 
> logs. Never simply all erased.
>
> You just said something 100% false, and tried to use that 100% false 
> idea as the basis for a technical decision. The fact is wrong, and so 
> any decisions or actions based on it are at best unknown. Maybe ok, 
> maybe disaster, might as well have thrown a dart at a random list of 
> possible actions.
>
> ---
> No one really cares if you copy "Repko" correctly. A baby isn't going 
> to die somewhere because of it and it doesn't make you a Trump voter 
> ;) . It just served as yet another exhibition of your overall tendency 
> to care or lack of it, while you were in the very act of trying to 
> defend the quality of your advice against an accusation that your 
> approach wasn't very careful or methodical.
>
> ---
> This thing about deleting the logs on one windows server is not really 
> the end of the world either by itself. The point is this: If you are 
> actually unsure if the log entries are really in chronological order, 
> or if there might be current log entries scattered down in the middle 
> mass of the list where you can't find them, such that you think it's a 
> good idea to just to clear everything, "just to be sure", that is 
> automatic damning evidence that you have such a poor understanding of 
> how things work that you are by definition not a good source of advice 
> on this and related topics.
>
> That's harsh, but isn't namecalling. No one else makes you say the 
> haphazard ideas you express. They just observe that they are 
> haphazard, and that it matters, since this isn't impressionist painting.
>
> And the real problem isn't even having a bad idea, or even giving the 
> bad idea as advice to someone else. The real problem is trying to 
> defend it *after* the problem has been explained.
>
1. I never defended, I asked for elaboration.  I did say that the 
responses were more like jabs ...
2. I did say and admitted to Mark's comments that yes, suggesting to 
look around the time period was better
3. Even on the very post to which you respond I repeat having done so 
... you still take the time to bash.
4. I do not think I am making false statements when I say that some 
flavors of Linux do this automatically and I did not say nor was 
referring to "purging/deleting" but "archiving/saving"

I have access to a few Linux servers and if I check /var/log, I can see 
the syslog, syslog.1, syslog.1.gz, syslog.2.gz ... and same for a number 
of other log files - These are obviously archives of the log file, same 
with a number of other log files there in.  These are done automatically 
- purpose unknown, source unknown ... but point is, it does happen; here 
is an example:

total 170244
-rw-r--r-- 1 root              root    56883 Sep 22 12:30 alternatives.log
-rw-r--r-- 1 root              root     2986 Aug 16 07:42 alternatives.log.1
-rw-r--r-- 1 root              root     5188 Nov 19  2015 
alternatives.log.10.gz
-rw-r--r-- 1 root              root      183 Aug  3 08:05 
alternatives.log.2.gz
-rw-r--r-- 1 root              root      479 Jun 17 12:20 
alternatives.log.3.gz
-rw-r--r-- 1 root              root      300 May 25 07:51 
alternatives.log.4.gz
-rw-r--r-- 1 root              root     2767 Apr 28 23:19 
alternatives.log.5.gz
-rw-r--r-- 1 root              root      297 Mar 12  2016 
alternatives.log.6.gz
-rw-r--r-- 1 root              root      259 Feb 23  2016 
alternatives.log.7.gz
-rw-r--r-- 1 root              root     1123 Jan 28  2016 
alternatives.log.8.gz
-rw-r--r-- 1 root              root      480 Dec 19  2015 
alternatives.log.9.gz
drwxr-x--- 2 root              adm      4096 Sep 23 07:35 apache2
-rw-r----- 1 root              adm         0 Sep 23 07:35 apport.log
-rw-r----- 1 root              adm       758 Sep 22 18:03 apport.log.1
-rw-r----- 1 root              adm       644 Sep  9 22:58 apport.log.2.gz
-rw-r----- 1 root              adm       319 Aug 23 00:30 apport.log.3.gz
-rw-r----- 1 root              adm       584 Aug  7 21:35 apport.log.4.gz
-rw-r----- 1 root              adm       573 Aug  5 23:58 apport.log.5.gz
-rw-r----- 1 root              adm       307 Jul 12 16:27 apport.log.6.gz
-rw-r----- 1 root              adm       266 Jun 12 10:45 apport.log.7.gz
drwxr-xr-x 2 root              root     4096 Sep  1 07:53 apt
-rw-r--r-- 1 root              root        0 Dec  1  2015 aptitude
-rw-r----- 1 syslog            adm  11631605 Sep 23 18:09 auth.log
-rw-r----- 1 syslog            adm  10673647 Sep 18 07:35 auth.log.1
-rw-r----- 1 syslog            adm    484275 Sep 12 07:30 auth.log.2.gz
-rw-r----- 1 syslog            adm    556492 Sep  4 07:39 auth.log.3.gz
-rw-r----- 1 syslog            adm    777921 Aug 29 07:54 auth.log.4.gz
-rw-r--r-- 1 root              root     6549 Sep  9 15:46 boot.log
-rw-r--r-- 1 root              root    61499 Jul 22  2014 bootstrap.log
:


As usual, you take the very tail end of a thread, respond to it as if to 
punctuate a final verdict.

The entire argument is valid if and only if you run into a problem where 
the content of the log may have proven valuable and even then it is a 
probability, nothing definitive.  Specially in Windows, damn things 
never have anything you can use or do anything with anyway.

I understand Mark's point of view as a "SysAdmin", this is his bread and 
butter and source of "what has been going on with you ...", if you will, 
when looking at server condition and root causes to this condition.