[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 above message in syslog no more messages are sent to any system logs. Plugging and unplugging an usb device produce no messages, although the device is mounted an works fine. Also, nothing is produced by the logger command. The problem occurs in a desktop and in a VirtualBox virtual machine. It occurred soon after karmic alpha 3 installation and persisted after installing all available updates in both environments. I'm attaching a typical 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 mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 code): No Atomic operations supported:Yes Runtime Instrumentation (slow code):No See http://www.rsyslog.com for more information. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 GNU/Linux Kubuntu Linux Lucid Lynx -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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" test message shows up in both syslog and messages. This is all absolutely normal, isn't? I'm available if further test is needed… -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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) ---
rt_sigaction(SIGHUP, {0x40c630, [], SA_RESTORER, 0x7f0cd0500190}, NULL, 8) = 0
rt_sigreturn(0x1) = -1 EINTR (Interrupted system call)
futex(0x800594, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x800590, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
sched_yield() = 0
select(1, NULL, NULL, NULL, {30, 0})= 0 (Timeout)
access("/var/log/syslog", F_OK) = 0
open("/var/log/syslog", O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_CLOEXEC, 0640) =
-1 EACCES (Permission denied)
select(1, NULL, NULL, NULL, {30, 0})= 0 (Timeout)
select(1, NULL, NULL, NULL, {30, 0})= 0 (Timeout)
access("/var/log/syslog", F_OK) = 0
open("/var/log/syslog", O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_CLOEXEC, 0640) =
-1 EACCES (Permission denied)
select(1, NULL, NULL, NULL, {30, 0})= 0 (Timeout)
select(1, NULL, NULL, NULL, {30, 0})= 0 (Timeout)
/var/log/syslog is owned by root:adm with permissions 0664 and created
by logrotate after the rotation.
** Changed in: rsyslog (Ubuntu)
Status: Fix Released => 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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 anyway?), I still haven't figured out what 'm
supposed to do. Has this bug been fixed, and me getting it is a different bug?
is it only fixed in rsyslogd 4.7? will uninstalling rsyslogd and installing
sysklogd solve it?
Thanx
--
[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
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 /var/log/debug.0: Erro ao verificar o ficheiro '/var/log/debug.0': Ficheiro ou directoria inexistente /var/log/kern.log.0: Erro ao verificar o ficheiro '/var/log/kern.log.0': Ficheiro ou directoria inexistente /var/log/messages.0: Erro ao verificar o ficheiro '/var/log/messages.0': Ficheiro ou directoria inexistente /var/log/syslog.0: Erro ao verificar o ficheiro '/var/log/syslog.0': Ficheiro ou directoria inexistente /var/log/user.log.0: Erro ao verificar o ficheiro '/var/log/user.log.0': Ficheiro ou directoria inexistente Does the count start on zero? -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
@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 new directory /var/log/ as the month changes. This didn't work for me but that was simply because rsyslog was running as syslog:syslog but /var/log was root:root 0755. That at least was clear once I thought to look. To save anyone else doing this other test (with apologies to Michael for not simply accepting your statement) I also tested if it made any difference putting user syslog in supplementary group syslog. I couldn't see any difference for rsyslog although as an interactive user I couldn't chgrp a file to a group I wasn't a member of. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 work when files are recreated during the next log rotation. I haven't had more time to investigate, but it does appear that there is a mismatch with the file ownership. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 $FileGroup adm $FileCreateMode 0640 $DirOwner syslog $DirGroup adm $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup syslog I want dynamic files based on severity (among other things but this is what I tested) using the following template: $template tLevel, "/var/log/%$MONTH%/%$DAY%/%HOSTNAME%.%SYSLOGSEVERITY-TEXT%" I sent a log entry with: logger -p local0.debug 'debug test' and this resulted in the following syslog entry: Nov 16 15:37:27 robbie rsyslogd: Could not open dynamic file '/var/log/11/16/robbie.debug' - discarding message although ls -l /var/log/11/16 showed: -rw-r- 1 syslog syslog 0 2009-11-16 15:37 robbie.debug -rw-r- 1 syslog adm156681 2009-11-16 15:35 robbie.info -rw-r- 1 syslog adm 622 2009-11-16 15:37 robbie.syslog Yesterday when the only difference was: $FileGroup syslog $DirGroup syslog robbie.debug was created and written to as I expected. Just in case it's relevant I restarted rsyslog after editing the config with: service rsyslog restart robbie.info and robbie.syslog were created overnight owned by syslog:syslog but I did a chown before the test I've described here. The 2 things that look like bugs to me are: - creating robbie.debug with the wrong group - rsyslog being unable to write to it even with the wrong group. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 files. 3) Yes, adm is for read-only access to system files. 4) No, syslog doesn't need to be in adm. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 currently have rsyslog 4.2.0-2ubuntu5. Anyway, while trying to get to a setup I like, I've been having all sorts of trouble with file/dir permissions. I think I'm ok now and I can get on with the other stuff I want to do but I have a couple of observations/questions which may arise from either the package or my fingers. When I started looking at rsyslog after the upgrade, I found that rsyslog.conf did not set $DirOwner or $DirGroup at all. Having set those the same as $FileOwner and $FileGroup rsyslog managed to create the directories I want but I still had problems with dynafiles being created and eventually found this bug report. Following Rainer's link [1] in comment #28 I read in Michael's description that $PrivDropToUser and $PrivDropToGroup should be set the same as $FileOwner and $FileGroup. I had $PrivDropTo as syslog:syslog but $File as syslog:adm. I don't believe I set any of those myself. I've now set all the groups to syslog and things seem to be working now. This last issue leaves me questions though: - _must_ $PrivDropTo match $File? I haven't spotted that as a requirement anywhere else or even mentioned in the docs I've read. - should I have used syslog:syslog or syslog:adm? - is the intention behind group adm to give read-only access to various admin files for appropriate users? - if I use syslog:adm, should/must the syslog user be in group adm? -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
> 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 let rsyslog recreate. It will also
HUP (but this becomes a restart with new upstartification changes)
rsyslog.
One interesting thing about logrotate is that it also doesn't know about
user changes to the list of output files. The config just assumes. So
it requires some skill as an admin to add/remove files correctly.
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
restart rsyslog >/dev/null 2>&1 || true
endscript
}
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
restart rsyslog >/dev/null 2>&1 || true
endscript
}
--
[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
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
RE: [Bug 407862] Re: [karmic] Messages not being sent to system logs
> 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 the case where the user set their own user/group. > > I don't have any evidence yet that another program is creating/changing > permissions on those files (all the current reports are explainable by > rsyslog creating them as root before the user/group config change -- > there was a period of time where rsyslog was running unprivileged, but > the config told it to create files as root, my bad), but I haven't done > an audit to make sure it's the case. I agree that such a review would > be helpful. OK, if it is only this transient problem, I think the current fix is a good one to solve the situation. Nevertheless, you correctly point out that some issue may occur if the user changes the file owner. Of course, one can argue that then this is a user error, but I agree it would be useful to have some utility to aid the user in that process. At least some doc should explain the situation and what to watch for. > So on the theory that the only real issue is previous rsyslog versions > (until such an above review finds anything), the current 'force owner > on > open' behavior could conceivably be replaced by some install-time > chowning, but to do that right (respect any user modification of either > user/group or output files), it would involve parsing rsyslog.conf & > rsyslog.conf.d/*. > > Maybe for this usecase (distro changing default user/group), when > rsyslog becomes fully-unprivileged, it could include a utility program > called, say, rsyslog-fix-permissions that would run as root and chown > all its output files? This sounds very reasonable. I will keep this on my mind when working on the new privilege drop code (whenever this may be). I tend to think that this must be done by an interactive instance of rsyslogd, because only it has the full knowledge of the configuration. But it may be really tricky for dynafiles, where rsyslogd only knows at runtime, "as it happens" which files need to be opened. Anyway, I think we can postpone that discussion until I finally begin to implement that functionality. > I suppose a second alternative is to force a logrotate that doesn't > create the files and let rsyslog recreate its files. But that relies > on > the logrotate config and seems a little forceful. I don't think it > would be wise to logrotate when an administrator isn't expecting it. full ack 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? I understand that in Ubuntu terms, the "rsyslog logrotate script" is considered part of the rsyslog package, but from the rsyslog project's POV (mine ;)), this is something totally external, so I neither know exactly what happens nor do I have any control over it. Actually, logrotate is my primary concern in regard to overall system stability. Rainer -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 the case where the user set their own user/group. I don't have any evidence yet that another program is creating/changing permissions on those files (all the current reports are explainable by rsyslog creating them as root before the user/group config change -- there was a period of time where rsyslog was running unprivileged, but the config told it to create files as root, my bad), but I haven't done an audit to make sure it's the case. I agree that such a review would be helpful. So on the theory that the only real issue is previous rsyslog versions (until such an above review finds anything), the current 'force owner on open' behavior could conceivably be replaced by some install-time chowning, but to do that right (respect any user modification of either user/group or output files), it would involve parsing rsyslog.conf & rsyslog.conf.d/*. Maybe for this usecase (distro changing default user/group), when rsyslog becomes fully-unprivileged, it could include a utility program called, say, rsyslog-fix-permissions that would run as root and chown all its output files? I suppose a second alternative is to force a logrotate that doesn't create the files and let rsyslog recreate its files. But that relies on the logrotate config and seems a little forceful. I don't think it would be wise to logrotate when an administrator isn't expecting it. Thanks very much for your Ubuntu concern. I appreciate it! -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
RE: [Bug 407862] Re: [karmic] Messages not being sent to system logs
> > 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. ... but in that case, I wonder why there is an issue in the first place. rsyslogd, correctly configured, creates files with the correct user. If the files have the correct user, and the right permissions, there is no issue in re-opening files after a HUP. The original bug report claimed that the files were root-owned. So I conclude the problem is either of this: a) rsyslog.conf is incorrect and does not specify the correct file owner at the correct location OR b) some other process creates the files with the wrong user In theory, there is a possibility c) that there is a bug in rsyslogd that prevents creation with the proper owner. So far, I outrule c) because my testing indicates this is not the case. So it is either a) or b). Now comes the important point: if it is a), the problem will persist, because the provided fix will also fail because of the configuration. So it looks like it is b). That, however, means that the current solution works to some degree, but fails under some circumstances. This, I think, is pretty dangerous and very hard to solve when a bug report comes in. Please see my failure case described in the links I posted in one of my earlier messages. So while I have implemented a work-around in rsyslog, I still think this is the wrong cure and careful consideration and review of all system components is needed. Also keep in mind that the work-around will most likely always fail with future rsyslg versions that have proper privilege drop code. Thus the current work-around buys some time to find the component the incorrectly creates the files - but it does not more. Of course, distro-specific questions are not really of my concern. But I am being somewhat persistent on this issue as I believe Ubuntu is a very important distribution, does great work and as such deserves good contributions. Rainer -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
> 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. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
> 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 Biebl, the Debian Maintainer, suggested using capabilities to reduce > this need. I will look into this, but other than that I agree. I looked into this a bit. You'd need to use the CAP_SYS_ADMIN capability. Which is sort of a catch-all. It allows the program to do many, many root-y things [1]. Honestly, I'd prefer to have a root dd process (which is contained and pretty safe) feeding an unprivileged rsyslog than have an rsyslog with CAP_SYS_ADMIN. [1] http://www.lids.org/lids-howto/node57.html -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
RE: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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 -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
RE: [Bug 407862] Re: [karmic] Messages not being sent to system logs
> -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-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'm just pointing it out for the rest of the > audience here). Michael Biebl, the Debian Maintainer, suggested using capabilities to reduce this need. I will look into this, but other than that I agree. > Once you sort the code so that it goes to non-root early, then it will > fail to open any file for which it doesn't have permissions and will > create files with the correct ownership. I believe that is the right > approach: rsyslog shouldn't be changing permissions on files. full ack > > The issue we have at the moment is two fold: > > - firstly we either create root owned files, or open root owned files > and then write to them for a bit until the privileges drop and the > files are closed > - secondly we don't get any decent error out of rsyslog reporting the > 'Permission denied' issue on opening/reopening of the files. I have seen some issue when I worked on the patch this morning. But this issue was so far unreported. It looks like a regression, and I am not sure if 4.2.0 already has this problem. > > As you probably already know the file access code could do with a bit > of TLC. It doesn't report errors as well as it should. large parts of the code have been rewritten in the current beta/devel versions. > If you drop root privileges early enough before any files are opened > or created and report errors properly in the File code then everything > else will follow. Ah, OK, I see where you are coming from. So the files were initially created by rsyslogd? I thought they were created by some other process. Mhhh... could be. But in any case, the very simple cure with the current code base is to specify the correct file owner right at the top of rsyslog.conf, so the files will be created with the correct owner right from the beginning. Note that my patch (and the patch posted here), assumes that the file owner was properly configured. If there is no proper owner config, neither of the patches will work. Thus I assumed this were no issue... > Note that we don't kick off root processes to write files; we kick > them off to read privileged files for which there is no other > alternative - the kernel dmesg output doesn't appear to have a > permission entry that works properly for example, and of course > network ports under 1024 need root permission. It might be possible to > engineer rsyslogd so that it runs as two processes that talk to each > other. One as root to read the network ports and the kernel with the > other running as a normal user to do the normal syslog processing. you can already do that, and it is my default suggested config for security-sensitive environments. I think internally TCP connections are used to combine the two, but other modes are also possible. But my reference was not to processes to read files, but to the process to write files. Rainer > > > 2009/9/11 Rainer Gerhards : > > 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. > > > > However, as far as this problem is concerned, this is not over root > > access or non-root access. The issue is that rsyslogd should run as > non- > > root. Let's assume it finally has decent code to do that. Then it > will > > run, from the start on, as non-root. But then rsyslog.conf specifies > > that rsyslogd shall write to files where it has no permissions. My > point > > is that either rsyslog.conf is invalid OR the files have been created > > with wrong permissions. In any case, it is not something that rsyslog > > can/should fix, because it is outside the scope of its configuration > and > > capabilities. I would consider it the wrong approach to create a root > > child process just to write to some files, which apparently are set > not > > to be accessible for the daemon users. IMHO this is an inconsistent > > system setup, and *that* root cause needs to be fixed. &
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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'm just pointing it out for the rest of the audience here). Once you sort the code so that it goes to non-root early, then it will fail to open any file for which it doesn't have permissions and will create files with the correct ownership. I believe that is the right approach: rsyslog shouldn't be changing permissions on files. The issue we have at the moment is two fold: - firstly we either create root owned files, or open root owned files and then write to them for a bit until the privileges drop and the files are closed - secondly we don't get any decent error out of rsyslog reporting the 'Permission denied' issue on opening/reopening of the files. As you probably already know the file access code could do with a bit of TLC. It doesn't report errors as well as it should. If you drop root privileges early enough before any files are opened or created and report errors properly in the File code then everything else will follow. Note that we don't kick off root processes to write files; we kick them off to read privileged files for which there is no other alternative - the kernel dmesg output doesn't appear to have a permission entry that works properly for example, and of course network ports under 1024 need root permission. It might be possible to engineer rsyslogd so that it runs as two processes that talk to each other. One as root to read the network ports and the kernel with the other running as a normal user to do the normal syslog processing. 2009/9/11 Rainer Gerhards : > 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. > > However, as far as this problem is concerned, this is not over root > access or non-root access. The issue is that rsyslogd should run as non- > root. Let's assume it finally has decent code to do that. Then it will > run, from the start on, as non-root. But then rsyslog.conf specifies > that rsyslogd shall write to files where it has no permissions. My point > is that either rsyslog.conf is invalid OR the files have been created > with wrong permissions. In any case, it is not something that rsyslog > can/should fix, because it is outside the scope of its configuration and > capabilities. I would consider it the wrong approach to create a root > child process just to write to some files, which apparently are set not > to be accessible for the daemon users. IMHO this is an inconsistent > system setup, and *that* root cause needs to be fixed. > > Rainer > > -- > [karmic] Messages not being sent to system logs > https://bugs.launchpad.net/bugs/407862 > You received this bug notification because you are a direct subscriber > of the bug. > -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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. However, as far as this problem is concerned, this is not over root access or non-root access. The issue is that rsyslogd should run as non- root. Let's assume it finally has decent code to do that. Then it will run, from the start on, as non-root. But then rsyslog.conf specifies that rsyslogd shall write to files where it has no permissions. My point is that either rsyslog.conf is invalid OR the files have been created with wrong permissions. In any case, it is not something that rsyslog can/should fix, because it is outside the scope of its configuration and capabilities. I would consider it the wrong approach to create a root child process just to write to some files, which apparently are set not to be accessible for the daemon users. IMHO this is an inconsistent system setup, and *that* root cause needs to be fixed. Rainer -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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 'obtain what you require and then drop privileges' is a nasty workaround. To be honest I prefer the Debian workaround where a root only process grabs the relevant data and resurfaces it via a named pipe - with the appropriate access permissions. Perhaps rsyslog should look at adopting that approach for access to 'root-only' facilities. It certainly prevents security holes. 2009/9/11 Rainer Gerhards : > 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 the new directive [2]. Consequently, this has been changed > to a "feature request" from rsyslog's POV. As such, the "patch" goes > into the recent devel (4.7.0). It is rsyslog policy never to add new > features to stable or beta versions. > > I would appreciate discussion on my view that the root cause is outside > of rsyslog. Discussion is especially important as I expect that the > work-around we now created will no longer work once rsyslog has new, > better privilege drop code (probably in the v5 or v6 timeframe). > > Thanks, > Rainer > > [1] http://bugzilla.adiscon.com/show_bug.cgi?id=150 > [2] http://www.rsyslog.com/doc-rsconf1_omfileforcechown.html > > -- > [karmic] Messages not being sent to system logs > https://bugs.launchpad.net/bugs/407862 > You received this bug notification because you are a direct subscriber > of the bug. > -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 the new directive [2]. Consequently, this has been changed to a "feature request" from rsyslog's POV. As such, the "patch" goes into the recent devel (4.7.0). It is rsyslog policy never to add new features to stable or beta versions. I would appreciate discussion on my view that the root cause is outside of rsyslog. Discussion is especially important as I expect that the work-around we now created will no longer work once rsyslog has new, better privilege drop code (probably in the v5 or v6 timeframe). Thanks, Rainer [1] http://bugzilla.adiscon.com/show_bug.cgi?id=150 [2] http://www.rsyslog.com/doc-rsconf1_omfileforcechown.html -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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: Always chown output files, since we may not be able to read them on a HUP otherwise. -- Michael TerryMon, 31 Aug 2009 14:58:50 -0400 ** Changed in: rsyslog (Ubuntu) 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [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 http://bugzilla.adiscon.com/show_bug.cgi?id=150 ** Also affects: rsyslog via http://bugzilla.adiscon.com/show_bug.cgi?id=150 Importance: Unknown Status: Unknown -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [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 : > 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. But yours may have been from sysklogd days? > > -- > [karmic] Messages not being sent to system logs > https://bugs.launchpad.net/bugs/407862 > You received this bug notification because you are a direct subscriber > of the bug. > -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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. But yours may have been from sysklogd days? -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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 * sudo /etc/init.d/rsyslog restart * plug in usb stick * sudo /etc/init.d/rsyslog reload * pull usb stick out I get the kernel messages after the restart but not the reload. Is your /var/log the same permissions as default? Mine is owned root:root mode 755 and the /var/log/syslog is owned root:adm with mode 640. Rsyslog is supposed to close all the files on reload, so if a syslog:syslog owned process can reopen a 640 mode file with root:adm ownership then the kernel probably has a security hole :-) This may be a thread sync problem. I'm on AMD 64 with 2 cores. Is your architecture similar? 2009/8/31 Michael Terry : > 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). -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 /var/log/lpr.log) * sudo /etc/init.d/rsyslog restart * sudo /etc/init.d/cups restart * sudo /etc/init.d/rsyslog reload * sudo /etc/init.d/cups reload And in the tail output, I saw (cupsd.conf problem is something unrelated, just good output to test rsyslog with): Aug 31 10:40:11 bongo rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="9805" x-info="http://www.rsyslog.com";] (re)start Aug 31 10:40:11 bongo rsyslogd: rsyslogd's groupid changed to 103 Aug 31 10:40:11 bongo rsyslogd: rsyslogd's userid changed to 102 Aug 31 10:41:32 bongo cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting! Aug 31 10:41:37 bongo rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="9805" x-info="http://www.rsyslog.com";] rsyslogd was HUPed, type 'lightweight'. Aug 31 10:41:39 bongo cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting! So that appears to be working! It could read it from the start, and it could still read it after a HUP. Then I tested kern.log: * tail -f /var/log/syslog * sudo /etc/init.d/rsyslog restart * plug in a usb stick * sudo /etc/init.d/rsyslog reload * pull usb stick out And I saw: Aug 31 10:50:32 bongo rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="10300" x-info="http://www.rsyslog.com";] (re)start Aug 31 10:50:32 bongo rsyslogd: rsyslogd's groupid changed to 103 Aug 31 10:50:32 bongo rsyslogd: rsyslogd's userid changed to 102 Aug 31 10:50:36 bongo kernel: [249915.148097] usb 2-2: new high speed USB device using ehci_hcd and address 40 ... Aug 31 10:50:49 bongo rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="10300" x-info="http://www.rsyslog.com";] rsyslogd was HUPed, type 'lightweight'. Aug 31 10:50:53 bongo kernel: [249932.212258] usb 2-2: USB disconnect, address 40 So it was also able to continue reading from kern.log after a reload. Can you give easy reproduction steps? ** Changed in: rsyslog (Ubuntu) Status: In Progress => Incomplete -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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 they all use different pidfile, init script names and process identifiers? Is anything tied that closely to rsyslog? Anything that does depend upon HUPing rsyslog should depend upon it or its virtual package shouldn't it? Or at the very least suggest/recommend it. 2009/8/17 Michael Terry : > 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 to HUP rsyslog for example?) > > As for disabling lightweight restarts via HUPs, I guess that's the same > question -- if we just ignore HUPs, will we break anything? > > -- > [karmic] Messages not being sent to system logs > https://bugs.launchpad.net/bugs/407862 > You received this bug notification because you are a direct subscriber > of the bug. > -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 to HUP rsyslog for example?) As for disabling lightweight restarts via HUPs, I guess that's the same question -- if we just ignore HUPs, will we break anything? -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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 log files. They are then reopened 'on demand' - but fail with 'permission denied.' The lightweight restart option needs to be disabled somehow - internally and via HUP. Either that or stop closing files in lightweight mode. The file access code is a bit messy and it looks hard to stop the file closes on HUP without breaking somehting else. Perhaps upstream has a better suggestion? I don't think the report is a 'wont fix' - we kinda need system log messages to get through. :) 2009/8/17 Michael Terry : > 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 restarting is just broken > with privilege dropping, then that's good to know. We just go back to > the previous init reloading and your original report would just be 'WONT > FIX' since we don't support manual HUPing? > > However, it surprises me that lightweight restart would be broken. As I > said, the code specifically chooses lightweight restarts when privileges > are dropped. I would think that means it would be safe. > > So Neil, with your original patch for 4.2.0-1ubuntu2, things weren't > working? I had tested them, but I think I only tested kernel messages, > which wouldn't be affected by the 'open as root, drop priv' issue since > the kernel messages are readable by the rsyslog user. > > -- > [karmic] Messages not being sent to system logs > https://bugs.launchpad.net/bugs/407862 > You received this bug notification because you are a direct subscriber > of the bug. > -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 restarting is just broken with privilege dropping, then that's good to know. We just go back to the previous init reloading and your original report would just be 'WONT FIX' since we don't support manual HUPing? However, it surprises me that lightweight restart would be broken. As I said, the code specifically chooses lightweight restarts when privileges are dropped. I would think that means it would be safe. So Neil, with your original patch for 4.2.0-1ubuntu2, things weren't working? I had tested them, but I think I only tested kernel messages, which wouldn't be affected by the 'open as root, drop priv' issue since the kernel messages are readable by the rsyslog user. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 back to a simple alias for restart. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 stops. -rw-r- 1 root adm 88 2009-08-16 08:39 kern.log -rw-r- 1 root adm 354 2009-08-16 08:39 syslog -rw-r- 1 root adm 354 2009-08-16 08:39 messages Plus the console has the wrong permissions. prw-r- 1 root adm 0 2009-08-16 08:47 /dev/xconsole And of course when you HUP the syslog daemon it reopens the files and gets permission denied. So we need to get the permissions sorted out - and figure out why rsyslog is able to open the log files are root. Which package does the initial create on /var/log? -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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:Ubuntu karmic (development branch) Release:9.10 Aug 14 14:17:38 jbs-lpia kernel: [ 15.636268]groups: 0-1 (__cpu_power = 2048) Aug 14 14:17:38 jbs-lpia rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="2362" x-info="http://www.rsyslog.com";] rsyslogd was HUPed, type 'lightweight'. I have to restart rsyslogd before messages start showing up in system logs again. -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 upgrade from sysklogd * debian/patches/deroot.patch: Don't allow using the klogctl function to read klog messages. Rather, allow /proc/kmsg or nothing, since we have special support for reading /proc/kmsg while unprivileged. [ Neil Wilson ] * debian/rsyslog.init: Set blocksize for dd (LP: #407862) and restore reload init argument to original lightweight reload -- Michael TerryThu, 13 Aug 2009 15:43:29 -0400 ** Branch linked: lp:ubuntu/karmic/rsyslog ** Changed in: rsyslog (Ubuntu) Status: In Progress => 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 /bin/dd -b -m -- if=/proc/kmsg of=$KMSG_PIPE The old klogd init.d file uses # shovel /proc/kmsg to pipe readable by klogd user start-stop-daemon --start --pidfile $kmsgpidfile --exec /bin/dd -b -m -- bs=1 if=/proc/kmsg of=$kmsgpipe Adding 'bs=1' to the rsyslog init.d file cures the lack of kernel logging. Patch attached which also implements HUP based reload for this daemon. ** Attachment added: "Fix blocksize and implement reload patch" http://launchpadlibrarian.net/30189297/set_blocksize_and_do_reload.patch -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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 very strange. 2009/8/10 Neil Wilson : > 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/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] Messages not being sent to system logs >> https://bugs.launchpad.net/bugs/407862 >> You received this bug notification because you are a direct subscriber >> of the bug. >> > > > > -- > Neil Wilson > -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 407862] Re: [karmic] Messages not being sent to system logs
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/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] Messages not being sent to system logs > https://bugs.launchpad.net/bugs/407862 > You received this bug notification because you are a direct subscriber > of the bug. > -- Neil Wilson -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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] 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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] 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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
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 correct one. Good luck on getting it fixed! ** Package changed: ubuntu => rsyslog (Ubuntu) -- [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 https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 407862] Re: [karmic] Messages not being sent to system logs
** 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 mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
