dhclient script adjustments

[Jason Hellenthal]

After recent merges to stable/8 I am now seeing errors on bootup of
the following for three interfaces that will never see the light of
DHCP. ?

/etc/rc.d/dhclient: ERROR: 'dc1' is not a DHCP-enabled interface

Can someone please revert these changes or some other action. ?

-- 
;s =;


pgpxhgHXGR3Ek.pgp
Description: PGP signature

Re: 6.2-Release ..ish.. CF + ata == freeze?

[Jason Hellenthal]

On Mon, Feb 13, 2012 at 08:43:08PM -0800, john fleming wrote:
> Just thought i would post over here as i'm not getting a warm fuzzy from 
> checkpoint about being able to find the root cause of an issue. I have a 
> large install base of IPSO checkpoint firewalls, which are based on FreeBSD 
> 6.2. I've had 3 firewalls hang basically the same way, with something that 
> looks like a filesystem issue or an issue with a CF card. 
>  
> Does anyone happen to know of any bugs (i've been looking around) that could 
> cause something like that? Granted, it could be a batch of bad CF cards, but 
> its odd that i'm seeing the same thing on 3 different boxes and once rebooted 
> they seem ok.
>  
> Also is it possible to get useful info form the atacontroller when things go 
> south like this from the ddb prompt?
>  
> This is what shows in show msgbuf
> ad0: timeout waiting to issue command
> ad0: error issuing WRITE command
> ad0: timeout waiting to issue command
> ad0: error issuing WRITE command
> ad0: timeout waiting to issue command
> ad0: error issuing WRITE command
> ad0: timeout waiting to issue command
> ad0: error issuing WRITE command
> g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 
> g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 
> g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5
>  g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 
> g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 
>  
> ad0: 1882MB  at ata0-master PIO4
> atapci0:  port 
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff 
> at device 31.1 on pci0
> ata0:  on atapci0
> ata1:  on atapci0
> atapci1:  port 
> 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq 15 
> at device 31.2 on pci0
> ata2:  on atapci1
> ata3:  on atapci1ad0s4h is basically a r/w ufs partition on 
> the box where almost anything that needs to be written goes.
> trace
> Tracing pid 1101 tid 100043 td 0x656d8460
> kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b
> siointr1(64ba1400) at siointr1+0xf0
> siointr(64ba1400) at siointr+0x38
> intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at 
> intr_execute_handler+0x61
> intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at 
> intr_execute_handlers+0x40
> atpic_handle_intr(4) at atpic_handle_intr+0x96
> Xatpic_intr4() at Xatpic_intr4+0x20
> --- interrupt, eip = 0x606044af, esp = 0xf0a4ab48, ebp = 0xf0a4ab5c ---
> lockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f
> getdirtybuf(e14569a4,60a405e4,1) at getdirtybuf+0x2e2
> flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30
> flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf
> softdep_sync_metadata(65964618) at softdep_sync_metadata+0x61
> ffs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2
> ffs_fsync(f0a4ac74) at ffs_fsync+0x12
> VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38
> fsync(656d8460,f0a4acb4) at fsync+0x170
> syscall(805003b,806003b,5fbf003b,805,288be450,...) at syscall+0x2ee
> Xint0x80_syscall() at Xint0x80_syscall+0x1f

This looks to be a problem with softupdates and CF cards. Can you get
this to repeat on a brand new (good) card ?

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 6.2-Release ..ish.. CF + ata == freeze?

[Jason Hellenthal]

On Mon, Feb 13, 2012 at 11:38:06PM -0600, Adam Vande More wrote:
> On Mon, Feb 13, 2012 at 10:43 PM, john fleming wrote:
> 
> > Just thought i would post over here as i'm not getting a warm fuzzy from
> > checkpoint about being able to find the root cause of an issue. I have a
> > large install base of IPSO checkpoint firewalls, which are based on FreeBSD
> > 6.2. I've had 3 firewalls hang basically the same way, with something that
> > looks like a filesystem issue or an issue with a CF card.
> >
> 
> There was a thread just the other day mentioned lockup problems with DMA
> and CF cards. Disabling DMA or reducing the mode helped.  Not sure if
> applicable to that old of FreeBSD version.
> 

I seen that thread. Doubt it is related to his issue since he is running
6.2. And besides his dmesg proves otherwise.

ad0: 1882MB  at ata0-master PIO4

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: dhclient script adjustments

[Jason Hellenthal]

Anyone ?

On Sat, Feb 11, 2012 at 01:58:57AM -0500, Jason Hellenthal wrote:
> 
> After recent merges to stable/8 I am now seeing errors on bootup of
> the following for three interfaces that will never see the light of
> DHCP. ?
> 
> /etc/rc.d/dhclient: ERROR: 'dc1' is not a DHCP-enabled interface
> 
> Can someone please revert these changes or some other action. ?
> 
> -- 
> ;s =;



-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: netstat: no namelist

[Jason Hellenthal]

On Mon, Feb 27, 2012 at 03:53:48PM +0100, O. Hartmann wrote:
> On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing
> "netstat on console or in terminal doesn't give the usual netstat as
> expected, instead I receive
> 
> netstat: no namelist
> 
> What's wrong?
> 

This usually happens when kernel and world are built out of sync.
Attempt to rebuild ( kernel first & then world ) follow the steps near
/usr/src/UPDATING


-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

da changes to recent stable

[Jason Hellenthal]

Can someone please look over this ... on i386 ?

cc1: warnings being treated as errors
/usr/src/sys/cam/scsi/scsi_da.c: In function 'dadone':
/usr/src/sys/cam/scsi/scsi_da.c:1930: warning: 'error_code' may be used
uninitialized in this functi
on
/usr/src/sys/cam/scsi/scsi_da.c:1930: warning: 'sense_key' may be used
uninitialized in this functio
n
/usr/src/sys/cam/scsi/scsi_da.c:1929: warning: 'ascq' may be used
uninitialized in this function
/usr/src/sys/cam/scsi/scsi_da.c:1929: warning: 'asc' may be used
uninitialized in this function
*** Error code 1



-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn commit: r233953 - stable/8/usr.bin/procstat

[Jason Hellenthal]

This commit in action does not seem to be doing the correct thing even
though it does report an error when kern.proc.pathname is not known.

Running procstat -a -b produces:
[...]
1848 ksh803500 /bin/ksh
procstat: sysctl: kern.proc.pathname: 2208: No such file or directory
2210 ksh803500 /bin/ksh
[...]

While procstat -a produces:
[...]
1848  1846  1848  1848  1848   1 jhellenthal wait  FreeBSD ELF32 ksh
 
2208  1814  2208  2208 0   1 jhellenthal selectFreeBSD ELF32 xterm
2210  2208  2210  2210  2210   1 jhellenthal wait  FreeBSD ELF32 ksh
[...]

If process 2208 can be seen during (procstat -a) I do not see a reason
to bailout and print an error when (-b) is used. Just print the
orrelease as (0) and print the rest of the information that should be
seen...

Could someone have a closer look at this?


On Fri, Apr 06, 2012 at 04:32:29PM +, Mikolaj Golub wrote:
> Author: trociny
> Date: Fri Apr  6 16:32:29 2012
> New Revision: 233953
> URL: http://svn.freebsd.org/changeset/base/233953
> 
> Log:
>   MFC r233390:
>   
>   When displaying binary information show also osreldate.
>   
>   Suggested by:   kib
> 
> Modified:
>   stable/8/usr.bin/procstat/procstat.1
>   stable/8/usr.bin/procstat/procstat_bin.c
> Directory Properties:
>   stable/8/usr.bin/procstat/   (props changed)
> 
> Modified: stable/8/usr.bin/procstat/procstat.1
> ==
> --- stable/8/usr.bin/procstat/procstat.1  Fri Apr  6 16:31:29 2012
> (r233952)
> +++ stable/8/usr.bin/procstat/procstat.1  Fri Apr  6 16:32:29 2012
> (r233953)
> @@ -25,7 +25,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd March 7, 2010
> +.Dd March 23, 2012
>  .Dt PROCSTAT 1
>  .Os
>  .Sh NAME
> @@ -98,6 +98,8 @@ Display the process ID, command, and pat
>  process ID
>  .It COMM
>  command
> +.It OSREL
> +osreldate for process binary
>  .It PATH
>  path to process binary (if available)
>  .El
> 
> Modified: stable/8/usr.bin/procstat/procstat_bin.c
> ==
> --- stable/8/usr.bin/procstat/procstat_bin.c  Fri Apr  6 16:31:29 2012
> (r233952)
> +++ stable/8/usr.bin/procstat/procstat_bin.c  Fri Apr  6 16:32:29 2012
> (r233953)
> @@ -42,11 +42,11 @@ void
>  procstat_bin(pid_t pid, struct kinfo_proc *kipp)
>  {
>   char pathname[PATH_MAX];
> - int error, name[4];
> + int error, osrel, name[4];
>   size_t len;
>  
>   if (!hflag)
> - printf("%5s %-16s %-53s\n", "PID", "COMM", "PATH");
> + printf("%5s %-16s %8s %s\n", "PID", "COMM", "OSREL", "PATH");
>  
>   name[0] = CTL_KERN;
>   name[1] = KERN_PROC;
> @@ -64,7 +64,19 @@ procstat_bin(pid_t pid, struct kinfo_pro
>   if (len == 0 || strlen(pathname) == 0)
>   strcpy(pathname, "-");
>  
> + name[2] = KERN_PROC_OSREL;
> +
> + len = sizeof(osrel);
> + error = sysctl(name, 4, &osrel, &len, NULL, 0);
> + if (error < 0 && errno != ESRCH) {
> + warn("sysctl: kern.proc.osrel: %d", pid);
> + return;
> + }
> + if (error < 0)
> + return;
> +
>   printf("%5d ", pid);
>   printf("%-16s ", kipp->ki_comm);
> + printf("%8d ", osrel);
>   printf("%s\n", pathname);
>  }
> ___
> svn-src-stabl...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-stable-8
> To unsubscribe, send any mail to "svn-src-stable-8-unsubscr...@freebsd.org"

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

BURN_BRIDGES & /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to `in6_selectroute_fib'

[Jason Hellenthal]

While attempting to burn bridges... yeah yeah I know, may include some
civil infractions ;)

On stable/8 i386 Last Changed Rev: 234180 fresh build

linking kernel.debug
ip6_output.o(.text+0x334f): In function `ip6_output':
/usr/src/sys/netinet6/ip6_output.c:582: undefined reference to
`in6_selectroute_fib'


-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: BURN_BRIDGES & /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to `in6_selectroute_fib'

[Jason Hellenthal]

On Thu, Apr 12, 2012 at 06:10:47PM +, Bjoern A. Zeeb wrote:
> 
> On 12. Apr 2012, at 17:10 , Jason Hellenthal wrote:
> 
> > 
> > While attempting to burn bridges... yeah yeah I know, may include some
> > civil infractions ;)
> > 
> > On stable/8 i386 Last Changed Rev: 234180 fresh build
> > 
> > linking kernel.debug
> > ip6_output.o(.text+0x334f): In function `ip6_output':
> > /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to
> > `in6_selectroute_fib'
> 
> It's basically a marker to not use this function anywhere new in the stable/ 
> branches.  It will change in HEAD soon given the code has now been in for 
> almost two months (in HEAD) without further needs to re-adjustment.  I am not 
> sure we ever allowed compiling with BURN_BRIDGES set but I can change the 
> #ifndef to THIS_IS_PART_OF_THE_PUBLIC_STABLE_KPI or something if needed.

Yeah compiling for me here was just a fundamental test but when I found
that I figured I should at least let someone know in case it was
useful.

Thanks Bjoern

> 
> See the comment above it:
> http://svnweb.freebsd.org/base/stable/8/sys/netinet6/in6_src.c?annotate=232552#l820
> 
> /bz
> 
> -- 
> Bjoern A. Zeeb You have to have visions!
>It does not matter how good you are. It matters what good you do!
> 

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: scanlogd doesnt start anymore after upgrade from 8.2 to 8.3 cause of USB

[Jason Hellenthal]

Did you recompile your ports so this would go away ?

More than likely some of your system is running against libpcap
installed from ports etc... This happens.

You should also expect these things to happen in an upgrade when you
leave software behind.

On Sun, Apr 22, 2012 at 05:47:24PM +0200, Hilko Meyer wrote:
> Claudius wrote:
> >If you are using packet filter,
> >echo hw.usb.no_pf=1 >>/boot/loader.conf
> >
> >http://lists.freebsd.org/pipermail/freebsd-stable/2012-January/065421.html
> >
> >Hope this helps.
> 
> Thanks! 
> | echo hw.usb.no_pf=1 >>/boot/loader.conf
> did the trick. That helped.
> 
> I'm a bit puzzled to see a disrupive change like this  merged to a
> Stable-branch without a heads-up and without documentation how to
> disable it.
> 
> 
> regards,
> hilko
> PS: forgot to mention I'm not subsricbed to this list. Please keep me
> CCed.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Restricting users from certain privileges

[Jason Hellenthal]

On Sat, Apr 28, 2012 at 08:04:31PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > > Please do study sudo real power :-)
> > > > It can give selective privileges per-command,
> [...]
> > > Just make sure none of the permitted commands has got the
> > > feature of starting a shell ;-))
> > 
> > Right, think of vi(1), less(1), et al.
> 
> Even this aspect is taken care of with sudo (at least to a certain limit):
> 
>NOEXEC and EXEC
> 
>If sudo has been compiled with noexec support and the underlying
>operating system supports it, the NOEXEC tag can be used to prevent a
>dynamically-linked executable from running further commands itself.
> 
>In the following example, user aaron may run /usr/bin/more and
>/usr/bin/vi but shell escapes will be disabled.
> 
> aaron  shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
> 
>See the "PREVENTING SHELL ESCAPES" section below for more details on
>how NOEXEC works and whether or not it will work on your system.
> 

cp /usr/bin/vi ~/

or upload your own...

sudo $HOME/vi


You need to be very careful with this NOEXEC thinking as it will not
always get you what you originally intended.


-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Restricting users from certain privileges

[Jason Hellenthal]

On Sat, Apr 28, 2012 at 04:34:34PM -0700, Freddie Cash wrote:
> On Apr 28, 2012 4:03 PM, "Jason Hellenthal"  wrote:
> > cp /usr/bin/vi ~/
> >
> > or upload your own...
> >
> > sudo $HOME/vi
> >
> 
> If your Cmnd_Alias includes the full path to vi, then your last command
> won't work.

I know. Just an example of why you should be careful. I had an admin on
a box I supervise add an entry where it enabled a user to run
miscelaneous commands. It did not effect anything since the user is well
trusted but if it had been the other way around and had not be caught
the sheer consequence of such could have been disasterous.

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-DNO_CLEAN compiling & recent changes as of ~two weeks.

[Jason Hellenthal]

Somewhere is the last two weeks it seems something has changed on
8-STABLE that causes a complete rebuild of the kernel every time it is
built.

While this is not too much of a problem, it is quite a neusense when
attempting to make a quick change that would only require a recompile of
the effected code and relink that would only amount to about 5 or 10
minutes.

I am running FreeBSD 8.3-STABLE #0 r234692 i386 where this has been an
issue. The earliest part of the kernel I always see compile is ACPI code
if that helps to determine the problem.

A few committs that I picked out that might cause it but only a guess
is... (I could be wrong about these)

After 8.3-RELEASE
r234634
r234631
r234604

Before 8.3-RELEASE
r234534
r234512
r234509

Maybe just a text or data relocation issue ? Has anyone else noticed this ?


To test after a full build of kernel #0.

1) Change config ROUTETABLES={ROUTETABLES+1}
2) cd /usr/src
3) time -h make -DNO_CLEAN buildkernel

This should only take a few minutes as an example only recompiling what
only is needed.

-- 

 - (2^(N-1))


pgpBknIFXTlQX.pgp
Description: PGP signature

Re: -DNO_CLEAN compiling & recent changes as of ~two weeks.

[Jason Hellenthal]

On Sun, Apr 29, 2012 at 01:35:20PM -0400, Eitan Adler wrote:
> On 29 April 2012 13:31, Jason Hellenthal  wrote:
> >
> > Somewhere is the last two weeks it seems something has changed on
> > 8-STABLE that causes a complete rebuild of the kernel every time it is
> > built.
> >
> > While this is not too much of a problem, it is quite a neusense when
> > attempting to make a quick change that would only require a recompile of
> > the effected code and relink that would only amount to about 5 or 10
> > minutes.
> >
> > I am running FreeBSD 8.3-STABLE #0 r234692 i386 where this has been an
> > issue. The earliest part of the kernel I always see compile is ACPI code
> > if that helps to determine the problem.
> >
> > A few committs that I picked out that might cause it but only a guess
> > is... (I could be wrong about these)
> >
> > After 8.3-RELEASE
> > r234634
> > r234631
> > r234604
> >
> > Before 8.3-RELEASE
> > r234534
> > r234512
> > r234509
> >
> > Maybe just a text or data relocation issue ? Has anyone else noticed this ?
> >
> >
> > To test after a full build of kernel #0.
> >
> > 1) Change config ROUTETABLES={ROUTETABLES+1}
> > 2) cd /usr/src
> > 3) time -h make -DNO_CLEAN buildkernel
> 
> use -DKERNFAST or -DNO_KERNELCLEAN
> 

Sorry but NO_CLEAN has been doing fine for a long time now and has not
changed recently. Like I said this happened about 2 weeks ago and was
not because of these defines.

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Jails can't get routing info

[Jason Hellenthal]

On Tue, May 01, 2012 at 09:01:33PM +, Bjoern A. Zeeb wrote:
> On 1. May 2012, at 19:41 , David Thiel wrote:
> 
> > Hello,
> > 
> > So, I've been trying to debug an issue running nmap scans within jails, 
> > partially documented here:
> > 
> > http://seclists.org/nmap-dev/2012/q2/220
> > 
> > On further debugging, it's seeming like jails can't read routing 
> > information directly at all:
> > 
> > # route get 69.163.203.254
> > route: writing to routing socket: No such process
> > 
> > Now, this is normally done via reading the routing table via something like 
> > socket(PF_ROUTE, SOCK_RAW, AF_INET), so one would suspect that this is a 
> > problem with raw sockets; but raw sockets are enabled within the jail. 
> > netstat is able to read routing information just fine, but I don't think 
> > it's doing it via the socket() call.
> 
> hmm, sure you don't have /dev/mem in the jail? netstat -rn I think is still
> using libkvm *sigh* and not the sysctl API.
> 

Good lord I hope this makes it down to stable/8

> 
> > Anyone know why this behavior might be happening?
> 
> Without thinking too much (as in if I got the right case) I think you are
> hitting this one:
> 
> http://svnweb.freebsd.org/base/head/sys/net/rtsock.c?annotate=234572#l792
> 
> /bz
> 
> -- 
> Bjoern A. Zeeb You have to have visions!
>It does not matter how good you are. It matters what good you do!
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: User root can't get email

[Jason Hellenthal]

On Thu, May 03, 2012 at 06:02:35PM -0500, Efraín Déctor wrote:
> Hello.
> 
> I have a FreeBSD Server 8.2, the past few days I’ve noticed that the user 
> root  was not recieving email. I ran a test simply by using:
> 
> mail root
> 
> Then in /var/log/messsages I got this message:
> 
> May  3 22:47:56 edh sendmail[74022]: q3RFM513074022: SYSERR(root): Cannot 
> reopen ./dfq3RFM513074022: No such file or directory
> May  3 22:47:56 edh sendmail[74022]: q3RFM514074022: SYSERR(root): putbody: 
> Cannot open ./dfq3RFM513074022 for MAILER-DAEMON from root: No such file or 
> directory
> 
> Im not using this server as a email server, but it is very important to me 
> because I have some scripts running by cron that send the output by email to 
> the user that is running them, in this case root.
> 

If you have recently been working on upgrading your system in any way I
would check the perms on all the directories in /var and possibly other
systems as can be advised in a upgrade procedure within the handbook.

You may also attempt the following which may fix it but it comes with a
disclaimer and you should know how to fix it if it breaks.

mtree -deU -f /etc/mtree/BSD.var.dist


Before doing the above, I would seriously ask myself... What did I do in
those last few days or week or so... and at least attempt to backtrack
to a conclusive result.


Good luck.

-- 

 - (2^(N-1))


pgpeiDnFgjzFc.pgp
Description: PGP signature

Re: User root can't get email

[Jason Hellenthal]

And possibly /etc/mtree/BSD.sendmail.dist

On Fri, May 04, 2012 at 01:05:05AM -0400, Jason Hellenthal wrote:
> 
> 
> On Thu, May 03, 2012 at 06:02:35PM -0500, Efraín Déctor wrote:
> > Hello.
> > 
> > I have a FreeBSD Server 8.2, the past few days I’ve noticed that the user 
> > root  was not recieving email. I ran a test simply by using:
> > 
> > mail root
> > 
> > Then in /var/log/messsages I got this message:
> > 
> > May  3 22:47:56 edh sendmail[74022]: q3RFM513074022: SYSERR(root): Cannot 
> > reopen ./dfq3RFM513074022: No such file or directory
> > May  3 22:47:56 edh sendmail[74022]: q3RFM514074022: SYSERR(root): putbody: 
> > Cannot open ./dfq3RFM513074022 for MAILER-DAEMON from root: No such file or 
> > directory
> > 
> > Im not using this server as a email server, but it is very important to me 
> > because I have some scripts running by cron that send the output by email 
> > to the user that is running them, in this case root.
> > 
> 
> If you have recently been working on upgrading your system in any way I
> would check the perms on all the directories in /var and possibly other
> systems as can be advised in a upgrade procedure within the handbook.
> 
> You may also attempt the following which may fix it but it comes with a
> disclaimer and you should know how to fix it if it breaks.
> 
> mtree -deU -f /etc/mtree/BSD.var.dist
> 
> 
> Before doing the above, I would seriously ask myself... What did I do in
> those last few days or week or so... and at least attempt to backtrack
> to a conclusive result.
> 
> 
> Good luck.
> 
> -- 
> 
>  - (2^(N-1))



-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Make filesystem type configurable for periodic(8)?

[Jason Hellenthal]

On Sun, May 06, 2012 at 11:20:42AM +0300, Daniel Kalchev wrote:
> 
> On May 4, 2012, at 7:05 PM, Freddie Cash wrote:
> 
> > A few of the periodic(8) scripts in FreeBSD have constructs similar to
> > the following to get which filesystems to scan for various things:
> >MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
> > 
> > For systems with large ZFS pools, and many ZFS filesystems, these
> > periodic scripts can grind it to its knees, and then some.  For
> > backups servers where we don't really care about the
> > ownership/permissions of files from the FreeBSD perspective, we really
> > don't want the ZFS filesytems to be scanned; 
> […]
> 
> The script already accommodates this scenario. Just mount your storage 
> filesystems with 'nosuidexec' and they won't be scanned. 
> 

You all may be interested in this [1] but I have not touched it in a
while and backed it out of a working source tree about a month ago so I
am no longer tracking it. But last I used it, it was working cleanly.

Configuration was like so...
daily_status_security_chknoid_enable="YES"
daily_status_security_chknoid_dirs="/ /home /tmp /var /usr/local"

The same thing should also be done for anything that traverses multiple
filesystems by default configuration and reporting output should remain
consistent. The current reporting format of these scripts is nearly
rediculous in its current use of diff(1).


1).
http://code.google.com/p/jhell/source/browse/340.noid.patch?repo=patches

-- 

 - (2^(N-1))


pgpynu62gVQ1d.pgp
Description: PGP signature

Re: bash 4.2 patchlevel 28

[Jason Hellenthal]

On Fri, May 25, 2012 at 07:44:39AM +0200, Trond Endrest?l wrote:
> On Thu, 24 May 2012 13:07-0700, Sean Bruno wrote:
> 
> > Noted that the following syntax is broken somewhere between 4.2
> > patchlevel 10 and 28.  I'm sure its because we shouldn't be doing that
> > over here at big purple, but we do ... and its a PITA.  I'm bisecting to
> > find out what is going on.
> > 
> > test:
> > VARIABLE="$(uname)"
> > bash: command substitution: line 3: syntax error near unexpected token
> > `)'
> > bash: command substitution: line 3: `uname)"'
> > 
> > Odd, but his works at patchlevel 10
> 
> I'm unable to reproduce this behaviour on one of my systems:
> 
> trond@enterprise:~>bash --version
> GNU bash, version 4.2.28(0)-release (amd64-portbld-freebsd9.0)
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> 
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> trond@enterprise:~>my_var="$(uname)"
> trond@enterprise:~>echo $my_var
> FreeBSD
> trond@enterprise:~>
> 
> I'm not sure what's going on in your case.
> 

Same here but on 8.3-STABLE i386 no errors found throughout any of the
tests.


-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

/usr/bin/unzip not being installed on 8.3-STABLE

[Jason Hellenthal]

I have just noticed the following depicting unzip not being
updated/installed during a make installworld.

The last binary before this test that caught my attention was from Apr
15, in which I cd(1) into unzip's source directory and did a make &&
everything neccesary to install it. After running a make installworld
once again I see that it seems not connected to the install target
somehow.

Could someone look into this when they get a chance ?

Install world happened here: May 26 16:11

ls -l /usr/bin
[...]
-r-xr-xr-x   1 root  wheel10168 May 26 16:11 uniq
-r-xr-xr-x   1 root  wheel11952 May 26 16:11 units
-r-xr-xr-x   6 root  wheel56796 May 26 16:11 unlzma
-r-xr-xr-x   1 root  wheel 5016 May 26 16:11 unvis
-r-xr-xr-x   6 root  wheel56796 May 26 16:11 unxz
-r-xr-xr-x   1 root  wheel15504 May 26 02:54 unzip
-r-xr-xr-x   2 root  wheel14840 May 26 16:11 uptime
-r-xr-xr-x   1 root  wheel14384 May 26 16:11 usbhidaction
-r-xr-xr-x   1 root  wheel14344 May 26 16:11 usbhidctl
[...]


This is on FreeBSD 8.3-STABLE r236003M i386


Thanks

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /usr/bin/unzip not being installed on 8.3-STABLE

[Jason Hellenthal]

On Sat, May 26, 2012 at 03:31:28PM -0500, Matthew D. Fuller wrote:
> On Sat, May 26, 2012 at 04:24:32PM -0400 I heard the voice of
> Jason Hellenthal, and lo! it spake thus:
> > 
> > I have just noticed the following depicting unzip not being
> > updated/installed during a make installworld.
> 
> >From a quick look at history, unzip was never connected to the build
> in 8.x, only 9.x+ (r200068, Dec 2009).
> 

Funny... so there are probably alot of machines running around with old
unzip binaries... including the already packaged releases.

> 
> -- 
> Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
>On the Internet, nobody can hear you scream.

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /usr/bin/unzip not being installed on 8.3-STABLE

[Jason Hellenthal]

On Sat, May 26, 2012 at 03:41:55PM -0500, Matthew D. Fuller wrote:
> On Sat, May 26, 2012 at 04:39:40PM -0400 I heard the voice of
> Jason Hellenthal, and lo! it spake thus:
> > 
> > Funny... so there are probably alot of machines running around with
> > old unzip binaries... including the already packaged releases.
> 
> No, they wouldn't have _any_ unzip binaries.
> 

Absolutely.

From: FreeBSD-8.2-RELEASE-i386-livefs.iso

Console# pwd ;ls usr/bin/ |grep unzip
/mnt/cd9660
bunzip2
gunzip


Silly

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /usr/bin/unzip not being installed on 8.3-STABLE

[Jason Hellenthal]

Could someone MFC this to stable/8 please...


r200068 | rdivacky | 2009-12-03 13:02:55 -0500 (Thu, 03 Dec 2009) | 6 lines

Connect unzip to the build.

Approved by:ed (mentor)
Approved by:des (unzip author)
Tested by:  exp ports build (miwi)



On Sat, May 26, 2012 at 04:24:32PM -0400, Jason Hellenthal wrote:
> 
> I have just noticed the following depicting unzip not being
> updated/installed during a make installworld.
> 
> The last binary before this test that caught my attention was from Apr
> 15, in which I cd(1) into unzip's source directory and did a make &&
> everything neccesary to install it. After running a make installworld
> once again I see that it seems not connected to the install target
> somehow.
> 
> Could someone look into this when they get a chance ?
> 
> Install world happened here: May 26 16:11
> 
> ls -l /usr/bin
> [...]
> -r-xr-xr-x   1 root  wheel10168 May 26 16:11 uniq
> -r-xr-xr-x   1 root  wheel11952 May 26 16:11 units
> -r-xr-xr-x   6 root  wheel56796 May 26 16:11 unlzma
> -r-xr-xr-x   1 root  wheel 5016 May 26 16:11 unvis
> -r-xr-xr-x   6 root  wheel56796 May 26 16:11 unxz
> -r-xr-xr-x   1 root  wheel15504 May 26 02:54 unzip
> -r-xr-xr-x   2 root  wheel14840 May 26 16:11 uptime
> -r-xr-xr-x   1 root  wheel14384 May 26 16:11 usbhidaction
> -r-xr-xr-x   1 root  wheel14344 May 26 16:11 usbhidctl
> [...]
> 
> 
> This is on FreeBSD 8.3-STABLE r236003M i386
> 
> 
> Thanks
> 
> -- 
> 
>  - (2^(N-1))

-- 

 - (2^(N-1))


pgpeZu2Wx9SQr.pgp
Description: PGP signature

Re: /usr/bin/unzip not being installed on 8.3-STABLE

[Jason Hellenthal]

Here is the unzip diff from stable/8 -> head

On Mon, May 28, 2012 at 07:20:03PM +0200, Dag-Erling Smørgrav wrote:
> Jason Hellenthal  writes:
> > Could someone MFC this to stable/8 please...
> 
> Is unzip in stable/8 identical to unzip in head and stable/9?  If not,
> this should be addressed first.  Otherwise, there is a good chance that
> many ports will fail to build.
> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@des.no

-- 

 - (2^(N-1))
Index: unzip.1
===
--- unzip.1	(.../stable/8/usr.bin/unzip)	(revision 236186)
+++ unzip.1	(.../head/usr.bin/unzip)	(revision 236186)
@@ -1,5 +1,5 @@
 .\"-
-.\" Copyright (c) 2007-2008 Dag-Erling Coïdan Smørgrav
+.\" Copyright (c) 2007-2008 Dag-Erling Smørgrav
 .\" All rights reserved.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
@@ -38,7 +38,6 @@
 .Ar zipfile
 .Sh DESCRIPTION
 .\" ...
-.Pp
 The following options are available:
 .Bl -tag -width Fl
 .It Fl a
@@ -121,6 +120,10 @@
 and
 .Fl u
 may be specified.
+If specified filename is
+.Qq - ,
+then data is read from
+.Va stdin .
 .Sh ENVIRONMENT
 If the
 .Ev UNZIP_DEBUG
Index: unzip.c
===
--- unzip.c	(.../stable/8/usr.bin/unzip)	(revision 236186)
+++ unzip.c	(.../head/usr.bin/unzip)	(revision 236186)
@@ -1,6 +1,6 @@
 /*-
  * Copyright (c) 2009 Joerg Sonnenberger 
- * Copyright (c) 2007-2008 Dag-Erling Coïdan Smørgrav
+ * Copyright (c) 2007-2008 Dag-Erling Smørgrav
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -426,7 +426,7 @@
 		fprintf(stderr,
 		"replace %s? [y]es, [n]o, [A]ll, [N]one, [r]ename: ",
 		*path);
-		if (fgets(buf, sizeof(buf), stdin) == 0) {
+		if (fgets(buf, sizeof(buf), stdin) == NULL) {
 			clearerr(stdin);
 			printf("NULL\n(EOF or read error, "
 			"treating as \"[N]one\"...)\n");
@@ -868,10 +868,14 @@
 	int fd, ret;
 	uintmax_t total_size, file_count, error_count;
 
-	if ((fd = open(fn, O_RDONLY)) < 0)
+	if (strcmp(fn, "-") == 0)
+		fd = STDIN_FILENO;
+	else if ((fd = open(fn, O_RDONLY)) < 0)
 		error("%s", fn);
 
-	a = archive_read_new();
+	if ((a = archive_read_new()) == NULL)
+		error("archive_read_new failed");
+
 	ac(archive_read_support_format_zip(a));
 	ac(archive_read_open_fd(a, fd, 8192));
 
@@ -929,7 +933,7 @@
 	ac(archive_read_close(a));
 	(void)archive_read_finish(a);
 
-	if (close(fd) != 0)
+	if (fd != STDIN_FILENO && close(fd) != 0)
 		error("%s", fn);
 
 	if (t_opt) {
Index: Makefile
===
--- Makefile	(.../stable/8/usr.bin/unzip)	(revision 236186)
+++ Makefile	(.../head/usr.bin/unzip)	(revision 236186)
@@ -1,7 +1,6 @@
 # $FreeBSD$
 
 PROG = unzip
-WARNS ?= 6
 CSTD = c99
 DPADD = ${LIBARCHIVE} ${LIBZ}
 LDADD = -larchive -lz
Index: .
===
--- .	(.../stable/8/usr.bin/unzip)	(revision 236186)
+++ .	(.../head/usr.bin/unzip)	(revision 236186)

Property changes on: .
___
Deleted: svn:mergeinfo
   Reverse-merged /head/sys/usr.bin/unzip:r196863
   Reverse-merged /head/usr.bin/unzip:r196045-201385,201387-207627,207842,207844,208320,212770,213738,213814,216591,223132,223152,223947,224271,224641,227006,227755,228857,230555,234206,235252
   Reverse-merged /vendor/resolver/dist/usr.bin/unzip:r1540-186085
   Reverse-merged /user/luigi/ipfw3-r8/usr.bin/unzip:r204833-205419
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problem with nmap

[Jason Hellenthal]

On Thu, May 31, 2012 at 04:12:09PM +0300, Andrey S. Rybak wrote:
> Hi!
> I can not run nmap on my computer with next output:
> "Error compiling our pcap filter: icmp6 not supported "
> I had not such nmap's problem on any my computer with FreeBSD.
> How I can solve this problem?
> #uname -a
> FreeBSD  9.0-STABLE FreeBSD 9.0-STABLE #5: Wed Feb  8 14:35:37 EET 
> 2012 root:/usr/obj/usr/src/sys/GENERIC  i386
> #nmap -V
> Nmap version 6.00 ( http://nmap.org )
> Platform: i386-portbld-freebsd9.0
> Compiled with: liblua-5.1.5 openssl-0.9.8q libpcre-8.30 libpcap-1.1.1 
> nmap-libdnet-1.12 ipv6
> Compiled without:
> Thank in advance
> 

I have the following which is different from your output but on
8.3-STABLE

Nmap version 6.00 ( http://nmap.org )
Platform: i386-portbld-freebsd8.3
Compiled with: liblua-5.1.5 openssl-0.9.8q libpcre-8.30 libpcap-1.2.1
nmap-libdnet-1.12 ipv6

You might consider installing libpcap from ports just to give it a shot.

Also running nmap with -dd may yield more to what is going on.

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [ GSOC ] Differences in shell behaviour

[Jason Hellenthal]

On Thu, May 31, 2012 at 11:21:10PM +0400, Alexander Pronin wrote:
> Hello everyone!
> I am GSOC student at FreeBSD Project.
> So my GSOC Project is "Parallelization in the ports collection".
> You may checkout wiki page of this project: 
> http://wiki.freebsd.org/SummerOfCode2012/Parallelization_in_the_ports_collection
> 
> Is it suitable to write sh script for 9.0, that does not work in 8.3?
> 
> To sum up, the scenario is as following:
> I need to spawn some processes in background to build port's dependencies.
> Store their pids.
> Wait for a while or do some stuff.
> explore exit codes of spawned processes by their pids.
> 
> The problem is:
> ### sh in 8.3
> $ false & pid=$!
> $ 
> [1]   Done (1)false
> $ wait ${pid}
> wait: No such job: 4852

I don't see this behavior on 8.3-STABLE @r236350 i386
 ---
Console> false & pid=$!
Console> wait ${pid}
[1]   Done (1)false
Console> echo $?
1
Console>

Using (builtin false) or (/usr/bin/false) I get the same results. Is
this a GENERIC system your working on ? And is this a blank user account
with no login.conf or profile modifications ?

 ---

ident /bin/sh ... for reference.
/bin/sh:
 $FreeBSD: stable/8/lib/csu/i386-elf/crti.S 146369 2005-05-19 07:31:06Z dfr 
$
 $FreeBSD: stable/8/lib/csu/i386-elf/crtn.S 146369 2005-05-19 07:31:06Z dfr 
$
 $FreeBSD: stable/8/lib/csu/i386-elf/crt1_s.S 217470 2011-01-16 10:41:47Z 
kib $
 $FreeBSD: stable/8/lib/csu/common/crtbrand.c 174251 2007-12-04 12:18:43Z 
kib $
 $FreeBSD: stable/8/bin/sh/alias.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/sh/arith.y 213390 2010-10-03 21:56:20Z jilles $
 $FreeBSD: stable/8/bin/sh/arith_lex.l 234001 2012-04-07 20:52:21Z jilles $
 $FreeBSD: stable/8/bin/sh/cd.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/sh/bltin/echo.c 127958 2004-04-06 20:06:54Z markm $
 $FreeBSD: stable/8/bin/sh/error.c 214123 2010-10-21 01:13:41Z obrien $
 $FreeBSD: stable/8/bin/sh/eval.c 231086 2012-02-06 13:36:49Z dumbbell $
 $FreeBSD: stable/8/bin/sh/exec.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/sh/expand.c 218992 2011-02-24 10:23:22Z brucec $
 $FreeBSD: stable/8/bin/sh/histedit.c 217485 2011-01-16 22:10:18Z jilles $
 $FreeBSD: stable/8/bin/sh/input.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/sh/jobs.c 08 2011-05-22 22:28:07Z jilles $
 $FreeBSD: stable/8/bin/sh/mail.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/sh/main.c 222452 2011-05-29 15:07:53Z jilles $
 $FreeBSD: stable/8/bin/sh/memalloc.c 214190 2010-10-21 23:45:57Z obrien $
 $FreeBSD: stable/8/bin/sh/miscbltin.c 213390 2010-10-03 21:56:20Z jilles $
 $FreeBSD: stable/8/bin/sh/mystring.c 213390 2010-10-03 21:56:20Z jilles $
 $FreeBSD: stable/8/bin/sh/options.c 221515 2011-05-05 22:07:02Z jilles $
 $FreeBSD: stable/8/bin/sh/output.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/sh/parser.c 221522 2011-05-06 12:49:32Z jilles $
 $FreeBSD: stable/8/bin/sh/redir.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/sh/show.c 214113 2010-10-20 18:25:00Z obrien $
 $FreeBSD: stable/8/bin/test/test.c 220250 2011-04-01 18:23:44Z delphij $
 $FreeBSD: stable/8/bin/sh/trap.c 231086 2012-02-06 13:36:49Z dumbbell $
 $FreeBSD: stable/8/bin/sh/var.c 231531 2012-02-11 20:37:08Z jilles $


/usr/bin/false:
 $FreeBSD: stable/8/lib/csu/i386-elf/crti.S 146369 2005-05-19 07:31:06Z dfr 
$
 $FreeBSD: stable/8/lib/csu/i386-elf/crtn.S 146369 2005-05-19 07:31:06Z dfr 
$
 $FreeBSD: stable/8/lib/csu/i386-elf/crt1_s.S 217470 2011-01-16 10:41:47Z 
kib $
 $FreeBSD: stable/8/lib/csu/common/crtbrand.c 174251 2007-12-04 12:18:43Z 
kib $
 $FreeBSD: stable/8/usr.bin/false/false.c 07 2003-02-19 00:10:28Z peter 
$

> 
> ---
> ### sh in releng9
> $ false & pid=$!
> $ 
> [1]   Done(1) false
> $ wait ${pid}
> $ echo $?
> 1
> $
> 
> I am currently working in releng9 environment, so the result suits my needs.
> 
> But, is it suitable to write sh script for 9.0, that does not work in 8.3?
> 
> ___
> freebsd-po...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Installworld and /usr/include/*.h modification times

[Jason Hellenthal]

On Fri, Jun 01, 2012 at 09:18:55PM +0300, Kimmo Paasiala wrote:
> On Fri, Jun 1, 2012 at 8:45 PM, Lowell Gilbert
>  wrote:
> > Kimmo Paasiala  writes:
> >
> >> Why are /usr/include files installed with "install -C" during "make
> >> installworld" ??when almost everything else is installed without the -C
> >> flag? This makes it harder to track which files were actually
> >> installed during the last "make installworld". One can easily find
> >> obsolete files ??(that are not covered with make delete-old(-libs))
> >> with "find -x / -type f -mtime +suitable_time" but this doesn't work
> >> for /usr/include files because the modification times are not bumped
> >> on "make installworld".
> >
> > "make" uses timestamps to determine whether to trigger a rule. Changing
> > timestamps on source files without changing the contents is a bad idea.
> 
> Yes, I'm aware of how make uses timestamps for figuring out out of
> date targets. However I would argue that after updating world with
> "make installworld" (which is done in single user mode there for
> requiring at least one reboot) you should start any compilations from
> scratch. The ports system does this by default and cleans up any
> previous work files before new compilation. I just don't see where
> bumping of mtimes for those files would have that great impact, does
> anyone?

With the setting of (vfs.timestamp_precision=1) in sysctl.conf I would
have to agree here strongly!. It would be great if this was default
especially in any new releases of stable/8 or stable/9.



-- 

 - (2^(N-1))


pgp3RKo14DoJR.pgp
Description: PGP signature

Re: problem with nmap

[Jason Hellenthal]

On Fri, Jun 01, 2012 at 07:43:17AM +0300, Andrey S. Rybak wrote:
> Installing libpcap from ports does not help. Error message is same.
> Running nmap with -dd yield next:
> 
> Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-01 05:42 EEST
> Fetchfile found /usr/local/share/nmap/nmap-services
> PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0)
> Fetchfile found /usr/local/share/nmap/nmap.xsl
> The max # of sockets we are using is: 0
> --- Timing report ---
>hostgroups: min 1, max 10
>rtt-timeouts: init 1000, min 100, max 1
>max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>parallelism: min 0, max 0
>max-retries: 10, host-timeout: 0
>min-rate: 0, max-rate: 0
> -
> Read from /usr/local/share/nmap: nmap-services.
> WARNING: No targets were specified, so 0 hosts scanned.
> Nmap done: 0 IP addresses (0 hosts up) scanned in 0.04 seconds
> Raw packets sent: 0 (0B) | Rcvd: 0 (0B)
> 
> 

Have you also recompiled nmap after you installed libpcap. Sorrry this
should be a neccesary step.

nmap -V -dd

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Why am I, Still subscribed and reading this list ?

[Jason Hellenthal]

Because... at some point it may return to normal without all the
bikeshedding and, I run because, I don't run because.

The previous threads before this message should have been on a web form
or questions@ as they are completely out of control.


-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

usr.bin/fstat warnings being treated as errors on i386

[Jason Hellenthal]

Is anyone else seeing this on a vanilla source tree ?

cc1: warnings being treated as errors
/usr/src/usr.bin/fstat/fstat.c:159: warning: 'struct shmfd' declared
inside parameter list
/usr/src/usr.bin/fstat/fstat.c:159: warning: its scope is only this
definition or declaration, which is probably not what you want
/usr/src/usr.bin/fstat/fstat.c:951: warning: 'struct shmfd' declared
inside parameter list
/usr/src/usr.bin/fstat/fstat.c:952: error: conflicting types for
'shmtrans'
/usr/src/usr.bin/fstat/fstat.c:159: error: previous declaration of
'shmtrans' was here
/usr/src/usr.bin/fstat/fstat.c: In function 'shmtrans':
/usr/src/usr.bin/fstat/fstat.c:953: error: storage size of 'shm' isn't
known
/usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of
'sizeof' to incomplete type 'struct shmfd' 
/usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of
'sizeof' to incomplete type 'struct shmfd' 
/usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of
'sizeof' to incomplete type 'struct shmfd' 
/usr/src/usr.bin/fstat/fstat.c:953: warning: unused variable 'shm'
*** Error code 1



-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: PF to Preventing SMTP Brute Force Attacks

[Jason Hellenthal]

On Fri, Jun 15, 2012 at 04:17:06PM -, Shiv. Nath wrote:
> Hi FreeBSD Gurus,
> 
> 
> i want to use PF to Preventing SMTP Brute Force Attacks. i need some help
> to understand correct syntax.
> 
> URL Explaining this: http://www.openbsd.org/faq/pf/filter.html#stateopts
> 
> 
> i expect the following behavior from the PF rule below:
> 
> Limit the absolute maximum number of states that this rule can create to 200
> 
> Enable source tracking; limit state creation based on states created by
> this rule only
> 
> Limit the maximum number of nodes that can simultaneously create state to 100
> 
> Limit the maximum number of simultaneous states per source IP to 3
> 
> Solution:
> int0="em0"
> trusted_tcp_ports="{22,25,443,465}"
> 

 pass in on $int0 proto tcp from any to any port $trusted_tcp_ports keep
 state (max 200, source-track rule, max-src-nodes 100, max-src-states 3 )


 I don't know if max will work here but this is what I use for a sshd
 rule.

 pass in log quick proto tcp from any port >1023 to any port 22 flags
 S/SA keep state (max-src-conn 5, max-src-conn-rate 5/15 overload
  flush global)


 You should be using the syntax from pf41 through pf45. The URL you
 referenced has a syntax that changed in pf46, pf47 onward...

 

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD 8.3-STABLE #0 r237184 if_tun auto-up upon create.

[Jason Hellenthal]

Hoping someone here might be able to clue me in on what I am seeing.

FreeBSD 8.3-STABLE #0 r237184

When creating a if_tun(4) device...
ifconfig tun0 create 

With these line in rc.conf(5)
cloned_interfaces="tun0"
ifconfig_tun0="metric 100 down"

And sysctl net.link.tun.devfs_cloning=0

The resulting tun0 device results in state...
tun0: flags=8011 metric 100 mtu 1500


After removing the ifconfig_tun0= and running ifconfig create...
tun0: flags=8010 metric 0 mtu 1500


Why would the device enter a UP/DOWN state if there is no addressing
information being fed to it ? and especially with a directive of "down"
?


As a workaround I just removed the ifconfig_tun0= and dropped a ifconfig
command in rc.local to achieve what I want for the moment. I need this
interface created but not in any state unless otherwise manually
specified.


Thanks

-- 

 - (2^(N-1))


pgpPGZ0ZHKcqZ.pgp
Description: PGP signature

Re: FreeBSD 8.3-STABLE #0 r237184 if_tun auto-up upon create.

[Jason Hellenthal]

On Mon, Jun 18, 2012 at 02:37:27PM +0700, Eugene Grosbein wrote:
> 18.06.2012 09:47, Jason Hellenthal пишет:
> > 
> > Hoping someone here might be able to clue me in on what I am seeing.
> > 
> > FreeBSD 8.3-STABLE #0 r237184
> > 
> > When creating a if_tun(4) device...
> > ifconfig tun0 create 
> > 
> > With these line in rc.conf(5)
> > cloned_interfaces="tun0"
> > ifconfig_tun0="metric 100 down"
> > 
> > And sysctl net.link.tun.devfs_cloning=0
> > 
> > The resulting tun0 device results in state...
> > tun0: flags=8011 metric 100 mtu 1500
> > 
> > 
> > After removing the ifconfig_tun0= and running ifconfig create...
> > tun0: flags=8010 metric 0 mtu 1500
> > 
> > 
> > Why would the device enter a UP/DOWN state if there is no addressing
> > information being fed to it ? and especially with a directive of "down"
> > ?
> 
> That's because the word "up" is automatically added by system rc-scripts
> for ifconfig_XXX lines, so real ifconfig statement in your case is:
> 
> ifconfig tun0 metric 100 down up
> 

Ugh! thanks. guess Ill just have to stick with start_if.tun0

I could swear I have other interfaces that don't do that but at least I
know what I am looking for now.


Thanks again

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: fsck_ufs running too often

[Jason Hellenthal]

On Sat, Jun 23, 2012 at 06:36:24PM -0700, Greg Byshenk wrote:
> On Sat, Jun 23, 2012 at 06:23:58PM +1000, Sean wrote:
> > On 23/06/2012, at 7:47 AM, Leonardo M. Ram? wrote:
>  
> > > Hi, since a few of days ago, I noticed my home server turns very
> > > slow more than once a day, so every time I run "top" to see what's
> > > processes are running, I can see fsck_ufs at the very top, and the
> > > hard drive working like mad.
> > > 
> > > I've checked my crontab and there's nothing related to fsck_ufs,
> > > where can I start searching for the cause of the problem?, I
> > > thought this process should run only at boot or shutdown, but this
> > > time it is running -apparently- without a cause.
>  
> > Background fsck. Your server crashed, rebooted, started up and fsck
> > is running in the background while everything else continues.
> > 
> > [...]
> > 
> > The more important thing is to find out why it crashed - if there
> > was a power outage, hardware or software issue.
> 
> Another thing to do is look in the logs to see if background fsck
> is failing for some reason. I've seen it happen in some cases that
> background fsck fails and asks for a manual run, in which case the
> filesystem remains dirty, and further reboots will continue to fail
> until a manual fsck is run.
> 

At one point it was proven that background fsck was not benefitial. I am
not sure what ever came out of that but it was advised to turn it off.

I usually go with these to aid in something useful for things I do not
really care about. You might consider to/not use fsck_y_enable but they
help.

fsck_y_enable="YES"
background_fsck="NO"

-- 

 - (2^(N-1))


pgpxCyZ4jPFaI.pgp
Description: PGP signature

Re: mountd suddenly stopped working

[Jason Hellenthal]

On Sat, Jun 30, 2012 at 09:07:17PM +, Marcin Wisnicki wrote:
> On Sat, 30 Jun 2012 16:21:18 +0200, Ronald Klop wrote:
> 
> > On Sat, 30 Jun 2012 15:53:53 +0200, Marcin Wisnicki
> >  wrote:
> > 
> >> I have just rebooted an old system after 100 days of uptime and this
> >> came up:
> >>
> >> Jun 30 15:39:00 ghost mountd[1592]: can't change attributes for
> >> /tftpboot Jun 30 15:39:00 ghost mountd[1592]: bad exports list line
> >> /tftpboot -ro -mapall
> >>
> > 
> > Than probably somebody changed something else. Can you provide the
> > content of your exports file?
> > 
> 
> OK, I've found the reason.
> 
> There were two paths exported with same attributes:
> 
> /tftpboot -ro -mapall=nobody
> /vol/tank1 -ro -mapall=nobody
> 
> As long as there is a filesystem mounted on /vol/tank1, above exports
> will work. Since I've disconnected that drive, there was nothing mounted
> this time.
> 
> Apparently mountd does not allow exporting multiple paths from a single
> filesystem on separate lines if they happen to have identical attributes.
> 

Its been like that for a long time. I remember running into this way
back on 6.X and 5.X.

The solution is to:

/tftpboot /vol/tank1 -ro -mapall=nobody

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[RFC] Flags to dmesg(1) to toggle kern.msgbuf_clear ?

[Jason Hellenthal]

Would anyone be interested in adding a flag argument to dmesg to toggle
kern.msgbuf_clear ? or systematicly to do the same thing ?

I often find myself wanting to clear the msgbuf but have to remember
what the sysctl MIB is for doing so and thought it would be a value add
situation to just add '-c' or '-C' to dmesg(1) to accomplish the same
thing.

This would be along the same lines that Linux has done for quite a
while.


-- 

 - (2^(N-1))


pgpkrooRa6VDR.pgp
Description: PGP signature

Re: 9.0-STABLE: Can't umount umass device

[Jason Hellenthal]

fstat /flash ?

On Tue, Jul 03, 2012 at 08:42:55PM -0400, George Mitchell wrote:
> uname -a:
> FreeBSD wonderland.m5p.com 9.0-STABLE FreeBSD 9.0-STABLE #9: Sun Jun  3 
> 10:01:09 EDT 2012 
> geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND  amd64
> 
> dmesg | grep umass:
> umass0:  on usbus2
> umass0:  SCSI over Bulk-Only; quirks = 0x4000
> umass0:3:0:-1: Attached to scbus3
> (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
> (probe0:umass-sim0:0:0:0): SCSI status: Check Condition
> (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not 
> ready to ready change, medium may have changed)
> da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
> 
> # mount -t msdosfs /dev/da0s1 /flash
> # umount /flash
> umount: unmount of /flash failed: Device busy
> 
> -- George Mitchell
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 

 - (2^(N-1))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

mtree(8) reservation of 16 -1 char[] in mtree files...

[Jason Hellenthal]

I was just going through mtree(8) and happen to notice that mtree while
populating a mtree file by the following [1] reference that it suffixes
spaces as some sort of way to either reserve or pad the result for every
value.

Has anyone else see this behavior in Xterm or cons2* terminals from
stable/8 i386 @ r238072 ?

I tested this with /bin/sh /bin/csh /bin/bash /bin/ksh on cons25 cons50
xterm logged in directly as either a user or root through ssh and local.

I looked over the mtree files in /etc/mtree and they do not exhibit the
same thing so it now has me curious if something snuck in that would
have changed this behavior.

I have not had time to see if this repeats on other arch's

1). mtree -c -d -i -n -k uname,gname,mode,nochange >mtree.out



Thanks to anyone that hits me with the clue bat if I have missed
something.

-- 

 - (2^(N-1))


pgpnF10eIMGk3.pgp
Description: PGP signature

ifconfig(8) fails to set MTU on multiple interfaces.

[Jason Hellenthal]

>Submitter-Id:  current-users
>Originator:    Jason Hellenthal
>Organization:  
>Confidential:  no 
>Synopsis:  ifconfig(8) fails to set MTU on multiple interfaces.
>Severity:  non-critical
>Priority:  high
>Category:  kern
>Class: sw-bug
>Release:   FreeBSD 8.3-STABLE i386
>Environment:
System: FreeBSD disbatch.DataIX.local 8.3-STABLE FreeBSD 8.3-STABLE #23 
r238498: Sun Jul 15 15:34:30 EDT 2012 
j...@dataix.net:/usr/obj/usr/src/sys/DISBATCH i386

>Description:
When using ifconfig(8) to change MTU of an interface it is not allowed.

# ifconfig lagg0 mtu 1492
ifconfig: ioctl (set mtu): Invalid argument

# ifconfig dc0 mtu 1492
ifconfig: ioctl (set mtu): Invalid argument

# ifconfig dc1 mtu 1492
ifconfig: ioctl (set mtu): Invalid argument

# ifconfig pflog0 mtu 120
ifconfig: ioctl (set mtu): Invalid argument

# ifconfig ath0 mtu 1500
ifconfig: ioctl (set mtu): Invalid argument

>How-To-Repeat:

See description.

>Fix:

No workaround known.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Login failures usefulness with OpenSSH 6.1

[Jason Hellenthal]

Hello everyone,

It seems that the login failures reported by the security output of a nightly 
periodic job has become somewhat useless per OpenSSH 6.1.

I used to get username and IP address in the output but it seems that the 
logging format has changed. Instead of one line the log format now has two 
lines. One like the ones below and then another coinciding line that contains 
IP address and username.

I think it would be more beneficial outputting the lines with the ip and 
username over the ones below for the security output.

Not sure exactly when this changed but would like to gather some input before I 
inspect further on the changes that would have to be made.

My output is from SVN FreeBSD STABLE 8.3 as of yesterday.


Thanks & Clean Regards,

...Sample output...

login failures:
May  4 00:04:35 disbatch sshd[48898]: fatal: Write failed: Operation not 
permitted
May  4 14:54:14 disbatch sshd[9544]: input_userauth_request: invalid user root 
[preauth]
May  4 18:44:04 disbatch sshd[18326]: fatal: Read from socket failed: 
Connection reset by peer [preauth]

-- 
 Jason Hellenthal
 JJH48-ARIN
 -(2^(N-1))

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Subversion 1.8 / FreeBSD 8 x86 STABLE Symlinks

[Jason Hellenthal]

When using svn 1.8 I have come across a situation where when it is used 
pointing to a symlink that refers to a working directory that a update will 
either segfault or exit prematurely and leave a lock held on the working 
directory that the symlink points to.

This leaves you with one choice but to run cleanup on the referenced actual 
working directory which was AFAIK never the case for any version below 1.8.

Not sure if this is a problem with svn or FreeBSD itself but thought I would 
report the characteristics in case it's noticed elsewhere.

Details:
Using UFS
FreeBSD 8-STABLE i386 as of this date.

In the directory...
cd /exports/usr
ln -s src8 src
svn up /exports/usr/src




-- 
 Jason Hellenthal
 Inbox: jhellent...@dataix.net
 Voice: +1 (616) 953-0176
 JJH48-ARIN



smime.p7s
Description: S/MIME cryptographic signature

9-STABLE amd64 / VirtualBox Testcases

[Jason Hellenthal]

Is anyone else seeing the build of VB on 9 failing on the test cases ? With two 
files that cannot be deleted and and one that after touching the two files so 
they can that errors out because of a parenthesis syntax error ?

Don't have the exact names of these off hand due to no inbound outbound 
connection to the machine but in particular it seems to only be a problem with 
the test cases at this point and would like to find a way to just disable the 
build of them for right now as I'm just trying to wrap this project up.

These are builds from all recent sources and ports as of today.

I see some variables within the vbox ose that just echoes the null car into 
localconfig.kmk but nothing obvious as of yet to completely wipe it from the 
build cycle.


Please keep me CCd upon reply I don't believe I am on the virt list as of yet.

Thanks


-- 
 Jason Hellenthal
 Inbox: jhellent...@gmail.com
 Voice: +1 (616) 953-0176
 JJH48-ARIN

-- 
 Jason Hellenthal
 Inbox: jhellent...@dataix.net
 Voice: +1 (616) 953-0176
 JJH48-ARIN



smime.p7s
Description: S/MIME cryptographic signature

Re: zpool upgrade, can't boot

[Jason Hellenthal]

Jeff,


On Mon, May 02, 2011 at 12:42:22PM -0400, Jeff Blank wrote:
>Hi,
>
>I recently upgraded from 8.0-STABLE to 8.2-STABLE (Apr. 29 checkout)
>and upgraded my zpool (includes root FS) from v13 to v15.  This is a
>dual-boot laptop, so I'm using MBR/boot0 and not GPT.  Here's what
>happens when I boot:
>
>F1  Win
>F2  ?
>F3  FreeBSD
>
>F6 PXE
>Boot:  F3
>ZFS: unsupported ZFS version 15 (should be 13)
>No ZFS pools located, can't boot
>

This has been discussed thoroughly in the past. You need to update your 
bootcode. You can use gpart(8) with the bootcode option to do this or your 
standard preferred way.

You will also have to do this same step when v28 makes it into the code.


Good Luck

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpMmdU811VU1.pgp
Description: PGP signature

Re: RELENG_8 pf stack issue (state count spiraling out of control)

[Jason Hellenthal]

---
>vmstat -i
>
>interrupt  total   rate
>irq4: uart054768912
>irq6: fdc0 1  0
>irq17: uhci1+172  2
>irq23: uhci3 ehci1+ 2367 39
>cpu0: timer  13183882632  219731377
>irq256: em02604910554341517
>irq257: em11275550362125917
>irq258: ahci0  2259231643765386
>cpu2: timer  13183881837  219731363
>cpu1: timer  13002196469  216703274
>cpu3: timer  13183881783  219731363
>Total53167869284  886131154
>
>
>Here's what a normal "vmstat -i" shows from the command-line:
>
># vmstat -i
>interrupt  total   rate
>irq4: uart0  518  0
>irq6: fdc0 1  0
>irq23: uhci3 ehci1+  145  0
>cpu0: timer 19041199   1999
>irq256: em0   614280 64
>irq257: em1   168529 17
>irq258: ahci0 355536 37
>cpu2: timer 19040462   1999
>cpu1: timer 19040458   1999
>cpu3: timer 19040454   1999
>Total   77301582   8119
>
>We graph many aspects of this box, including CPU load, memory/swap
>usage, etc. and none show any sign that the interrupt rate on all of
>those devices was even remotely out of control.  (I would expect to see
>CPU through the roof given the above data)
>
>I have since rebuilt/reinstalled world/kernel on the machine with the
>latest RELENG_8 code (box is now 8.2-STABLE #0: Mon May  2 14:44:18 PDT
>2011), hoping whatever this was may have been fixed.
>
>As for what I think may have triggered it, but I have no hard evidence
>of such: on April 29th, I changed our pf.conf and did "/etc/rc.d/pf
>reload".  The pf.conf change was a single line:
>
>Old: scrub on em0 all
>New: scrub in on em0 all
>
>Why it took the problem approximately 3 days to start is unknown.  It's
>the only change we've made to the system (truly/honestly), and it was a
>change to pf.conf.
>
>If anyone has advice (or has seen the above problem), or is interested
>in debugging it -- as I said, I have a vmcore -- I'm happy to assist in
>any way I can.  I would hate for someone else to get bit by this, and
>really am hoping its something that has been fixed between February and
>now.
>

That's quite the deduction there. I've noticed recently that you were also 
experimenting with the new NFS server recompiling kernel etc etc. Seeing 
as weird things can happen with DNS, NFS and mountpoint's, is this the same 
machine that you were doing that on ?

If so can you check to see how many requests for NFS operations were done 
to/from that box ? as well the names that would be being resolved and if 
that machine can resolve them ?

Also I would believe your using tables in your pf.conf, if so do any of 
those tables contain a FQDN that cannot be resolved from that machine ?

I think you probably see what I am getting at here as it could be some 
sort of concurrent recursive DNS failure that can only be seen from the 
machine caused by possibly the new NFS backend or a change in one of the 
tables that pf would use.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgp0eObgCkq4s.pgp
Description: PGP signature

Re: Daily backups of pkgdb failure

[Jason Hellenthal]

Doug,


On Wed, May 04, 2011 at 12:26:01PM -0700, Doug Barton wrote:
>On 05/04/2011 04:49, Hans Ottevanger wrote:
>> Hi,
>>
>> I upgraded my Soekris 4801 boxes from 8.1 to 8.2-STABLE (r221326) a few
>> days ago and now I get the following error in the daily mail:
>>
>> Backing up package db directory:
>> tar: : Cannot stat: No such file or directory
>> tar: Error exit delayed from previous errors.
>>
>> These messages originate from /etc/periodic/daily/220.backup-pkgdb,
>> apparently a recent addition.
>>
>> The culprit is probably on line 21:
>>
>> make -f/usr/share/mk/bsd.port.mk -V PKG_DBDIR
>> "/usr/share/mk/bsd.port.mk", line 11: Could not find
>> /usr/ports/Mk/bsd.port.mk
>> make: fatal errors encountered -- cannot continue
>
>Thanks, I'll take a look.
>

Move PKG_DBDIR out of ports(7) and/or duplicate it to 
/usr/share/mk/bsd.port.mk.

Seems this could be used for far off more things than when ports(7) is 
unpacked to its usual location.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpA9FdNpuzO0.pgp
Description: PGP signature

Re: Daily backups of pkgdb failure

[Jason Hellenthal]

Doug,


On Wed, May 04, 2011 at 07:37:48PM -0700, Doug Barton wrote:
>On 05/04/2011 16:25, Jason Hellenthal wrote:
>> Move PKG_DBDIR out of ports(7) and/or duplicate it to
>> /usr/share/mk/bsd.port.mk.
>
>A) That's a non-starter
>B) Doesn't actually solve the problem at hand

Considering the PKG_DBDIR doesn't require ports being installed I fail to 
see why duplicating it to a location that's system-wide would be a problem. 
If that is a problem then maybe a global environment file should be put 
into place that will export that variable directly to user-land for 
consumption.

FTP_PASSIVE_MODE is already set via login.conf. Would there be any harm in 
exporting one more for PKG_DBDIR instead of having that in the Make files 
at all ?

I think something a little more solid should become of this variable than 
whats in place now.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpbsTC9yTV2j.pgp
Description: PGP signature

test

[Jason Hellenthal]

hackers,

Test

-- 

 Regards, (jhell)
 Jason Hellenthal

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: test

[Jason Hellenthal]

hackers,

On Sun, May 08, 2011 at 01:54:18PM -0400, Jason Hellenthal wrote:
> 
> hackers,
> 
> Test
> 

My appologies. this message was never supposed to leave the outbox. 
Instead of hitting one key I hit another. Please disregard.


Thanks.

-- 

 Regards, (jhell)
 Jason Hellenthal

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.

[Jason Hellenthal]

List, - Please reply-to freebsd...@freebsd.org

Recently I have been going over some changes in the configurations that 
are possible with the rc subsystem and to my dismay I have found some 
inconsistencies with in particular the way rc.conf.d directory is 
processed and the arguments that are supplied to load_rc_config so I have 
patched it up...

Let me explain:  As determined by rc.subr load_rc_config, config's from 
rc.conf.d are loaded by the scripts $name as an argument to load_rc_config 
and thus only the name being parsed is is available to be used in the 
rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient as 
the user has no direct way to know that a variable used by nfsd is also 
needed by mountd or the same for various other scripts in the rc.d 
directory. At this time these config's are explained to be available for 
the user to utilize by rc.conf(5) but yet without much knowledge of the 
inner workings of the rc subsystem it would be quite the feat to do.


The attachment[1] keeps this functionality the same while introducing a 
more convenient approach for the user to modularize their configuration 
however they see fit within a couple constraints that work very well. 


What does it do ?: As stated above, current functionality is undisturbed 
while allowing the user to create config's by any name they so desire as 
long as it has an extension of ".conf", also introducing the ability to 
turn a configuration file off by using chmod(1). You can turn nfsc1.conf
off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf


Why ? Simple. How many times have you been bitten by disabling something 
in the rc.conf file and left to discover what you just disabled was also 
used by another daemon but that daemon is now not starting ? This is a way 
to virtualize your configuration allowing you to add multiple _enable= 
lines to different configurations for different roles. For instance 
rpcbind is used by both samba and nfs*. With this you can add 
rpcbind_enable to both a configuration for samba and nfs and when you 
disable one service you know that you have not disabled a dependent for 
another.


This is a small addition that fixes currently broken undesirable aspects 
of the configuration system that deals with the rc.conf.d directory with a 
SysV style init approach that is just as flexible. This should apply 
cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedback 
has been received Ill update the manual page with any suggestions 
regenerate the patch to accommodate and file a PR.


1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch


Thanks

-- 

 Regards, (jhell)
 Jason Hellenthal



pgp2JDj2HJ4jZ.pgp
Description: PGP signature

Re: gpg-agent dont start automatically

[Jason Hellenthal]

On Thu, Jul 14, 2011 at 12:57:36AM -0700, Doug Barton wrote:
> On 07/13/2011 23:42, joerg_surmann wrote:
> > 
> > Hi all,
> > 
> > i have in my .xinitrc:
> > exec /usr/local/bin/gpg-agent --daemon --write-env-file
> > .gnupg/agent.info /usr/home/holm/.gpg-agent-info
> > 
> > Thats don't start gpg-agent.
> 
> Take a look at this:
> 
> http://dougbarton.us/PGP/gpg-agent.html
> 

This may be helpful too for reference there are a lot of ways you can go
about setting this up. Here is mine.

===

using cron @reboot & every 5 minutes:
#!/bin/sh
# Start gpg-agent if it is not running as the current user.

umask 077

rm -f $HOME/.gpg-agent-info # only for @reboot. remove for minutely

pgrep -q -U $LOGNAME gpg-agent ||/usr/local/bin/gpg-agent --daemon
--write-env-file "${HOME}/.gpg-agent-info" >>/dev/null 2>&1



Then in your profile or rc file for the shell: (bourne compatible)

GPG_TTY="$(tty)"

if [ -n "$(pgrep -U $LOGNAME gpg-agent)" -a -f ${HOME}/.gpg-agent-info ]; then
. ${HOME}/.gpg-agent-info
export GPG_AGENT_INFO
if [ -S ${HOME}/.gnupg/S.gpg-agent.ssh ]; then
export SSH_AUTH_SOCK
fi
echo "GNU Privacy Guard Agent [ENABLED]"
echo
else
unset GPG_AGENT_INFO
if [ -f ${HOME}/.gpg-agent-info ]; then
rm -f ${HOME}/.gpg-agent-info
fi
fi



Adjust appropriately for your environment.

This should allow you to use gpg-agent form the console, any xterm, rxvt
etc... and any X applications while X is running and ensure that
gpg-agent is restarted if it for some reason fails.


Good luck.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: running newsyslog fiveminly

[Jason Hellenthal]

On Mon, Aug 01, 2011 at 11:20:35AM +0700, Eugene Grosbein wrote:
> 01.08.2011 09:39, Jason Hellenthal ?:
> > 
> > What line of the newsyslog.conf file is your line inserted and can you
> > move that to a higher line number. FIFO
> 
> I don't get why position of line in newsyslog.conf can have any meaning.
> 

Normally things don't process from the inside out. Its first in first
out. newsyslog processes from the first line it see's and then moves
down. If your first line that processes is a large file that takes a
while to compress then the delay you are seeing is coming from
processing those files first.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: running newsyslog fiveminly

[Jason Hellenthal]

On Mon, Aug 01, 2011 at 11:20:35AM +0700, Eugene Grosbein wrote:
> 01.08.2011 09:39, Jason Hellenthal ?:
> > 
> > What line of the newsyslog.conf file is your line inserted and can you
> > move that to a higher line number. FIFO
> 
> I don't get why position of line in newsyslog.conf can have any meaning.
> 

Note on the previous comment... check the timestamps on the files and
you should see the timestamps for the files listed at the top of
newsyslog.conf have an earlier timestamp than the ones at the bottom.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: R: make installworld fails (touch not found)

[Jason Hellenthal]

On Fri, Sep 16, 2011 at 12:26:46PM +0100, Tom Evans wrote:
> On Fri, Sep 16, 2011 at 7:18 AM, Jason Hellenthal  wrote:
> >
> > Don't get why all these references for time are popping up here and why
> > everyone seems to think that would make the PATH variable get cut short
> > from the environment that newvers.sh is running in, but see the post I
> > made to the real thread a few moments earlier.
> >
> 
> Its also a FAQ in the handbook:
> 
> http://www.freebsd.org/doc/en/books/faq/troubleshoot.html#TOUCH-NOT-FOUND
> 

Keywords "...when booting into single user mode." 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: R: make installworld fails (touch not found)

[Jason Hellenthal]

On Sat, Sep 17, 2011 at 01:38:31AM -0400, Jason Hellenthal wrote:
> 
> 
> On Fri, Sep 16, 2011 at 12:26:46PM +0100, Tom Evans wrote:
> > On Fri, Sep 16, 2011 at 7:18 AM, Jason Hellenthal  wrote:
> > >
> > > Don't get why all these references for time are popping up here and why
> > > everyone seems to think that would make the PATH variable get cut short
> > > from the environment that newvers.sh is running in, but see the post I
> > > made to the real thread a few moments earlier.
> > >
> > 
> > Its also a FAQ in the handbook:
> > 
> > http://www.freebsd.org/doc/en/books/faq/troubleshoot.html#TOUCH-NOT-FOUND
> > 
> 
> Keywords "...when booting into single user mode." 

Should also mention here machines that I have noticed this on were
syncronized with NTP & time was not fluctuating at the time of errors.
Once that I have mentioned before could be provoked by using screen or
tmux whereas not using either of them it would not happen. Login shell
non-Login shell ? pick your Brat!.

All I know is the environment disapears for one reason or another but I
am fairly confident it does not have anything to do with adjkerntz or
localtime.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: h_ertt cc_vegas loader.conf interaction on stable/8

[Jason Hellenthal]

Hi Larence,

On Wed, Sep 21, 2011 at 12:39:28PM +1000, Lawrence Stewart wrote:
> Hi Jason,
> 
> On 09/20/11 14:27, Jason Hellenthal wrote:
> >
> > On stable/8 as of the date of this message when attempting the following
> > configuration the sysctl MIB net.inet.tcp.cc.algorithm is not available
> > for /etc/sysctl.conf to tune for whatever reason.
> >
> > /boot/loader.conf:
> > h_ertt_load="YES"
> > cc_vegas_load="YES"
> >
> > /etc/sysctl.conf:
> > net.inet.tcp.cc.algorithm=vegas
> >
> >
> > After boot the system still has the congestion algo set to 'newreno'
> 
> Does "sysctl net.inet.tcp.cc.available" after boot show only 'newreno' 
> in the list? Or is 'vegas' listed as well after 'newreno', even though 
> 'newreno' is listed by "sysctl net.inet.tcp.cc.algorithm"?

Only 'newreno'

> 
> > To get around this I had to load the above two modules at rc.local stage
> > of the boot and also tune the sysctl via this method.
> >
> >
> > Has anyone else seen this behavior with other congestion algo's ?
> >
> > Can any developer advise what is controlling this ?
> 
> hmm this smells like a bug in the ordering of module registration vs 
> framework init, as I certainly intended that the code work in the way 
> you tried to set it up.

Yes that is what I was thinking but have not had the time to
specifically track it down.

> 
>  From sys/netinet/cc/cc_module.h, you can see that CC modules attach at 
> SI_SUB_PROTO_IFATTACHDOMAIN stage with order SI_ORDER_ANY.
> 
>  From sys/netinet/cc/cc.c, "SYSINIT(cc, SI_SUB_PROTO_IFATTACHDOMAIN, 
> SI_ORDER_FIRST, cc_init, NULL);", so the framework is supposed to 
> initialise at the same kernel boot stage as algorithm modules, but 
> before any modules do.
> 
> I don't see any obvious problems with the current code, but will try 
> reproduce here and follow up with my results.

Thank you.

> 
> Cheers,
> Lawrence
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: h_ertt cc_vegas loader.conf interaction on stable/8

[Jason Hellenthal]

On Wed, Sep 21, 2011 at 02:08:33PM +1000, Lawrence Stewart wrote:
> On 09/21/11 13:32, Jason Hellenthal wrote:
> >
> > Hi Larence,
> >
> > On Wed, Sep 21, 2011 at 12:39:28PM +1000, Lawrence Stewart wrote:
> >> Hi Jason,
> >>
> >> On 09/20/11 14:27, Jason Hellenthal wrote:
> >>>
> >>> On stable/8 as of the date of this message when attempting the following
> >>> configuration the sysctl MIB net.inet.tcp.cc.algorithm is not available
> >>> for /etc/sysctl.conf to tune for whatever reason.
> >>>
> >>> /boot/loader.conf:
> >>> h_ertt_load="YES"
> >>> cc_vegas_load="YES"
> >>>
> >>> /etc/sysctl.conf:
> >>> net.inet.tcp.cc.algorithm=vegas
> >>>
> >>>
> >>> After boot the system still has the congestion algo set to 'newreno'
> >>
> >> Does "sysctl net.inet.tcp.cc.available" after boot show only 'newreno'
> >> in the list? Or is 'vegas' listed as well after 'newreno', even though
> >> 'newreno' is listed by "sysctl net.inet.tcp.cc.algorithm"?
> >
> > Only 'newreno'
> 
> Ok, definitely a bug then. Should be simple to reproduce, so I'll track 
> it down and send through a patch for testing when I've got something.
> 

Alright, Ill await the patch for testing.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: re unix browser problem

[Jason Hellenthal]

On Sat, Oct 15, 2011 at 02:39:43PM +0200, kapral wrote:
> it might be caused by insecure dns ipv4 because this domain le100 resolvs
> for ip that belong to seedo not to google i dont know i fought seedo is not
> owned by google but i am a newbie sorry for a problem

I would take a educated guess that your search provideer in FF is
Google. And when you open a new browser window and just start to type
something within the search box is when your seeing this traffic occur.
This is traffic you are seeing from search suggestions. If you do not
want to see that traffic then turn off search suggestions and continue
on because as someone else already noted this is not a FreeBSD problem.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: re unix browser problem

[Jason Hellenthal]

On Sat, Oct 15, 2011 at 04:04:43PM +0200, kapral wrote:
> On Sat, 15 Oct 2011 09:46:57 -0400, Jason Hellenthal 
> wrote:
> > On Sat, Oct 15, 2011 at 02:39:43PM +0200, kapral wrote:
> >> it might be caused by insecure dns ipv4 because this domain le100
> resolvs
> >> for ip that belong to seedo not to google i dont know i fought seedo is
> >> not
> >> owned by google but i am a newbie sorry for a problem
> > 
> > I would take a educated guess that your search provideer in FF is
> > Google. And when you open a new browser window and just start to type
> > something within the search box is when your seeing this traffic occur.
> > This is traffic you are seeing from search suggestions. If you do not
> > want to see that traffic then turn off search suggestions and continue
> > on because as someone else already noted this is not a FreeBSD problem.
> no the same happends when i type in konquerror and epifany so it is a bsd
> problem or rather browsers problem the only browser thet dont have this
> problem is lynx all other have it in FreeBSD and Open BSD i had this
> connection to 1e100.net this domains dont resolvs via nslookup i dont know
> what is going on but the connection is from my port 21131 to www port
> foreign host there shouldn't be this connection because i use blank page as
> start page and dont use a search provider in other browsers

This is not a problem... This is called search suggestions and like I
said turn them off and you wont see this happening.

> 
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn commit: r226946 - stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Jason Hellenthal]

On Sun, Oct 30, 2011 at 10:43:47PM +0100, Martin Matuska wrote:
> On 30. 10. 2011 22:34, Jason Hellenthal wrote:
> > On Sun, Oct 30, 2011 at 09:03:12PM +, Martin Matuska wrote:
> >> Author: mm
> >> Date: Sun Oct 30 21:03:12 2011
> >> New Revision: 226946
> >> URL: http://svn.freebsd.org/changeset/base/226946
> >>
> >>
> >> Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c
> >> ==
> >> --- stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c   
> >> Sun Oct 30 21:02:01 2011(r226945)
> >> +++ stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c   
> >> Sun Oct 30 21:03:12 2011(r226946)
> >> @@ -21,6 +21,9 @@
> >>  /*
> >>   * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights 
> >> reserved.
> >>   */
> >> +/*
> >> + * Copyright 2011 Nexenta Systems, Inc.  All rights reserved.
> >> + */
> >>  
> > With (c) being a literal copyright symbol it seems to be missing above.
> 
> Hi Jason,
> 
> this is a 1:1 upstream merge:
> http://hg.openindiana.org/upstream/illumos/illumos-gate/file/205481e35e49/usr/src/uts/common/fs/zfs/dmu_tx.c
> 
> If you don't like it you can try to contact Illumos and/or Nexenta ;-)
> 

Haha ok, I will get right on that ;). Thought this was just added to
that that file.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building servers this weekend. Recommendations?

[Jason Hellenthal]

On Sun, Nov 13, 2011 at 07:24:51PM +, Matthew Seaman wrote:
> On 13/11/2011 18:51, Brett Glass wrote:
> > I need to build up some new servers this weekend, and my first choice
> > for the OS would be FreeBSD 9.0-RC2 if it were available. Alas, it
> > isn't, and there's no sign of when it's coming (neither the Release
> > Engineering page or the Wiki is anywhere near up to date). RC1 has a few
> > bugs that I'd like to avoid, as does 8.2-RELEASE. Recommendations?
> 
> It's here already:
> 
> maggot:~:% uname -a
> FreeBSD maggot.black-earth.co.uk 9.0-RC2 FreeBSD 9.0-RC2 #1: Sat Nov 12
> 01:06:59 GMT 2011
> r...@maggot.black-earth.co.uk:/usr/obj/usr/src/sys/MAGGOT  amd64
> 
> Don't know about iso images or the like: this was upgraded from -RC1 by
> compiling sources.
> 

Don't know why you would go with 9.0 on a new server but ok. It's not that hard 
to build up your own ISO via the process laid out in the docs. make realease is 
pretty nice.

Tweak as neccesary...

#!/bin/sh

trap 'exit 1' 2

VERSION=8.1-STABLE
BRANCH="stable/8"
SVNVER=$(svnversion /usr/src)
RELNAME=${VERSION}-r${SVNVER}
THISBUILD=${RELNAME} ;export THISBUILD
MAKEOBJDIRPREFIX=/usr/obj/RELEASE ;export MAKEOBJDIRPREFIX
KERNELS=SH4500 ;export KERNELS
NUMCPUS=$(($(sysctl -n kern.smp.cpus)*2+(8)))

cd /usr/src/release

nice make release CHROOTDIR=/usr/obj/RELEASE BUILDNAME=${THISBUILD} \
  SVNROOT=file:///exports/nsvn SVNBRANCH=${BRANCH} EXTSRCDIR=/usr/src \
  NOPORTS=YES NODOCS=YES EXTPORTSDIR=/usr/ports EXTDOCDIR=/usr/doc \
  MAKE_ISOS=YES
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: swi4: clock taking 40% cpu?!?

[Jason Hellenthal]

On Thu, Dec 15, 2011 at 12:51:28PM -0800, Doug Barton wrote:
> Howdy,
> 
> Web server under heavy'ish load (7 on a 2 cpu system) running
> 8.2-RELEASE-p4 i386 I'm seeing this:
> 
> PID USERNAME PRI NICE   SIZERES STATE   C   TIME   WCPU COMMAND
> 12  root -32- 0K   112K WAIT0 129:01 39.99% {swi4: clock}
> 
> Any ideas why the clock should be taking so much cpu? HZ=100 if that
> makes a difference ...
> 
> 

Without NTPd running test the following.


apply "/usr/bin/time -ph sleep %1" 300 600 900

If the results are skewed quite a bit then your system may benefit from a 
different HZ than what you have set. I have seen systems that require a HZ of 
350 and as weird as it sounds NTPd may be tasting the clock too much just to 
try and keep time.

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: swi4: clock taking 40% cpu?!?

[Jason Hellenthal]

Should also mention the kern.sched may be playing a part in this too.

On Sat, Dec 17, 2011 at 11:20:29AM -0500, Jason Hellenthal wrote:
> 
> 
> On Thu, Dec 15, 2011 at 12:51:28PM -0800, Doug Barton wrote:
> > Howdy,
> > 
> > Web server under heavy'ish load (7 on a 2 cpu system) running
> > 8.2-RELEASE-p4 i386 I'm seeing this:
> > 
> > PID USERNAME PRI NICE   SIZERES STATE   C   TIME   WCPU COMMAND
> > 12  root -32- 0K   112K WAIT0 129:01 39.99% {swi4: clock}
> > 
> > Any ideas why the clock should be taking so much cpu? HZ=100 if that
> > makes a difference ...
> > 
> > 
> 
> Without NTPd running test the following.
> 
> 
> apply "/usr/bin/time -ph sleep %1" 300 600 900
> 
> If the results are skewed quite a bit then your system may benefit from a 
> different HZ than what you have set. I have seen systems that require a HZ of 
> 350 and as weird as it sounds NTPd may be tasting the clock too much just to 
> try and keep time.
> 
> -- 
> ;s =;

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn commit: r229497 - in stable/8/sys: conf modules modules/ipfw netinet/ipfw

[Jason Hellenthal]

After this change I am recieving the attached error log.

On Wed, Jan 04, 2012 at 04:20:56PM +, John Baldwin wrote:
> Author: jhb
> Date: Wed Jan  4 16:20:55 2012
> New Revision: 229497
> URL: http://svn.freebsd.org/changeset/base/229497
> 
> Log:
>   MFC 225518,225793,227085:
>   Allow the ipfw.ko module built with a kernel to honor any options defined
>   in the kernel config.  This more closely matches the behavior of other
>   modules which inherit configuration settings from the kernel configuration
>   during a kernel + modules build.
>   
>   Do not try to build the module in case of no INET support but keep #error
>   calls for now in case we would compile it into the kernel.
>   
>   While here garbage collect unneeded opt_*.h includes.
>   opt_ipdn.h is not used anywhere but we need to leave the DUMMYNET
>   entry in options for conditional inclusion in kernel so keep the
>   file with the same name.
> 
> Modified:
>   stable/8/sys/modules/Makefile
>   stable/8/sys/modules/ipfw/Makefile
>   stable/8/sys/netinet/ipfw/ip_fw2.c
>   stable/8/sys/netinet/ipfw/ip_fw_dynamic.c
>   stable/8/sys/netinet/ipfw/ip_fw_log.c
>   stable/8/sys/netinet/ipfw/ip_fw_pfil.c
>   stable/8/sys/netinet/ipfw/ip_fw_sockopt.c
>   stable/8/sys/netinet/ipfw/ip_fw_table.c
> Directory Properties:
>   stable/8/sys/   (props changed)
>   stable/8/sys/amd64/include/xen/   (props changed)
>   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
>   stable/8/sys/conf/ldscript.mips.octeon1.32   (props changed)
>   stable/8/sys/conf/ldscript.mips.octeon1.64   (props changed)
>   stable/8/sys/contrib/dev/acpica/   (props changed)
>   stable/8/sys/contrib/pf/   (props changed)
> 
> Modified: stable/8/sys/modules/Makefile
> ==
> --- stable/8/sys/modules/Makefile Wed Jan  4 16:07:16 2012
> (r229496)
> +++ stable/8/sys/modules/Makefile Wed Jan  4 16:20:55 2012
> (r229497)
> @@ -134,7 +134,7 @@ SUBDIR=   ${_3dfx} \
>   ${_io} \
>   ipdivert \
>   ${_ipfilter} \
> - ipfw \
> + ${_ipfw} \
>   ipfw_nat \
>   ${_ipmi} \
>   ip_mroute_mod \
> @@ -366,6 +366,10 @@ _random= random
>  _ipfilter=   ipfilter
>  .endif
>  
> +.if ${MK_INET_SUPPORT} != "no" || defined(ALL_MODULES)
> +_ipfw=   ipfw
> +.endif
> +
>  .if ${MK_NETGRAPH} != "no" || defined(ALL_MODULES)
>  _netgraph=   netgraph
>  .endif
> 
> Modified: stable/8/sys/modules/ipfw/Makefile
> ==
> --- stable/8/sys/modules/ipfw/MakefileWed Jan  4 16:07:16 2012
> (r229496)
> +++ stable/8/sys/modules/ipfw/MakefileWed Jan  4 16:20:55 2012
> (r229497)
> @@ -8,7 +8,7 @@ KMOD= ipfw
>  SRCS=ip_fw2.c ip_fw_pfil.c
>  SRCS+=   ip_fw_dynamic.c ip_fw_log.c
>  SRCS+=   ip_fw_sockopt.c ip_fw_table.c
> -SRCS+=   opt_inet6.h opt_ipsec.h
> +SRCS+=   opt_inet.h opt_inet6.h opt_ipdivert.h opt_ipfw.h opt_ipsec.h
>  
>  CFLAGS+= -DIPFIREWALL
>  CFLAGS+= -I${.CURDIR}/../../contrib/pf
> @@ -22,6 +22,10 @@ CFLAGS+= -I${.CURDIR}/../../contrib/pf
>  #
>  
>  .if !defined(KERNBUILDDIR)
> +.if ${MK_INET_SUPPORT} != "no"
> +opt_inet.h:
> + echo "#define INET 1" > ${.TARGET}
> +.endif
>  .if ${MK_INET6_SUPPORT} != "no"
>  opt_inet6.h:
>   echo "#define INET6 1" > ${.TARGET}
> 
> Modified: stable/8/sys/netinet/ipfw/ip_fw2.c
> ==
> --- stable/8/sys/netinet/ipfw/ip_fw2.cWed Jan  4 16:07:16 2012
> (r229496)
> +++ stable/8/sys/netinet/ipfw/ip_fw2.cWed Jan  4 16:20:55 2012
> (r229497)
> @@ -30,15 +30,12 @@ __FBSDID("$FreeBSD$");
>   * The FreeBSD IP packet firewall, main file
>   */
>  
> -#if !defined(KLD_MODULE)
>  #include "opt_ipfw.h"
>  #include "opt_ipdivert.h"
> -#include "opt_ipdn.h"
>  #include "opt_inet.h"
>  #ifndef INET
>  #error IPFIREWALL requires INET.
>  #endif /* INET */
> -#endif
>  #include "opt_inet6.h"
>  #include "opt_ipsec.h"
>  
> 
> Modified: stable/8/sys/netinet/ipfw/ip_fw_dynamic.c
> ==
> --- stable/8/sys/netinet/ipfw/ip_fw_dynamic.c Wed Jan  4 16:07:16 2012
> (r229496)
> +++ stable/8/sys/netinet/ipfw/ip_fw_dynamic.c Wed Jan  4 16:20:55 2012
> (r229497)
> @@ -33,17 +33,12 @@ __FBSDID("$FreeBSD$");
>   * Dynamic rule support for ipfw
>   */
>  
> -#if !defined(KLD_MODULE)
>  #include "opt_ipfw.h"
> -#include "opt_ipdivert.h"
> -#include "opt_ipdn.h"
>  #include "opt_inet.h"
>  #ifndef INET
>  #error IPFIREWALL requires INET.
>  #endif /* INET */
> -#endif
>  #include "opt_inet6.h"
> -#include "opt_ipsec.h"
>  
>  #include 
>  #include 
> 
> Modified: stable/8/sys/netinet/ipfw/ip_fw_log.c
> ==
> --- stable/8/sys/netinet/ipfw/ip_fw_log.c Wed Jan 

Re: FreeBSD 8.2-stable: devd fails to restart

[Jason Hellenthal]

Just because of what I read already is pretty terse I am top-posting for
a reason.

$ su -
# /etc/rc.d/devd stop
# pgrep -l devd (This should show nothing if so kill the results)
# /sbin/devd -D -d  (Paste the results)


On Fri, Feb 03, 2012 at 08:41:10PM +0100, Torfinn Ingolfsen wrote:
> On Fri, 03 Feb 2012 08:34:10 +0300
> Sergey Kandaurov  wrote:
> 
> > Please apply this patch and report how it goes for you.
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/devd.diff?r1=1.12;r2=1.13
> > 
> > This is not in 8-STABLE yet.
> 
> It looks like it (or almost the same) is here already:
> root@kg-v2# more /etc/rc.d/devd
> #!/bin/sh
> #
> # $FreeBSD: src/etc/rc.d/devd,v 1.11.2.2 2011/04/29 20:31:52 dougb Exp $
> #
> 
> # PROVIDE: devd
> # REQUIRE: netif network_ipv6
> # BEFORE: NETWORKING mountcritremote
> # KEYWORD: nojail shutdown
> 
> . /etc/rc.subr
> 
> name="devd"
> rcvar=`set_rcvar`
> command="/sbin/${name}"
> 
> start_precmd=${name}_prestart
> stop_precmd=find_pidfile
> 
> find_pidfile()
> {
> if get_pidfile_from_conf pid-file /etc/devd.conf; then
> pidfile="$_pidfile_from_conf"
> else
> pidfile="/var/run/${name}.pid"
> fi
> }
> 
> devd_prestart ()
> {
> find_pidfile
> 
> # If devd is disabled, turn it off in the kernel to avoid memory 
> leaks.
> if ! checkyesno ${rcvar}; then
> $SYSCTL hw.bus.devctl_disable=1
> fi
> }
> 
> load_rc_config $name
> run_rc_command "$1"
> 
> HTH
> -- 
> Torfinn
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ld: kernel.debug: Not enough room for program headers

[Jason Hellenthal]

On Sat, Feb 04, 2012 at 10:57:40AM -0700, Warren Block wrote:
> Trying to build 8-stable i386 for the last couple of days gives this 
> error when building the kernel:
> 
> /usr/local/libexec/ccache/world/cc -c -O -pipe -march=prescott -std=c99 -g 
> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
> -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
> opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
> --param large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  vers.c
> linking kernel.debug
> ld: kernel.debug: Not enough room for program headers (allocated 5, need 6)
> ld: final link failed: Bad value
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> 
> 
> Use (or not) of ccache doesn't change the error.
> 
> The kernel config file is
> 
> include GENERIC
> nocpu   I486_CPU
> ident   LIGHTNING
> 
> nooptions   INET6
> nooptions   WITNESS
> nooptions   INVARIANTS
> 
> nodeviceeisa
> 
> nodevicefdc
> 
> device  ahci
> #optionsATA_CAM
> ...
> (followed by a lot of nodevice and nooption entries to disable unneeded 
> stuff from GENERIC).

Not sure if this has anything to do with it but
(/usr/local/libexec/ccache/world/cc)

My last kernel build completed perfectly (...completed on Sat Feb  4
11:18:21 EST 2012)

You might have to clean your cache.

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ld: kernel.debug: Not enough room for program headers

[Jason Hellenthal]

On Sat, Feb 04, 2012 at 10:57:40AM -0700, Warren Block wrote:
> Trying to build 8-stable i386 for the last couple of days gives this 
> error when building the kernel:
> 
> /usr/local/libexec/ccache/world/cc -c -O -pipe -march=prescott -std=c99 -g 
> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
> -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
> opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
> --param large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  vers.c
> linking kernel.debug
> ld: kernel.debug: Not enough room for program headers (allocated 5, need 6)
> ld: final link failed: Bad value
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> 
> 
> Use (or not) of ccache doesn't change the error.
> 
> The kernel config file is
> 
> include GENERIC
> nocpu   I486_CPU
> ident   LIGHTNING
> 
> nooptions   INET6
> nooptions   WITNESS
> nooptions   INVARIANTS
> 
> nodeviceeisa
> 
> nodevicefdc
> 
> device  ahci
> #optionsATA_CAM
> ...
> (followed by a lot of nodevice and nooption entries to disable unneeded 
> stuff from GENERIC).

Aslso for reference:

Path: /usr/src
Working Copy Root Path: /usr/src
URL: file:///exports/nsvn/stable/8
Repository Root: file:///exports/nsvn
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 230983
Node Kind: directory
Schedule: normal
Last Changed Author: mav
Last Changed Rev: 230983
Last Changed Date: 2012-02-04 10:43:16 -0500 (Sat, 04 Feb 2012)

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ld: kernel.debug: Not enough room for program headers

[Jason Hellenthal]

On Sat, Feb 04, 2012 at 10:48:16AM -0800, Jeremy Chadwick wrote:
> On Sat, Feb 04, 2012 at 10:57:40AM -0700, Warren Block wrote:
> > Trying to build 8-stable i386 for the last couple of days gives this
> > error when building the kernel:
> > 
> > /usr/local/libexec/ccache/world/cc -c -O -pipe -march=prescott -std=c99 -g 
> > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> > -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
> > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
> > opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
> > --param large-function-growth=1000  -mno-align-long-strings 
> > -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> > -mno-sse3 -ffreestanding -fstack-protector -Werror  vers.c
> > linking kernel.debug
> > ld: kernel.debug: Not enough room for program headers (allocated 5, need 6)
> > ld: final link failed: Bad value
> > *** Error code 1
> > 1 error
> > *** Error code 2
> > 1 error
> > *** Error code 2
> > 1 error
> 
> The freebsd-stable mailing list has been filled with tinderbox failures
> for this exact problem with the LINT kernel, and it appears to be
> specific to RELENG_8 on i386.
> 
> http://lists.freebsd.org/pipermail/freebsd-stable/2012-February/thread.html
> 
> Start from the bottom and search upwards for the string:
> "[releng_8 tinderbox] failure on i386/i386"
> 
> Point being: the problem is not you.
> 

This is why I don't like ccache. Technically the problem is there but
also coexists within the source itself. For whatever reason I would
believe a cached copy of already built source is having some collisions.
As already stated "NO CCACHE" the kernel can be built with what I
posted on three different machines.

-- 
;s =;


pgpYIoGesw7M8.pgp
Description: PGP signature

Re: ld: kernel.debug: Not enough room for program headers

[Jason Hellenthal]

On Sat, Feb 04, 2012 at 12:54:58PM -0700, Warren Block wrote:
> On Sat, 4 Feb 2012, Jason Hellenthal wrote:
> 
> > On Sat, Feb 04, 2012 at 10:48:16AM -0800, Jeremy Chadwick wrote:
> >> On Sat, Feb 04, 2012 at 10:57:40AM -0700, Warren Block wrote:
> >>> Trying to build 8-stable i386 for the last couple of days gives this
> >>> error when building the kernel:
> >>>
> >>> /usr/local/libexec/ccache/world/cc -c -O -pipe -march=prescott -std=c99 
> >>> -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> >>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> >>> -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
> >>> -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
> >>> -include opt_global.h -fno-common -finline-limit=8000 --param 
> >>> inline-unit-growth=100 --param large-function-growth=1000  
> >>> -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow 
> >>> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror  
> >>> vers.c
> >>> linking kernel.debug
> >>> ld: kernel.debug: Not enough room for program headers (allocated 5, need 
> >>> 6)
> >>> ld: final link failed: Bad value
> >>> *** Error code 1
> >>> 1 error
> >>> *** Error code 2
> >>> 1 error
> >>> *** Error code 2
> >>> 1 error
> >>
> >> The freebsd-stable mailing list has been filled with tinderbox failures
> >> for this exact problem with the LINT kernel, and it appears to be
> >> specific to RELENG_8 on i386.
> >>
> >> http://lists.freebsd.org/pipermail/freebsd-stable/2012-February/thread.html
> >>
> >> Start from the bottom and search upwards for the string:
> >> "[releng_8 tinderbox] failure on i386/i386"
> >>
> >> Point being: the problem is not you.
> >>
> >
> > This is why I don't like ccache. Technically the problem is there but
> > also coexists within the source itself. For whatever reason I would
> > believe a cached copy of already built source is having some collisions.
> > As already stated "NO CCACHE" the kernel can be built with what I
> > posted on three different machines.
> 
> But it still does (did) not build here with NOCCACHE set, so it's not 
> a ccache problem.

I have seen ccache before run anyway even though .if statements are
within make.conf to prevent it. It was something to do with make and
friends built from world with ccache and after it would continue to use
ccache regardless. This can be verified by watching the cache hits and
misses during a compile with NOCCACHE set. Its tough to revert from
this but involves removing ccache/distcc from the system.

-- 
;s =;


pgpIOevQmhCmD.pgp
Description: PGP signature

Re: ld: kernel.debug: Not enough room for program headers

[Jason Hellenthal]

On Sat, Feb 04, 2012 at 05:18:18PM -0700, Warren Block wrote:
> On Sat, 4 Feb 2012, Jason Hellenthal wrote:
> 
> > On Sat, Feb 04, 2012 at 12:54:58PM -0700, Warren Block wrote:
> >> But it still does (did) not build here with NOCCACHE set, so it's not
> >> a ccache problem.
> >
> > I have seen ccache before run anyway even though .if statements are
> > within make.conf to prevent it. It was something to do with make and
> > friends built from world with ccache and after it would continue to use
> > ccache regardless. This can be verified by watching the cache hits and
> > misses during a compile with NOCCACHE set. Its tough to revert from
> > this but involves removing ccache/distcc from the system.
> 
> Interesting.  Just for fun, I tried that, and the ccache stats didn't 
> change.

Wierd. I dont know what to say to that and out of ideas at this point.

Can say though that FreeBSD 8.2-STABLE #1 r230983M: Sat Feb  4 11:05:52
EST 2012 this one did compile cleanly here. usr/obj was clean when
built and have build logs for every batch of 10 revisions for the past 6
months with no errors shown.

-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"