devil-linux-develop Mailing List for Devil-Linux (Page 24)

Serge Leschinsky wrote:
> You can read the cache of tty actually, but it's not a proper way I guess.
> Please check if " cat /dev/vcs10" works for you.
>   
Thanks Serge, that does work, though the line formatting is a bit 
strange and it only has the last 20 or so lines. I guess there is no 
point me keeping the lines

destination console { file("/dev/tty10"); };
log { source(src); destination(console); };

in syslog-ng.conf, they don't do anything for me that the lines below 
can't do better:

destination logfile { file("/var/log/messages"); };
log { source(src); destination(logfile); };

However, your tip led me to look at "cat /dev/vcs1" which showed that a 
script of mine was frequently throwing an error message that I was 
unaware of, so that has been helpful, thanks!

Dominic

On 11/18/2009 07:05 AM, Dominic Raferd wrote:
> Heiko Zuerker wrote:
>> The console is only available on the machine itself (on the monitor).
> 
> Ah, that explains it. I hardly ever use the direct console; in fact only 
> when upgrading (and I wish there was a way of upgrading through ssh, but 
> I digress...)

You can read the cache of tty actually, but it's not a proper way I guess.
Please check if " cat /dev/vcs10" works for you.

Serge

Heiko Zuerker wrote:
> The console is only available on the machine itself (on the monitor).

Ah, that explains it. I hardly ever use the direct console; in fact only 
when upgrading (and I wish there was a way of upgrading through ssh, but 
I digress...)

> -----Original Message-----
> From: Dominic Raferd [mailto:dl...@ed...]
> Sent: Wednesday, November 18, 2009 8:02 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] syslog-ng version
> 
> Serge Leschinsky wrote:
> > Awesome! I really appreciate your investigation because my upgrade of
> syslog-ng
> > to 3.0 caused the problem which I can neither reproduce nor fix. To
> live without
> > feeling of guilt is much better! :-)
> >
> Thank you, I pronounce you absolved! That is assuming that you have
> said
> three Hail Marys - and the problem doesn't reoccur :-) [On second
> thoughts, as this is Devil-Linux maybe Hail Marys are not
> appropriate!?]
> > Console #10 is available after "ALT+F10" keys pressing.
> >
> Still I can't get to it, does this only work from the local console not
> from ssh?
> 
> When I do ps -A I see tty1 through to tty7 and also pts/0 (which in
> fact
> is my own ssh console I believe), but no tty10. So maybe syslog-ng is
> not writing to it because it doesn't exist? In any case I don't think I
> can reach any of the ttys. When I press ALT+F2 (I am using putty) I
> just
> see:

The console is only available on the machine itself (on the monitor).

Heiko

Serge Leschinsky wrote:
> Awesome! I really appreciate your investigation because my upgrade of syslog-ng
> to 3.0 caused the problem which I can neither reproduce nor fix. To live without
> feeling of guilt is much better! :-)
>   
Thank you, I pronounce you absolved! That is assuming that you have said 
three Hail Marys - and the problem doesn't reoccur :-) [On second 
thoughts, as this is Devil-Linux maybe Hail Marys are not appropriate!?]
> Console #10 is available after "ALT+F10" keys pressing.
>   
Still I can't get to it, does this only work from the local console not 
from ssh?

When I do ps -A I see tty1 through to tty7 and also pts/0 (which in fact 
is my own ssh console I believe), but no tty10. So maybe syslog-ng is 
not writing to it because it doesn't exist? In any case I don't think I 
can reach any of the ttys. When I press ALT+F2 (I am using putty) I just 
see:

[12~

On 11/17/2009 03:11 AM, Dominic Raferd wrote:

> In any case my guess is that "/etc/init.d/syslog reload" after upgrading 
> DL switches from unix-stream to unix-dgram (because it switches from the 
> default configuration at boot time to my configuration which I naturally 
> elect to retain), and that this causes some problem which, hours later, 
> leads syslog-ng to crash. This would also explain why I cannot replicate 
> the problem except at upgrade - and why others do not experience it. 
> Also why Heiko found the problem disappeared after removing his custom 
> syslog-ng.conf (if you still have the custom file somewhere, Heiko, 
> maybe you could check if it had unix-dgram?)
> 
> I have changed my syslog-ng.conf to use unix-stream (the unix-dgram must 
> be a carry-over from an earlier DL configuration), and am hoping that 
> the problem will not recur.
Awesome! I really appreciate your investigation because my upgrade of syslog-ng
to 3.0 caused the problem which I can neither reproduce nor fix. To live without
feeling of guilt is much better! :-)


> 
> BTW does anyone know what is /dev/tty10, is it working and how does one 
> get to see it? I guess this is why I specified the additional 
> destination logfile, because I had no idea where the console messages 
> were going.
> 
Console #10 is available after "ALT+F10" keys pressing.

Thanks,
Serge

Serge Leschinsky wrote:
> On 11/15/2009 06:02 AM, Bruce Smith wrote:
>   
>> A better question might be
>> "Does syslog-ng run fine for anyone in the latest RC2?".
>>
>> Personally I'm not running syslog-ng on RC2.
>> So asking me if it crashes does not apply to me, and you might
>> incorrectly infer from my silence that it's working for me.
>>
>>  - BS
>>     
>
> My systems work correctly. However, these systems are not "official" DL build,
> but I believe it's not a reason of the problem reproducibility...
>
> Serge
>   
I now think that the problem may relate to syslog-ng switching upon 
reload between source unix-stream and source unix-dgram. The default 
conf has (stripping comments):

@version: 3.0
options { long_hostnames(on); flush_lines(0); time_reopen(60); use_dns 
(no); };
source src { file("/proc/kmsg" program_override("kernel: ")); 
unix-stream("/dev/log" max-connections(1000)); internal(); };
destination console { file("/dev/tty10"); };
log { source(src); destination(console); };

My syslog-ng.conf has:

@version: 3.0
options { stats_freq(7200); long_hostnames(on); flush_lines(0); 
time_reopen(60); use_dns (no);  };
source src { file("/proc/kmsg" program_override("kernel: ")); 
unix-dgram("/dev/log" max-connections(1000)); internal(); };
destination console { file("/dev/tty10"); };
log { source(src); destination(console); };
destination logfile { file("/var/log/messages"); };
log { source(src); destination(logfile); };

see some discussion here which may or may not be related: 
http://74.125.77.132/search?q=cache:j-kBNRHUY-EJ:www.mail-archive.com/debian-bugs-dist%40lists.debian.org/msg240161.html+unix-stream+unix-dgram+reload&cd=1&hl=en&ct=clnk&gl=uk

In any case my guess is that "/etc/init.d/syslog reload" after upgrading 
DL switches from unix-stream to unix-dgram (because it switches from the 
default configuration at boot time to my configuration which I naturally 
elect to retain), and that this causes some problem which, hours later, 
leads syslog-ng to crash. This would also explain why I cannot replicate 
the problem except at upgrade - and why others do not experience it. 
Also why Heiko found the problem disappeared after removing his custom 
syslog-ng.conf (if you still have the custom file somewhere, Heiko, 
maybe you could check if it had unix-dgram?)

I have changed my syslog-ng.conf to use unix-stream (the unix-dgram must 
be a carry-over from an earlier DL configuration), and am hoping that 
the problem will not recur.

BTW does anyone know what is /dev/tty10, is it working and how does one 
get to see it? I guess this is why I specified the additional 
destination logfile, because I had no idea where the console messages 
were going.

Dominic

On 11/15/2009 06:02 AM, Bruce Smith wrote:
> A better question might be
> "Does syslog-ng run fine for anyone in the latest RC2?".
> 
> Personally I'm not running syslog-ng on RC2.
> So asking me if it crashes does not apply to me, and you might
> incorrectly infer from my silence that it's working for me.
> 
>  - BS

My systems work correctly. However, these systems are not "official" DL build,
but I believe it's not a reason of the problem reproducibility...

Serge

A better question might be
"Does syslog-ng run fine for anyone in the latest RC2?".

Personally I'm not running syslog-ng on RC2.
So asking me if it crashes does not apply to me, and you might
incorrectly infer from my silence that it's working for me.

 - BS


On Sun, Nov 15, 2009 at 08:48, Heiko Zuerker <he...@zu...> wrote:
> Does anybody other than me and Dominic experience the syslog-ng crashes?
> I did start over with a new syslog-ng.conf and can't reproduce the issue
> since then. Not sure what's going on....
>
> Heiko

Does anybody other than me and Dominic experience the syslog-ng crashes?
I did start over with a new syslog-ng.conf and can't reproduce the issue
since then. Not sure what's going on....

Heiko

> -----Original Message-----
> From: Heiko Zuerker [mailto:he...@zu...]
> Sent: Friday, November 13, 2009 12:34 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] syslog-ng version
> 
> Quoting Serge Leschinsky <fi...@in...>:
> 
> > Heiko Zuerker wrote:
> >>> -----Original Message-----
> >>> From: Bruce Smith [mailto:bw...@re...]
> >>> Sent: Sunday, November 08, 2009 9:59 AM
> >>> To: dev...@li...
> >>> Subject: Re: [Devil-linux-develop] syslog-ng version
> >>>
> >>> I don't really know the difference between v2 & v3.
> >>>
> >>> Is it grsec that's causing it to crash?
> >>
> >> No, it crashes in the -server version too. :-(
> >>
> > Heiko, I have been trying to reveal a problem with syslog-ng, which
> works
> > perfectly on my setups. To be honest, I cannot reproduce the problem
> (DL is
> > built on my box, though). However I found the interesting  message in
> the
> > syslog-ng list:
> >  cfg-lex: fixed a possible segmentation fault in HUP processing if
> > included files have syntax errors
> >
> > May I ask what config file do you use? Is it default conf or
> modifyed? My
> > configs are default initially and slightly modified later.
> 
> I can't check it right now, but I have pretty much the default
> syslog-ng.conf with the addition of remote logging via udp 514 (?) to
> another host.

The problem either shows within the next 2 minutes of the reboot, or it'll
work.

I checked my config and all servers except the log host use the base
syslog-ng file, just with the remote logging enabled.
Just in case I'll recreate the config. If it still fails, I'll start messing
with the loghost itself, since I syslog-ng complains on that one about some
parameter (it only complains about performance).


Heiko

Quoting Serge Leschinsky <fi...@in...>:

> Heiko Zuerker wrote:
>>> -----Original Message-----
>>> From: Bruce Smith [mailto:bw...@re...]
>>> Sent: Sunday, November 08, 2009 9:59 AM
>>> To: dev...@li...
>>> Subject: Re: [Devil-linux-develop] syslog-ng version
>>>
>>> I don't really know the difference between v2 & v3.
>>>
>>> Is it grsec that's causing it to crash?
>>
>> No, it crashes in the -server version too. :-(
>>
> Heiko, I have been trying to reveal a problem with syslog-ng, which works
> perfectly on my setups. To be honest, I cannot reproduce the problem (DL is
> built on my box, though). However I found the interesting  message in the
> syslog-ng list:
>  cfg-lex: fixed a possible segmentation fault in HUP processing if
> included files have syntax errors
>
> May I ask what config file do you use? Is it default conf or modifyed? My
> configs are default initially and slightly modified later.

I can't check it right now, but I have pretty much the default  
syslog-ng.conf with the addition of remote logging via udp 514 (?) to  
another host.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko Zuerker wrote:
>> -----Original Message-----
>> From: Bruce Smith [mailto:bw...@re...]
>> Sent: Sunday, November 08, 2009 9:59 AM
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] syslog-ng version
>>
>> I don't really know the difference between v2 & v3.
>>
>> Is it grsec that's causing it to crash?
> 
> No, it crashes in the -server version too. :-(
> 
Heiko, I have been trying to reveal a problem with syslog-ng, which works
perfectly on my setups. To be honest, I cannot reproduce the problem (DL is
built on my box, though). However I found the interesting  message in the
syslog-ng list:
 cfg-lex: fixed a possible segmentation fault in HUP processing if
included files have syntax errors

May I ask what config file do you use? Is it default conf or modifyed? My
configs are default initially and slightly modified later.

Serge

Serge Leschinsky wrote:
> Heiko Zuerker wrote:
> 
>> I don't remember why we would have switched to the inetutils one.  
>> Search the mailinglist archive, if there's nothing in there, I don't  
>> care if we switch to the iputils one.
>>
> 
> I'll fix that.
> 
Done.

Serge

Heiko Zuerker wrote:

> 
> I don't remember why we would have switched to the inetutils one.  
> Search the mailinglist archive, if there's nothing in there, I don't  
> care if we switch to the iputils one.
> 

I'll fix that.

Serge

Quoting Bruce Smith <bw...@re...>:

>> I have just found out that in DL 1.4, the ping command (from inetutils)
>> is missing the -I option.... the ping from iputils (used in 1.2.x).
>>
>> '-I' permits to specify the source address or interface used for the
>> ICMP packets, so this was very useful for testing tunnels. Is there some
>> other way to do this?
>
> ping from iputils is setting there in the tmp directory, but is not
> the one being installed.  It doesn't matter to me which ones we use,
> and I don't know why we switched to the inetutils version of ping.
> Heiko?
>
> FWIW, ping on Ubuntu 9.04 appears to be the one from iputils.  At
> least the "--help" screen looks like the iputils version, not the
> inetutils version of ping.

I don't remember why we would have switched to the inetutils one.  
Search the mailinglist archive, if there's nothing in there, I don't  
care if we switch to the iputils one.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> I have just found out that in DL 1.4, the ping command (from inetutils)
> is missing the -I option.... the ping from iputils (used in 1.2.x).
>
> '-I' permits to specify the source address or interface used for the
> ICMP packets, so this was very useful for testing tunnels. Is there some
> other way to do this?

ping from iputils is setting there in the tmp directory, but is not
the one being installed.  It doesn't matter to me which ones we use,
and I don't know why we switched to the inetutils version of ping.
Heiko?

FWIW, ping on Ubuntu 9.04 appears to be the one from iputils.  At
least the "--help" screen looks like the iputils version, not the
inetutils version of ping.

 - BS

Hi,

I have just found out that in DL 1.4, the ping command (from inetutils)
is missing the -I option.... the ping from iputils (used in 1.2.x).

'-I' permits to specify the source address or interface used for the
ICMP packets, so this was very useful for testing tunnels. Is there some
other way to do this?

Thanks,

Frank
-- 
_______________________________________________
 Centre de Technologie de l'Education
 29 avenue John F. Kennedy
 L-1855 Luxembourg-Kirchberg
 email: Fra...@ct...
 tél.: +352 247-85973
 fax: +352 333797
_______________________________________________

Heiko,

I use syslog-ng v3 for a while on different servers - I also built centralized
syslog-server on top of v3. It works very good.

The latest syslog-ng v3 (as a part of DL) I have got is:

root@gw:~ # syslog-ng --version
syslog-ng 3.0.4
Revision:
ssh+git://bazsi@git.balabit//var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.0#master#1b5d618e301ad94aa20e692ffba16469dece8d10
Compile-Date: Sep 19 2009 18:24:01
Enable-Threads: off
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-Sun-STREAMS: off
Enable-Sun-Door: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: on
Enable-SSL: on
Enable-SQL: off
Enable-Linux-Caps: on
Enable-Pcre: on

It works correctly... However, it's not a representative sample (and it was
built without sql support).  Let's revert it to v2, while I'm working on v3 problem.

Serge

Heiko Zuerker wrote:
> Hey,
> 
> Is there a reason to stay with Syslog-NG v3?
> 
> It keeps crashing and even the newest GIT version doesn’t work right.

> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: Sunday, November 08, 2009 9:59 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] syslog-ng version
> 
> I don't really know the difference between v2 & v3.
> 
> Is it grsec that's causing it to crash?

No, it crashes in the -server version too. :-(

Heiko

I don't really know the difference between v2 & v3.

Is it grsec that's causing it to crash?

 - BS


On Sun, Nov 8, 2009 at 09:58, Heiko Zuerker <he...@zu...> wrote:
> Hey,
>
>
>
> Is there a reason to stay with Syslog-NG v3?
>
> It keeps crashing and even the newest GIT version doesn’t work right.
>
>
>
> I’m very tempted to go back down to v2.
>
>
>
> Regards
>
>   Heiko Zuerker
>
>   http://www.devil-linux.org
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>

Hey,

 

Is there a reason to stay with Syslog-NG v3?

It keeps crashing and even the newest GIT version doesn't work right.

 

I'm very tempted to go back down to v2.

 

Regards

  Heiko Zuerker

  http://www.devil-linux.org

 

> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: Friday, November 06, 2009 9:47 AM
> To: Devil Linux
> Subject: Re: [Devil-linux-develop] [Devil-Linux 1.4 0000030]: In Setup:
> can't select 'none' or 'default' for network adapter type
> 
> > Might also be good to have an option for 'none' or 'disable' which
> would
> > disable the ethernet port altogether? But less important.
> 
> How would we go about disabling the port all together?
> 
> Loading the module seems to be less important with the 2.6 kernel
> since most hardware is automatically detected and the modules
> automatically loaded.  Even if there is no module specified, there is
> a good chance the NIC will still be active.
> 
> (Active in the sense the lights will be blinking, although it
> shouldn't have a IPv4 address.  Not sure about IPv6.)

"ifconfig ethX down" should do the trick.

Heiko

> Might also be good to have an option for 'none' or 'disable' which would
> disable the ethernet port altogether? But less important.

How would we go about disabling the port all together?

Loading the module seems to be less important with the 2.6 kernel
since most hardware is automatically detected and the modules
automatically loaded.  Even if there is no module specified, there is
a good chance the NIC will still be active.

(Active in the sense the lights will be blinking, although it
shouldn't have a IPv4 address.  Not sure about IPv6.)

 - BS

> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: Thursday, November 05, 2009 4:15 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Closing Mantis issues.
> 
> >> After fixing a problem, what is the correct way to update Mantis?
> >>
> >> I see two possible options.  Change it to "closed" or "resolved"?
> >> I'm not sure I understand the difference (and have been using
> closed).
> >>
> >> >From the stats, there are a number of both "closed" & "resolved"
> >> issues, so I may not be the only one who's not sure.
> >
> > Not sure if I remember right, but I think this is what Serge
> suggested (and
> > I agreed):
> > Set issue to 'resolved" once you think it's fixed, then 'close' it
> once the
> > user confirms that it's fixed.
> >
> > Now that I think of it, this really depends on the user getting back
> to
> > us....
> > We could just 'close' them, it is pretty simple in Mantis to reopen
> the
> > issue. This would keep things quite a bit cleaner.
> >
> > Thoughts?
> 
> I'm fine with just closing them.
> 
> I guess we could use "resolved" if there is some doubt about the fix
> and user confirmation is wanted.

Yeah let's do that, that's going to be a lot cleaner then.

Heiko