** Description changed:
- Ubuntu 9.10 Alpha3
+ First reported on Ubuntu 9.10 Alpha3
+ It affects Ubuntu 10.04 Lucid Lynx Final Release, too.
rsyslogd: [origin software=rsyslogd swVersion=4.2.0 x-pid=2296
x-info=http://www.rsyslog.com;] rsyslogd was HUPed, type 'lightweight'.
After the
I have last message in /var/log/syslog:
May 26 07:35:16 kutoid rsyslogd: [origin software=rsyslogd swVersion=4.2.0
x-pid=953 x-info=http://www.rsyslog.com;] rsyslogd was HUPed, type
'lightweight'.
uname -a:
Linux kutoid 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686
rsyslogd -v :
rsyslogd 4.2.0, compiled with:
FEATURE_REGEXP: Yes
FEATURE_LARGEFILE: Yes
FEATURE_NETZIP (message compression): Yes
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow
Running 10.04 64bits, the same message show up BUT it seems normal. I've seen
the following behavior:
The message show in /var/log/messages; afterward it's the first one of
/var/log/syslog. Log seems to have been rotated.
If I execute something like that:
$ logger -t test This is a test message
Having the same problem here. Running 10.04 32bit.
Apr 11 12:26:46 home rsyslogd: [origin software=rsyslogd
swVersion=4.2.0 x-pid=902 x-info=http://www.rsyslog.com;] rsyslogd
was HUPed, type 'lightweight'.
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
Having the same problem here. Running 9.10 64bit on EC2, this is from
very early this morning:
Apr 8 05:32:05 ubuntu rsyslogd: [origin software=rsyslogd swVersion=4.2.0
x-pid=544 x-info=http://www.rsyslog.com;] rsyslogd was HUPed, type
'lightweight'.
--
[karmic] Messages not being sent to
Additionally the permissions on syslog:
-rw-r- 1 syslog adm 4670 2010-04-08 11:03 /var/log/syslog
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I'm still having the same problem too. Here's a strace of the rsyslog
process when it receives the HUP:
[0] spitzer:/var/log# strace -p 7830
Process 7830 attached - interrupt to quit
select(1, NULL, NULL, NULL, {17, 289248}) = ? ERESTARTNOHAND (To be restarted)
--- SIGHUP (Hangup) @ 0 (0) ---
I found this page while searching for a fix for the same problem (rsyslogd was
huped... and no more logging after that (I think cron might have stopped
running my scripts then too. can that be?)
anyway, after reading all the technical stuff here, most of which I don't
understand (what is a HUP
Opening gnome-system-log shows it searches for, and does not find:
/var/log/auth.log.0: Erro ao verificar o ficheiro '/var/log/auth.log.0':
Ficheiro ou directoria inexistente
/var/log/daemon.log.0: Erro ao verificar o ficheiro '/var/log/daemon.log.0':
Ficheiro ou directoria inexistente
@Gigglesworth, I'm still suffering the same problem as stated above at
#42. For now I've just set all group configs to syslog. I did hit
another problem which was all my own work though which might be relevant
to you. As you'll see from the dynamic file template above, rsyslog
should create a
I also have this same issue.
I noticed that my new files were all being created with the ownership of
syslog:syslog. I was able to workaround this problem with a 'chgrp -Rv
adm /var/log/foobar', where 'foobar' was the directory containing the
new files. This should work, but I'm unsure if it will
Thanks for the quick answers Michael, I'm afraid they've thrown up what
looks like a bug to me. It's similar to this bug but I'm happy to open
a new one if that's more appropriate.
Following your answers I set the following in rsyslog.conf (plus all the other
parts obviously):
$FileOwner syslog
First - apologies for the vagueness that follows. I'm only an amateur
and while I do record configurations I end up with, I don't record much
if anything on the way. Second, I got here via installing rsyslog
myself on Jaunty and then upgrading to Karmic which may also have
confused things. I
1) PrivDropTo doesn't need to match $File. Certainly not for the group. But
PrivDropToUser should be able to read files created by FileOwner. Else,
rsyslog can't read the files it creates.
2) syslog:adm is fine. The group doesn't matter so much. adm is the
recommended group for system log
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 purposes.
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
to handle
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
to
I still have one concern, and that is probably easy to verify: what happens
if logrotate runs? Does it create the files with the proper owner and
permissions? And if so, how does it know?
The default logrotate script does not create the files. It will move
the existing file out of the way 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.
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.
Michael
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 purposes.
--
** Changed in: rsyslog
Status: Confirmed = Fix Released
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I have integrated the patch (actually the idea as the code has evolved
in the mean time). Thanks for the suggestions. Please note that I think
this patch tries to fix something outside of the scope of rsyslogd. I
have posted full details in the rsyslog's bug tracker [1] as well as in
the doc for
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
I couldn't agree more, and that is why I say that this work-around will
be broken once rsyslog's privilege drop code has been rewritten. As
stated in the wiki, the current solution is a quick and dirty one,
provided only because there seems to be some value in providing it over
not providing it.
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.
-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
Rsyslogd can't run initially as non
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
--
This bug was fixed in the package rsyslog - 4.2.0-2ubuntu2
---
rsyslog (4.2.0-2ubuntu2) karmic; urgency=low
* Fix log file ownership issues when HUPing an unprivileged rsyslog
LP: #407862
- debian/rsyslog.conf: Set $FileOwner to syslog
- debian/patches/deroot.patch:
Looks fine, thanks - sponsoring.
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
OK, so I finally got time to sit down and look at this, and I can't
reproduce the problem (files that rsyslog can log stop being logged
after reload).
I tested normal logs by:
* tail -f /var/log/syslog
* sudo chown root:root /var/log/lpr.log # (-rw-r- 1 root root 776
2009-08-31 10:40
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
*
OK, I see the difference. My /var/log is the same as yours, but my
/var/log/syslog is syslog:adm. If I chown it to root:adm, I get the
same behavior as you... Now to see why/when it is root:adm (and if it
should be). I suspect my syslog:adm is because rsyslog created it for
me at some point.
I'll note that sysklogd did a rather forceful resetting of log ownership
as a result of bug 120085. Before each kickoff in its init.d script, it
would reset permissions of log files. Maybe we need something similar?
Still digging.
--
[karmic] Messages not being sent to system logs
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 michael.te...@canonical.com:
OK, I see the difference. My /var/log is the same as yours, but my
Looks like we want to set $FileOwner in /etc/rsyslog.conf to syslog
(duh, my fault for not noticing that was still set to root) and add code
to chown files if they aren't $FileOwner and $FileGroup. That should
let rsyslog do its thing.
--
[karmic] Messages not being sent to system logs
Here's a debdiff that both sets the correct $FileOwner value of syslog
and makes sure that we chown all output files as we open them.
** Attachment added: rsyslog-fileowner.debdiff
http://launchpadlibrarian.net/31084941/rsyslog-fileowner.debdiff
** Bug watch added: bugzilla.adiscon.com/ #150
** Changed in: rsyslog
Status: Unknown = Confirmed
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
** Changed in: rsyslog (Ubuntu)
Status: Incomplete = Confirmed
** Changed in: rsyslog (Ubuntu)
Assignee: Michael Terry (mterry) = (unassigned)
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are
Guh, I thought it was safe to revert to how debian did it (sending a
HUP) in the latest upload because I noticed that rsyslog forces a
lightweight HUP restart when privileges are dropped. It seemed to work
for me, but I didn't do extensive testing.
OK, so if the realization is that lightweight
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
I meant 'wont fix' in the sense of after we fix bs=1 and we set the init
script to always use hard restarts. Then, we just say 'wont fix' to
users of manual HUPs. Is there a use case for manual HUPs vs init
script restarts? (serious question, are there 3rd party apps that
depend on being able
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?
** Changed in: rsyslog (Ubuntu)
Status: Fix Released = In Progress
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
Doh, this is so obvious it's embarrassing.
rsyslog is dropping privileges to 'rsyslog:rsyslog'
/var/log is set as follows:
drwxr-xr-x 14 root root 4096 2009-08-16 07:20 /var/log
The files appear to be created before the privileges are dropped - hence
why it seems to work for a bit and then
Of course if the design is that files are opened and then permissions
are dropped (as seems to be the case on further reading:
http://wiki.rsyslog.com/index.php/Security#Dropping_Privileges), then
HUP needs to be ignored completely somehow and the reload command in the
init scripts needs reverting
This bug was fixed in the package rsyslog - 4.2.0-2ubuntu1
---
rsyslog (4.2.0-2ubuntu1) karmic; urgency=low
[ Michael Terry ]
* Merge from debian unstable (LP: #413023), remaining changes:
- Run as rsyslog:rsyslog
- Allow reading /proc/kmsg when non-root
- Cleanly
Sorry, but it still isn't fixed for me.
$ apt-cache policy rsyslog
rsyslog:
Instalado: 4.2.0-2ubuntu1
Candidato: 4.2.0-2ubuntu1
Tabela de Versão:
*** 4.2.0-2ubuntu1 0
500 http://ports.ubuntu.com karmic/main Packages
100 /var/lib/dpkg/status
$ lsb_release -rd
Description:
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 berna...@bandos.net:
Sorry, but it still isn't fixed for me.
--
Neil Wilson
--
** Changed in: rsyslog (Ubuntu)
Status: Confirmed = In Progress
** Changed in: rsyslog (Ubuntu)
Assignee: (unassigned) = Michael Terry (mterry)
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you
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
Ok problem#1 sorted. The new rsyslog system is starting up dd without
the correct blocksize indicator and that is causing everything to hang
up.
The new rsyslog init.d file uses
# shovel /proc/kmsg to pipe readable by syslog user
start-stop-daemon --start --pidfile $KMSG_PIDFILE --exec
I tried to reproduce this with a 'sudo pkill -1 rsyslog'. I got the
message in /var/log/syslog about a lightweight restart, but it kept
logging messages. So I couldn't reproduce.
Does a pkill -1 break rsyslog for you, Neil or Vajra? Do either of you
know what triggered the HUP?
--
[karmic]
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 michael.te...@canonical.com:
I tried to reproduce this with a 'sudo pkill -1 rsyslog'. I
I tried the command 'sudo pkill -1 rsyslog' in my VirtualBox
installation but couldn't see any effect. I have no idea about what
triggered the HUP. It just happens to be the last syslog message most of
the time, but not always. Sometimes the syslog stops before that
message.
--
[karmic] Messages
I'm seeing this as well. When the rsyslog is getting the new
'lightweight' restart command the log files are not being reopened
properly and nothing gets logged from the kernel.
It makes debugging a right pain.
** Changed in: rsyslog (Ubuntu)
Status: New = Confirmed
--
[karmic]
** Tags added: karmic
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
The previous syslog was from a desktop.
I'm attaching another one from a VirtualBox VM.
** Attachment added: Syslog from a VirtualBox VM
http://launchpadlibrarian.net/29800584/syslog
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this
** Attachment added: syslog
http://launchpadlibrarian.net/29786798/syslog
--
[karmic] Messages not being sent to system logs
https://bugs.launchpad.net/bugs/407862
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Thank you for taking the time to report this bug and helping to make
Ubuntu better. Judging from your description, I am going to assign this
bug to the rsyslog package in hopes that it will have a faster response.
If you believe that I have chosen the wrong package, please change your
bug to the
60 matches
Mail list logo
