> I agree it's probably (b), with the addendum that certainly part of the
> problem was previous rsyslog versions, which created the files as root.
> If that were the only problem, I suppose the packaging scripts could
> change permissions at install time, but that would require special
> logic
> t
> > I agree. The logrotate.d file that rsyslog uses in Debian/Ubuntu
> should use the 'create' directive which says
> > which user/group to create files as.
>
> Hmm, I guess that's actually not needed. Without the create directive,
> it leaves the creating up to rsyslog, which is fine for our pur
I think I missed to express me clearly enough in my previous reply:
> - firstly we either create root owned files, or open root owned files
> and ...
Why do you create these files as root-owned in the first place? Why not
create them with the right user?That is my primary point.
Rainer
--
[kar
> -Original Message-
> From: boun...@canonical.com [mailto:boun...@canonical.com] On Behalf Of
> Neil Wilson
> Sent: Friday, September 11, 2009 2:05 PM
> To: Rainer Gerhards
> Subject: Re: [Bug 407862] Re: [karmic] Messages not being sent to
> system logs
>
> R
Rsyslogd can't run initially as non-root if it is going to listen on
port 512 or directly access the kernel logs. It needs to open that
first as root and then keep them open while dropping privileges. So
we're still going to have to root drop problem regrettably. (I'm sure
you already know that. I'
I think we get into the realms of Unix philosophy at this point.
What actually needs to be fixed is the ability to set permissions on
network ports and other 'root only' system facilities. Then rsyslog
could be started as a non-privileged user and still get the facilities
it requires.
This 'obtai
My machine is a fresh install of Karmic Alpha 3 on the bare metal - no
upgrades. So the permissions are created by the current package system
and/or logrotate.
2009/8/31 Michael Terry :
> OK, I see the difference. My /var/log is the same as yours, but my
> /var/log/syslog is syslog:adm. If I ch
For me it is busted as soon as I start up the machine unless I change
the ownership on the /var/log/* files to syslog:syslog and then it
will work fine.
I've just done the same as you after a fresh install of rsyslog to
make sure I'm on the latest repository version.
* tail /var/log/syslog
* su
Yes. I think the reload needs to stay as a hard restart until upstream
refactors the code to separate the privileged and non-privileged code
base slightly more effectively.
How would the third party app know that the syslog server that is
running is rsyslog rather than syslog-ng or sysklogd? Don't
The 'bs=1' kernel message fix helps, since otherwise kernel messages
don't get through at all. With bs=1 you get kernel messages when you
restart the daemon, but it stops again when you issue a 'HUP'.
I put some debug into the code over the weekend and lightweight
restart appears to close all the
Same here, but at least the kern log works now and you can get the
logging working via a restart.
Now to find out what is causing that HUP and why the files aren't
opening properly.
2009/8/14 Jose Bernardo :
> Sorry, but it still isn't fixed for me.
--
Neil Wilson
--
[karmic] Messages not be
I did a check this morning and the pkill -HUP does stop the logging -
if it is actually still working at that point in time.
I also noticed that the logging will just stop *without* seeing the
HUP message. dmesg continues merrily, but nothing appears in
/var/log/syslog or /var/log/messages.
All v
No idea what's causing it. Mostly I see the restart message on boot
but sometimes I don't.
I feel this is going to be one of those irritating bugs that's
difficult to track down...
2009/8/10 Michael Terry :
> I tried to reproduce this with a 'sudo pkill -1 rsyslog'. I got the
> message in /var/l
13 matches
Mail list logo
