misc/166440: fix depends
>Number: 166440
>Category: misc
>Synopsis: fix depends
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 27 11:40:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Vasiliy P. Melnik
>Release:9.0-RELEASE
>Organization:
na
>Environment:
FreeBSD monkey.home 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sat Jan 7 02:31:55 EET
2012 r...@monkey.home:/usr/obj/usr/src/sys/monkey i386
>Description:
fix depends
>How-To-Repeat:
>Fix:
Diff mode was set to CVS, but there's no CVS subdirectory
Trying /usr/ports ... found
Warning: current directory name differs from Makefile header:
ldap-account-manager !=
===> Generating patch
===> Viewing diff with more
diff -ruN --exclude=CVS /usr/ports/sysutils/ldap-account-manager/Makefile
./Makefile
--- /usr/ports/sysutils/ldap-account-manager/Makefile 2012-03-26
21:54:15.0 +0300
+++ ./Makefile 2012-03-27 14:27:44.0 +0300
@@ -7,6 +7,7 @@
PORTNAME= ldap-account-manager
PORTVERSION= 3.7
+PORTREVISION= 1
CATEGORIES=sysutils www
MASTER_SITES= SF/${SHORTNAME}/LAM/${PORTVERSION}
@@ -21,7 +22,7 @@
NO_BUILD= yes
USE_GETTEXT= yes
USE_PERL5= yes
-USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json
+USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json zip
WANT_PHP_WEB= yes
DEFAULT_PHP_VER= 5
===> Done
Patch attached with submission follows:
Diff mode was set to CVS, but there's no CVS subdirectory
Trying /usr/ports ... found
Warning: current directory name differs from Makefile header:
ldap-account-manager !=
===> Generating patch
===> Viewing diff with more
diff -ruN --exclude=CVS /usr/ports/sysutils/ldap-account-manager/Makefile
./Makefile
--- /usr/ports/sysutils/ldap-account-manager/Makefile 2012-03-26
21:54:15.0 +0300
+++ ./Makefile 2012-03-27 14:27:44.0 +0300
@@ -7,6 +7,7 @@
PORTNAME= ldap-account-manager
PORTVERSION= 3.7
+PORTREVISION= 1
CATEGORIES=sysutils www
MASTER_SITES= SF/${SHORTNAME}/LAM/${PORTVERSION}
@@ -21,7 +22,7 @@
NO_BUILD= yes
USE_GETTEXT= yes
USE_PERL5= yes
-USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json
+USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json zip
WANT_PHP_WEB= yes
DEFAULT_PHP_VER= 5
===> Done
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/166440: sysutils/ldap-account-manager: fix depends
Old Synopsis: fix depends New Synopsis: sysutils/ldap-account-manager: fix depends Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 27 11:43:00 UTC 2012 Responsible-Changed-Why: ports PR http://www.freebsd.org/cgi/query-pr.cgi?pr=166440 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/166441: bktr.ko does not exist
>Number: 166441 >Category: kern >Synopsis: bktr.ko does not exist >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 27 11:50:07 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Joe Stroud >Release:8.2 >Organization: Cubesoft Communications, Inc. >Environment: FreeBSD elkab 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sun Dec 18 03:36:49 UTC 2011 root@elkab:/usr/obj/usr/src/sys/GENERIC amd64 >Description: There is no kernel support for Brooktree 8x8 capture devices, although the "bktr" manpage exists, and the "Hardware Notes" indicate support for such devices. There is speculation about that it was removed because it is unmaintained or that a commit clobbered the code. Nor will bktr compile during a custom kernel build. Where did it go? http://www.freebsd.org/releases/8.2R/hardware.html#CAMERA ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.2-RELEASE/kernels/generic.mtree >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)
The following reply was made to PR kern/166340; it has been noted by GNATS. From: Christian Esken To: bug-follo...@freebsd.org Cc: Konstantin Belousov , a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Tue, 27 Mar 2012 17:30:27 +0200 --=-0r5Lk3awdhxqDAjyo6lR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Konstantin Belousov wrote: > Thank you for the data. Semi-obviously, the callout_stop() call in > sleepq_check_timeout() have to return 0, otherwise we would not call > mi_switch() there. But I do not see how this can happen, because > the callout state, printed from kgdb, still indicates that callout > is pending. Callout cannot be reset while in sleepq code. > > So there are two possible routes to go forward: preferrable is for > you to extract the self-contained C program that would illustrate > the issue and send this sample to me. Second is to recompile your > kernel with INVARIANTS/WITNESS and possibly KTR and see what happen. I repeated the test with INVARIANTS/WITNESS and KTR compiled in (actually WITNESS was already included during the last test). I ran KTR with nothing filtered out, and formatted the dump with "ktrdump -cftH -i ktr.out". The whole log is excessive (1GB), so I have extrated two short sections (see attachment). The first section shows the last action of the application, namely a succselful sendto() to a TCP socket, and then waiting for an answer via recvfrom(). The second section illustrates the lock/unlock sequence of the sleep mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK. This time the signal status is different. We have a pending signal: USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN nobody 9163 1 4000 80005006 79f880100 D- Looks like SIGPROF (27). Just wondering where it comes from. By the way: I evaluated the possibility to implement a standalone test case. It would be extremely complicated, as the issue is while writing to the socket, and thus it would require extracting the socket code from the Thrift procect (http://thrift.apache.org/ ). Christian --=-0r5Lk3awdhxqDAjyo6lR Content-Disposition: attachment; filename="wait_recvfrom.txt" Content-Type: text/plain; name="wait_recvfrom.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Last actions of pid 9163 (serelog): sendto() succesful recvfrom() waits for data, uisng sleep mutex 7463551 55644560314159 /usr/src/sys/kern/kern_sx.c:352 0xfe01972b2480 XUNLOCK (sx) so_snd_sx 0xfe0344b07490 r = 0 at /usr/src/sys/kern/uipc_sockbuf.c:160 7463552 15644560316280 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463553 55644560319107 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0x77d 0x77d 7463557 55644560329931 /usr/src/sys/kern/subr_trap.c:101 0xfe01972b2480 userret: thread 0xfe01972b2480 (pid 9163, serelog) 7463559 45644560336733 /usr/src/sys/vm/uma_core.c:1975 0xfe0008364480 uma_zalloc_arg thread 8364480 zone mbuf flags 1 7463561 65644560344432 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972ae900 syscall: td=0xfe01972ae900 pid 9767 gettimeofday (0x7fffac40, 0, 0x43fd18) 7463562 15644560347528 /usr/src/sys/kern/kern_mutex.c:222 0xfe01bcf4d000 UNLOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1796 7463563 65644560348788 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972ae900 syscall: p=0xfe01bc1ad000 error=0 return 0 0x43fd18 7463564 55644560351047 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:187 0xfe01972b2480 syscall sendto exit thread 0xfe01972b2480 pid 9163 proc serelog 7463565 15644560354848 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe02f7525700 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463567 55644560360499 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972b2480 syscall: td=0xfe01972b2480 pid 9163 gettimeofday (0x7fffc600, 0, 0x ) 7463568 25644560364617 /usr/src/sys/kern/kern_mutex.c:356 0xfe004e384000 _mtx_lock_sleep: taskqueue contested (lock=0xfe0008375000) at /usr/src/sys/kern/kern_mutex.c :147 7463569 55644560366559 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0 0x 7463570 35644560369374 /usr/src/sys/kern/kern_mutex.c:222 0xfe0008375000 UNLOCK (sleep mutex) taskqueue 0xfe004e2604b0 r = 0 at /usr/src/sys/kern/subr_taskqueu
Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)
The following reply was made to PR kern/166340; it has been noted by GNATS. From: Christian Esken To: bug-follo...@freebsd.org Cc: Konstantin Belousov , a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Tue, 27 Mar 2012 17:30:48 +0200 --=-3sl93MaMYlu/dkvvUUBe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Konstantin Belousov wrote: > Thank you for the data. Semi-obviously, the callout_stop() call in > sleepq_check_timeout() have to return 0, otherwise we would not call > mi_switch() there. But I do not see how this can happen, because > the callout state, printed from kgdb, still indicates that callout > is pending. Callout cannot be reset while in sleepq code. > > So there are two possible routes to go forward: preferrable is for > you to extract the self-contained C program that would illustrate > the issue and send this sample to me. Second is to recompile your > kernel with INVARIANTS/WITNESS and possibly KTR and see what happen. I repeated the test with INVARIANTS/WITNESS and KTR compiled in (actually WITNESS was already included during the last test). I ran KTR with nothing filtered out, and formatted the dump with "ktrdump -cftH -i ktr.out". The whole log is excessive (1GB), so I have extrated two short sections (see attachment). The first section shows the last action of the application, namely a succselful sendto() to a TCP socket, and then waiting for an answer via recvfrom(). The second section illustrates the lock/unlock sequence of the sleep mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK. This time the signal status is different. We have a pending signal: USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN nobody 9163 1 4000 80005006 79f880100 D- Looks like SIGPROF (27). Just wondering where it comes from. By the way: I evaluated the possibility to implement a standalone test case. It would be extremely complicated, as the issue is while writing to the socket, and thus it would require extracting the socket code from the Thrift procect (http://thrift.apache.org/ ). Christian --=-3sl93MaMYlu/dkvvUUBe Content-Disposition: attachment; filename="wait_recvfrom.txt" Content-Type: text/plain; name="wait_recvfrom.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Last actions of pid 9163 (serelog): sendto() succesful recvfrom() waits for data, uisng sleep mutex 7463551 55644560314159 /usr/src/sys/kern/kern_sx.c:352 0xfe01972b2480 XUNLOCK (sx) so_snd_sx 0xfe0344b07490 r = 0 at /usr/src/sys/kern/uipc_sockbuf.c:160 7463552 15644560316280 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463553 55644560319107 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0x77d 0x77d 7463557 55644560329931 /usr/src/sys/kern/subr_trap.c:101 0xfe01972b2480 userret: thread 0xfe01972b2480 (pid 9163, serelog) 7463559 45644560336733 /usr/src/sys/vm/uma_core.c:1975 0xfe0008364480 uma_zalloc_arg thread 8364480 zone mbuf flags 1 7463561 65644560344432 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972ae900 syscall: td=0xfe01972ae900 pid 9767 gettimeofday (0x7fffac40, 0, 0x43fd18) 7463562 15644560347528 /usr/src/sys/kern/kern_mutex.c:222 0xfe01bcf4d000 UNLOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1796 7463563 65644560348788 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972ae900 syscall: p=0xfe01bc1ad000 error=0 return 0 0x43fd18 7463564 55644560351047 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:187 0xfe01972b2480 syscall sendto exit thread 0xfe01972b2480 pid 9163 proc serelog 7463565 15644560354848 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe02f7525700 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463567 55644560360499 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972b2480 syscall: td=0xfe01972b2480 pid 9163 gettimeofday (0x7fffc600, 0, 0x ) 7463568 25644560364617 /usr/src/sys/kern/kern_mutex.c:356 0xfe004e384000 _mtx_lock_sleep: taskqueue contested (lock=0xfe0008375000) at /usr/src/sys/kern/kern_mutex.c :147 7463569 55644560366559 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0 0x 7463570 35644560369374 /usr/src/sys/kern/kern_mutex.c:222 0xfe0008375000 UNLOCK (sleep mutex) taskqueue 0xfe004e2604b0 r = 0 at /usr/src/sys/kern/subr_taskqu
Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)
The following reply was made to PR kern/166340; it has been noted by GNATS. From: Konstantin Belousov To: Christian Esken Cc: bug-follo...@freebsd.org, a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Tue, 27 Mar 2012 20:46:26 +0300 --KldKAdupQSLqpq2E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 27, 2012 at 05:30:48PM +0200, Christian Esken wrote: > Konstantin Belousov wrote: > > Thank you for the data. Semi-obviously, the callout_stop() call in > > sleepq_check_timeout() have to return 0, otherwise we would not call > > mi_switch() there. But I do not see how this can happen, because > > the callout state, printed from kgdb, still indicates that callout > > is pending. Callout cannot be reset while in sleepq code. > >=20 > > So there are two possible routes to go forward: preferrable is for > > you to extract the self-contained C program that would illustrate > > the issue and send this sample to me. Second is to recompile your > > kernel with INVARIANTS/WITNESS and possibly KTR and see what happen. >=20 > I repeated the test with INVARIANTS/WITNESS and KTR compiled in > (actually WITNESS was already included during the last test). >=20 > I ran KTR with nothing filtered out, and formatted the dump with > "ktrdump -cftH -i ktr.out". The whole log is excessive (1GB), so > I have extrated two short sections (see attachment). >=20 > The first section shows the last action of the application, namely a > succselful sendto() to a TCP socket, and then waiting for an answer via > recvfrom(). > The second section illustrates the lock/unlock sequence of the sleep > mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK. >=20 > This time the signal status is different. We have a pending signal: > USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN > nobody 9163 1 4000 80005006 79f880100 D-=20 >=20 > Looks like SIGPROF (27). Just wondering where it comes from. >=20 This is irrelevant, and probably red-herring. The issue there is failing callout_stop() while callout seems to be still pending. Also, mask 0x4000 of the pending signals indicates that SIGTERM is pending, not SIGPROF. I probably want the data from your ktr dump, either all entries for the stuck process and all entries for facility CALLOUT, or just the whole dump. Last entries of your log shred do not make much sense, since the process must enter _sleep() function which logs this fact right after locking sleepq. But log ends on so_rcv mutex lock. Please, when collecting the data, collect the whole set, i.e. include procstat -kk output together with the ktr, as well as kgdb output, so that I can be sure that we chasing one, and not N bugs. --KldKAdupQSLqpq2E Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9x/PIACgkQC3+MBN1Mb4hbeACfYyUTEE5GV/SeDO4fNf4ErfHY 27oAoIGj2TMOBtQRi5P+q/v+nrKOFhFb =0tFs -END PGP SIGNATURE- --KldKAdupQSLqpq2E-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/166448: [patch] newsyslog -t fails to find previous rotated log
>Number: 166448
>Category: bin
>Synopsis: [patch] newsyslog -t fails to find previous rotated log
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 27 18:10:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.3-PRERELEASE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.pp.ru 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #19: Tue
Mar 20 03:24:04 NOVT 2012
r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV amd64
>Description:
newsyslog.conf(5) has "when" field instructing newsyslog to find
previous rotated copy of log and look if it is older than "when" hours.
newsyslog always looks for "file.0" and this is wrong when -t flag is
used.
>How-To-Repeat:
Use newsyslog -t and non-zero value in "when" field:
/var/log/cron 600 3 * 8@T C
This should rotate log three times a day starting from midnight.
>Fix:
--- usr.sbin/newsyslog/newsyslog.c.orig 2012-03-27 22:43:06.0 +0700
+++ usr.sbin/newsyslog/newsyslog.c 2012-03-28 00:53:21.0 +0700
@@ -2206,6 +2206,77 @@
return (kbytes(dbtob(sb.st_blocks)));
}
+/* Return the age of previous old log file, when using time based filenames. */
+static time_t
+find_oldest_timelog(const char *dir, const char *logfname)
+{
+ struct stat sb;
+ int c, valid;
+ size_t logfname_len;
+ struct tm tm;
+ time_t oldt;
+ struct dirent *dp;
+ DIR *dirp;
+ char *s;
+
+ if ((dirp = opendir(dir)) == NULL)
+ err(1, "Cannot open log directory '%s'", dir);
+
+ oldt = -1;
+ logfname_len = strlen(logfname);
+ while ((dp = readdir(dirp)) != NULL) {
+ if (dp->d_type != DT_REG)
+ continue;
+ /* Ignore everything but files with our logfile prefix */
+ if (strncmp(dp->d_name, logfname, logfname_len) != 0)
+ continue;
+ /* Ignore the actual non-rotated logfile */
+ if (dp->d_namlen == logfname_len)
+ continue;
+ /*
+* Make sure we have found a logfile, so the
+* postfix is valid, IE format is: '.(.[bg]z)?'.
+*/
+ if (dp->d_name[logfname_len] != '.') {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name,
+ &dp->d_name[logfname_len]);
+ continue;
+ }
+ if ((s = strptime(&dp->d_name[logfname_len + 1],
+ timefnamefmt, &tm)) == NULL) {
+ if (verbose)
+ printf("Ignoring %s which does not "
+ "match time format\n", dp->d_name);
+ continue;
+ }
+
+ valid = 0;
+ c = 0;
+ while (!valid && c < COMPRESS_TYPES)
+ if (strcmp(s, compress_type[c++].suffix) == 0)
+ valid = 1;
+
+ if (valid != 1) {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name, s);
+ continue;
+ }
+ if (stat(dp->d_name, &sb) < 0)
+ err(1, "Cannot stat '%s'", dp->d_name);
+
+ /* We have found more recent old logfile */
+ if (oldt < sb.st_mtime)
+ oldt = sb.st_mtime;
+ }
+ closedir(dirp);
+
+ /* Return -1 if nothing found */
+ return oldt;
+}
+
/* Return the age of old log file (file.0) */
static int
age_old_log(char *file)
@@ -2241,6 +2312,17 @@
(void) strlcpy(tmp, file, sizeof(tmp));
}
+ if (timefnamefmt != NULL) {
+char *bd;
+time_t t;
+
+ if ((bd = dirname(tmp)) == NULL)
+err(1, "'%s'", tmp);
+if ((t = find_oldest_timelog(bd, basename(tmp))) == -1)
+return (-1);
+return ((int)(ptimeget_secs(timenow) - t + 1800) / 3600);
+ }
+
strlcat(tmp, ".0", sizeof(tmp));
logfile_suffix = get_logfile_suffix(tmp);
if (logfile_suffix == NULL)
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.
Re: bin/166448: [patch] newsyslog -t fails to find previous rotated log
The following reply was made to PR bin/166448; it has been noted by GNATS.
From: Eugene Grosbein
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/166448: [patch] newsyslog -t fails to find previous rotated
log
Date: Wed, 28 Mar 2012 02:10:50 +0700
Sorry, I've sent buggy patch (does stat() on wrong filename). Here is
corrected one.
--- usr.sbin/newsyslog/newsyslog.c.orig2012-02-13 17:02:03.0
+0400
+++ usr.sbin/newsyslog/newsyslog.c 2012-03-27 22:53:46.0 +0400
@@ -2206,6 +2206,79 @@
return (kbytes(dbtob(sb.st_blocks)));
}
+/* Return the age of previous old log file, when using time based filenames.
*/
+static time_t
+find_oldest_timelog(const char *dir, const char *logfname)
+{
+ struct stat sb;
+ int c, valid;
+ size_t logfname_len;
+ struct tm tm;
+ time_t oldt;
+ struct dirent *dp;
+ DIR *dirp;
+ char *s;
+ char tmp[MAXPATHLEN];
+
+ if ((dirp = opendir(dir)) == NULL)
+ err(1, "Cannot open log directory '%s'", dir);
+
+ oldt = -1;
+ logfname_len = strlen(logfname);
+ while ((dp = readdir(dirp)) != NULL) {
+ if (dp->d_type != DT_REG)
+ continue;
+ /* Ignore everything but files with our logfile prefix */
+ if (strncmp(dp->d_name, logfname, logfname_len) != 0)
+ continue;
+ /* Ignore the actual non-rotated logfile */
+ if (dp->d_namlen == logfname_len)
+ continue;
+ /*
+ * Make sure we have found a logfile, so the
+ * postfix is valid, IE format is: '.(.[bg]z)?'.
+ */
+ if (dp->d_name[logfname_len] != '.') {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name,
+ &dp->d_name[logfname_len]);
+ continue;
+ }
+ if ((s = strptime(&dp->d_name[logfname_len + 1],
+ timefnamefmt, &tm)) == NULL) {
+ if (verbose)
+ printf("Ignoring %s which does not "
+ "match time format\n", dp->d_name);
+ continue;
+ }
+
+ valid = 0;
+ c = 0;
+ while (!valid && c < COMPRESS_TYPES)
+ if (strcmp(s, compress_type[c++].suffix) == 0)
+ valid = 1;
+
+ if (valid != 1) {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name, s);
+ continue;
+ }
+ snprintf(tmp, sizeof(tmp), "%s/%s", dir, dp->d_name);
+ if (stat(tmp, &sb) < 0)
+ err(1, "Cannot stat '%s'", tmp);
+
+ /* We have found more recent old logfile */
+ if (oldt < sb.st_mtime)
+ oldt = sb.st_mtime;
+ }
+ closedir(dirp);
+
+ /* Return -1 if nothing found */
+ return oldt;
+}
+
/* Return the age of old log file (file.0) */
static int
age_old_log(char *file)
@@ -2241,6 +2314,17 @@
(void) strlcpy(tmp, file, sizeof(tmp));
}
+ if (timefnamefmt != NULL) {
+char *bd;
+time_t t;
+
+ if ((bd = dirname(tmp)) == NULL)
+err(1, "'%s'", tmp);
+if ((t = find_oldest_timelog(bd, basename(tmp))) == -1)
+return (-1);
+return ((int)(ptimeget_secs(timenow) - t + 1800) / 3600);
+ }
+
strlcat(tmp, ".0", sizeof(tmp));
logfile_suffix = get_logfile_suffix(tmp);
if (logfile_suffix == NULL)
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/166458: bind() incorrectly interprets SO_REUSEADDR option as also implying SO_REUSEPORT on FreeBSD
>Number: 166458 >Category: kern >Synopsis: bind() incorrectly interprets SO_REUSEADDR option as also >implying SO_REUSEPORT on FreeBSD >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 28 01:00:25 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Sean Bruno >Release:9.0 >Organization: Yahoo! Inc >Environment: FreeBSD x 9.0-RELEASE FreeBSD 9.0-RELEASE #3: Tue Dec 27 14:14:29 PST 2011 r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC amd64 >Description: ... seems to be a bug in FreeBSD when specifying port number 0 in the socket address passed to the bind system call in order to let the kernel select a free port number. The semantics of SO_REUSEADDR is inconsistently implemented on FreeBSD. FreeBSD 4 jail environment (on a FreeBSD 4 host): dev-tegge:~$ ./bindbug serversock addr is 10.76.250.174:40328 dup bind: Address already in use This error was expected, tried to bind to used addr/port dup2 bind: Address already in use This error was expected, tried to bind to used port without SO_REUSEPORT autosock addr is 10.76.250.174:40328 bug triggered, port number conflict on sockets without SO_REUSEPORT listen succeded after implicitly overlapping port bind FreeBSD 6 host enironment: tegge-store1:~:$ ./bindbug serversock addr is 127.0.0.1:59073 dup bind: Address already in use This error was expected, tried to bind to used addr/port BUG: binding duplicate socket to server port succeeded dup2sock addr is 0.0.0.0:59073 overlapping explicit bind to same port number succeeded without SO_REUSEPORT listen succeeded after explicitly overlapping port bind autosock addr is 0.0.0.0:59073 bug triggered, port number conflict on sockets without SO_REUSEPORT listen succeded after implicitly overlapping port bind RHEL4 host environment: [tegge@dell-bl1s3 ~]$ time ./bindbug serversock addr is 127.0.0.1:43270 dup bind: Address already in use This error was expected, tried to bind to used addr/port dup2 bind: Address already in use This error was expected, tried to bind to used port without SO_REUSEPORT bug not triggered after 16777216 iterations real1m12.753s user0m4.695s sys 1m8.037s >How-To-Repeat: Use test code that is attached, compile and run on a fbsd box vs a linux box. test case is at http://people.freebsd.org/~sbruno/bind_test.c >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/166459: other id for atkbdc
>Number: 166459
>Category: kern
>Synopsis: other id for atkbdc
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: update
>Submitter-Id: current-users
>Arrival-Date: Wed Mar 28 01:40:08 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Kaho Toshikazu
>Release:10-CURRENT
>Organization:
>Environment:
FreeBSD catsidhe.pf2.ed.niigata-u.ac.jp 10.0-CURRENT FreeBSD 10.0-CURRENT #4
r233525M: Tue Mar 27 12:48:27 UTC 2012
k...@pf2.ed.niigata-u.ac.jp:/usr/obj/usr/src/sys/SOIL i386
>Description:
atkbdc_isa.c dosen't have a KBC id which is reported from acpi table on some
machines, and PS2 keyboard and mouse are not probed/attached.
`acpidump -dt` showed about "KBC" is :
Device (KBC)
{
Name (R101, 0x0303D041)
Name (R106, 0x2003D041)
Method (_HID, 0, NotSerialized)
{
If (SIDF)
{
Return (R101)
}
Else
{
Return (R106)
}
}
>How-To-Repeat:
Boot FreeBSD 9/10 on some machines, PS2 keyboard and mouse do not do any jobs.
Fujitsu FMV-BIBLO LOOX T70S/V and Sharp PC-CV50 have the problem here, and
google shows some machines have similar acpi table.
>Fix:
Add id.
Index: sys/dev/atkbdc/atkbdc_isa.c
===
--- sys/dev/atkbdc/atkbdc_isa.c (revision 233525)
+++ sys/dev/atkbdc/atkbdc_isa.c (working copy)
@@ -87,6 +87,7 @@
static struct isa_pnp_id atkbdc_ids[] = {
{ 0x0303d041, "Keyboard controller (i8042)" }, /* PNP0303 */
+ { 0x2003d041, "Keyboard controller (i8042)" }, /* PNP2003 */
{ 0 }
};
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
conf/166460: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic scripts
>Number: 166460
>Category: conf
>Synopsis: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic
>scripts
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Mar 28 02:00:22 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Jeremy Chadwick
>Release:FreeBSD 8.2-STABLE amd64
>Organization:
>Environment:
System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 10
17:43:50 PST 2012
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
>Description:
First: not sure if I got the right Category. This might be kern
or misc.
Issue was discussed on freebsd-stable here:
http://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066962.html
http://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066978.html (root
cause)
When ipfilter is removed from the system via src.conf knob
WITHOUT_IPFILTER, periodic scripts which rely on ipfstat(8) do not
get removed during "make delete-old". This results in errors
like the following during "periodic security" phase:
ipfstat: not found
Root cause appears to be lack of OLD_FILES entries for the two
periodic scripts in question. Patch should fix this. Only tested on
RELENG_8; other adjustments may be needed for RELENG_7 or RELENG_9.
Note that etc/periodic/security/610.ipf6denied is a tricky one: it's
both
IPFILTER-related *and* IPv6. So I'm not sure if this removal should go
under the MK_IPFILTER check or the MK_INET6 check.
>How-To-Repeat:
1. Add WITHOUT_IPFILTER=true to /etc/src.conf
2. Rebuild system (world/kernel), mergemaster, etc... -- the usual
3. Run "periodic security" and watch for "ipfstat: not found" messages
>Fix:
Apply below patch:
--- src/tools/build/mk/OptionalObsoleteFiles.inc.orig 2010-11-22
17:39:30.0 -0800
+++ src/tools/build/mk/OptionalObsoleteFiles.inc2012-03-27
18:56:15.167308202 -0700
@@ -605,6 +605,8 @@
OLD_FILES+=usr/share/man/man8/ipmon.8.gz
OLD_FILES+=usr/share/man/man8/ipnat.8.gz
OLD_FILES+=usr/share/man/man8/ippool.8.gz
+OLD_FILES+=etc/periodic/security/510.ipfdenied
+OLD_FILES+=etc/periodic/security/610.ipf6denied
.endif
.if ${MK_IPX} == no
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: conf/166460: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic scripts
Synopsis: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic scripts Responsible-Changed-From-To: freebsd-bugs->eadler Responsible-Changed-By: eadler Responsible-Changed-When: Wed Mar 28 02:41:43 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=166460 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/166462: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state
>Number: 166462 >Category: kern >Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't >honor the MASTER/BACKUP state >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 28 05:40:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.2-RELEASE >Organization: RealService LLC >Environment: FreeBSD moscow-omega 8.2-RELEASE FreeBSD 8.2-RELEASE #5: Sat Mar 10 14:15:00 MSK 2012 emz@moscow-omega:/usr/obj/usr/src/sys/MOSCOW amd64 >Description: When using a HA system of two nodes for corporate VPN I encountered a problem: Imagine node A and B share the same public ip address on their carp(4) interface. Imagine A and B have a gre(4) interface, and its tunnel source address is the carp(4) address. Imagine there is an ospf daemon running on those gre(4) interfaces. Then the OSPF neiborship will be constantly reestablished, because A and B will interfere with OSPF sessions of each other. This happens because both nodes will send a HELO packet, and the backup node isn't honoring its BACKUP state properly. >How-To-Repeat: Build a setup mentioned above. Use OSPF or just try to send icmp packets via the tunnel from the BACKUP node. >Fix: Use IPSEC with 'required' policies. This will prevent the backup node from establishing SA, thus preventing the tunnel from working. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/166462: [gre] gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state
Old Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state New Synopsis: [gre] gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 28 05:58:53 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166462 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
