On Sat, Nov 13, 2010 at 04:11:39PM +0100, Josip Rodin wrote: > On Tue, Nov 02, 2010 at 07:09:26PM +0100, Moritz Muehlenhoff wrote: > > On Mon, Oct 25, 2010 at 12:35:38PM +0200, Alan DeKok wrote: > > > Josip Rodin wrote: > > > > [For Alan: I requested for FreeRADIUS 2.1.10 to replace 2.1.9 in the > > > > future > > > > Debian 6.0 release; the former came too late in our process to be > > > > accepted > > > > automatically.] > > > > > > OK. > > > > > > >> This, from main/events.c, looks obviously wrong, however: > > > >> > > > >> + home->zombie_period_start.tv_sec = home->last_packet; > > > >> + home->zombie_period_start.tv_sec = USEC / 2; > > > >> > > > >> Presumably the second tv_sec should be tv_usec. > > > > > > Yes, ouch. > > > > > > > Yeah, that sounds like it to me, too. That change came in this commit > > > > http://github.com/alandekok/freeradius-server/commit/f8bcc0fe > > > > which actually probably fixed a fatal crash (the assert call removed > > > > because "Don't check home->ev due to race conditions."), so that's still > > > > probably better than one randomized zombie period start (which can > > > > get reset and/or ignored soon enough anyway) which is why nobody else > > > > noticed. > > > > > > > > Alan, is this correct? > > > > > > Yes. I'll commit a fix. > > > > Josip, Alan's fix has been commited: > > http://github.com/alandekok/freeradius-server/commit/7b7dff7724721f8af5fd163f2292d427a869992d > > > > Could you upload a fixed version? > > I'll get to it today. It'll also fix another logging regression that got > reported in the meantime.
Argh, I just read the update, so I guess it's best to clarify, by pasting the changelog entries of the new packages I've been testing and hashing out for a while now: * The zombie period start time variable mistakenly got set to a random value because of an upstream typo. Cherry-picked upstream commit 7b7dff7724721f8af5fd163f2292d427a869992d into a Debian patch, requested for squeeze in #600465. * Since 2.1.9, the daemon stopped reopening the default radius.log file constantly, which means the default logrotate setup breaks the default logging. D'oh. We now have to send SIGHUP to the daemon as a postrotate action, which makes it reopen log files and continue normally. * Added delaycompress to the logrotate options, just to be on the safe side. * Added a reload action into the init script accordingly, so that the right pidfile is picked up (one that can be overridden by the admin in /etc/default/freeradius, available since the last release). * Called reload from the postrotate section, closes: #602815. * However, the latter signal also makes the server re-read configuration files, but unlike the initial server start, this all happens under the unprivileged user. That in turn means that if by any chance there is any part of FR configuration that happens not to be readable by group freerad (or whatever non-default is configured), the reload will fail, effectively silently, as the log has been moved away. Gah. So we have to make an effort to ensure that the configuration files are still readable by that user, otherwise the reload fails and the aforementioned bug is not fixed. The files seem to revert to root:root upon conffile actions, at least that's what happened to me and I think that was the cause. So, on upgrade, try to re-apply the dpkg-statoverrides on our /etc/freeradius/* stuff, whatever they are, under the assumption they will let the freerad group read config files as is the initial setup. (I wish dpkg-statoverride --update $file just did the right thing, but it doesn't, so there's a new local function that does that.) * While doing the latter, noticed that we were checking for directories in dpkg-statoverride --list output with trailing slashes, but they get output without it, so it was a no-op. Fixed the check by removing the trailing slashes. Also then noticed that we were grepping --list output, but it takes an optional glob pattern, so saved us that pointless grep fork by using that facility, just as described in the policy manual. * force-reload switches from restart to reload, per policy 9.3.2. * lenny backport needed also libltdl-dev (2.2.x) to build properly, rather than libltdl3-dev, which is obsolete and doesn't make sense anyway. Oh, how I wish 2.1.8 had been left in squeeze as I imagined it originally... if only that initial crash was filed as an RC bug in time to stop the propagation. :/k -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org