Re: devd based AUTOMOUNTER
Hi, I have created a PORT at last, its in the 'port' directory in the usual place: https://github.com/vermaden/automount/ Its my first PORT so feel free to bash me about my mistakes ;) After latest 'commits' I think that its ready for day-to-day use. To make 'full advantage' of *automount* install these ports: sysutils/ntfsprogs sysutils/fusefs-ntfs sysutils/fusefs-ext4fuse sysutils/fusefs-exfat I will try to add these ports as OPTIONS in the Makefile later. I will have to think about creating a man page through ... Feel free to submit Your propositions about next changes/development, because I think that I already created everything 'I' needed. Regards, vermaden --- ___ 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: "File too large" error when appending to a file of 130 MB
Hi Phil, On Tue, Feb 21, 2012 at 02:24:39PM +1300, Phil Murray wrote: > > On 20/02/2012, at 10:36 AM, Jeremie Le Hen wrote: > > > > I have a problem with procmail which gets a "File too large" error when > > it tries to write at the end of some mailbox file. > > Is procmail running from Postfix (or some other MTA)? I've hit this > problem where Postfix has set a filesize ulimit, which all the scripts > spawned from Postfix will inherit. > > In my case, I had a script that was hitting the filesize limit trying > to log it's results to a logfile that doesn't get rotated. I imagine > the same thing could happen with procmail, if postfix was calling it. Yes that was the problem indeed. Someone already contacted me (privately, but I didn't notice at that time) pointing out the problem. I've disabled the mailbox_size_limit in Postfix and the problem vanished. Thanks for your help. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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"
[CFT] modular kernel config
Hi, I created a kernel config for i386/amd64 (should work on -current and 9.x) and a suitable loader.conf which: - tries to provide as much features as GENERIC (I lost one or two disk controllers, they are not available as a module... or I didn't find them) - incorporates some more features based upon a poll on stable@ (see below) - loads as much as possible as a module I've compile-tested them on i386 and amd64, but I didn't had time yet to give it a try on a spare machine. I may get some time next week to test (i386 only). It would be nice if someone could help testing: - compile the kernel - make _sure_ you have a way to recover the system in case the new kernel+loader.conf fails - verify that the example loader.conf contains all devices which are important for you - copy the example loader.conf to /boot/loader.conf - give it a try You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I didn't provide direct links for eqch one on purpose. If you do not know how to recover a system with an unsuitable loader.conf, don't give this a try (you could check a diff between GENERIC and SMALL, and make sure all removed devices which are imporant for you are in the loader.conf). They should work on -current and on 9.x, for 8.x I'm not sure if it woll work without removing some stuff (GENERIC on 8.x comes without some more debugging options, make sure you don't get surprised by them, but those may not be the only differences). I didn't use the name MODULAR on purpose, I've chosen a name where the first letter does not yet exist in the kernel config directory, to make tab-completion more easy. If you are not happy with the name, keep your opinion for yourself please, until after you tested this on a (maybe virtual) system. The loader.conf was generated with a script from a diff between GENERIC and SMALL, if there's a name mismatch between the config-name and the module-name, the script may have missed the module (I added some missing sound modules, but I may have overlooked something). You better double-check before giving it a try. The loader.conf is also supposed to disable some features (at the end of the file) which are new compared to what is in GENERIC, if the particular feature could cause a change in behavior. The new stuff in the kernel config compared to GENERIC is (in order of number of requests from users): - IPSEC (+ device enc + IPSEC_NAT_T) - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) - BPF_JITTER In the poll there where some more options requested, but most of them can be handled via the loader or sysctl (e.g. the firewalls can be loaded as modules). For some of them I added some comments at the end of the SMALL config to make it more easy to find the correct way of configuring them. Doc-committers may want to have a look, maybe there's an opportunity to improve existing documentation. I'm interested in success reports, failure reports, and reports about missing stuff in loader.conf (mainly compared to the devices available in GENERIC, but missing stuff which could help getting a system installed and booted is welcome even if what you propose is not in GENERIC). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: ZFS + nullfs + Linuxulator = panic?
On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote:
> On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
>> On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
>>
>>> On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
> On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
>> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel,
>> last built 2012-02-08). It will panic during the daily periodic scripts
>> that run at 3am. Here is the most recent panic message:
>>
>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 0; apic id = 00
>> instruction pointer = 0x20:0x8069d266
>> stack pointer = 0x28:0xff8094b90390
>> frame pointer = 0x28:0xff8094b903a0
>> code segment= base 0x0, limit 0xf, type 0x1b
>> = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags= resume, IOPL = 0
>> current process = 72566 (ps)
>> trap number = 9
>> panic: general protection fault
>> cpuid = 0
>> KDB: stack backtrace:
>> #0 0x8062cf8e at kdb_backtrace+0x5e
>> #1 0x805facd3 at panic+0x183
>> #2 0x808e6c20 at trap_fatal+0x290
>> #3 0x808e715a at trap+0x10a
>> #4 0x808cec64 at calltrap+0x8
>> #5 0x805ee034 at fill_kinfo_thread+0x54
>> #6 0x805eee76 at fill_kinfo_proc+0x586
>> #7 0x805f22b8 at sysctl_out_proc+0x48
>> #8 0x805f26c8 at sysctl_kern_proc+0x278
>> #9 0x8060473f at sysctl_root+0x14f
>> #10 0x80604a2a at userland_sysctl+0x14a
>> #11 0x80604f1a at __sysctl+0xaa
>> #12 0x808e62d4 at amd64_syscall+0x1f4
>> #13 0x808cef5c at Xfast_syscall+0xfc
>
> Please look up the line number for the fill_kinfo_thread+0x54.
Is there a way for me to do this from the above information? As
I said in the original message, I failed to get a crash dump after
reboot (because, it turns out, I hadn't set up my gmirror swap device
properly). Alas, with the latest panic, it appears to have hung[1]
during the "Dumping" phase, so it looks like I won't get a saved crash
dump this time, either. :-(
>>>
>>> Load the kernel.debug into kgdb, and from there do
>>> "list *fill_kinfo_thread+0x54".
>>
>>
>> gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>> (kgdb) list *fill_kinfo_thread+0x54
>> 0x805ee034 is in fill_kinfo_thread
>> (/usr/src/sys/kern/kern_proc.c:854).
>> 849 thread_lock(td);
>> 850 if (td->td_wmesg != NULL)
>> 851 strlcpy(kp->ki_wmesg, td->td_wmesg,
>> sizeof(kp->ki_wmesg));
>> 852 else
>> 853 bzero(kp->ki_wmesg, sizeof(kp->ki_wmesg));
>> 854 strlcpy(kp->ki_ocomm, td->td_name, sizeof(kp->ki_ocomm));
>> 855 if (TD_ON_LOCK(td)) {
>> 856 kp->ki_kiflag |= KI_LOCKBLOCK;
>> 857 strlcpy(kp->ki_lockname, td->td_lockname,
>> 858 sizeof(kp->ki_lockname));
>> (kgdb)
>
> This is indeed strange. It can only occur if td pointer is damaged.
>
> Please, try to get a core and at least print the content of *td in this case.
Alas, I was unable to obtain a crash dump (or even a panic) last night, but I
have learned more about the circumstances that lead to this panic.
In attempting to find a workaround for this panic (because having nightly
backups instead of panics is a good thing:) I discovered two successful
approaches. In the original situation that causes a reliable panic I have a
daemonised Tivoli "dsmc schedule" job running. This communicates with the
Tivoli TSM server to determine when it should run its scheduled backup. When
the backup is run, there is defined in a Tivoli client config file (in
/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys) a preschedulecmd and a
postschedulecmd, which are /usr/local/bin/make_zfs_backup_snapshot and
/usr/local/bin/remove_zfs_backup_snapshot respectively. The preschedulecmd
script (run prior to the actual backup) basically makes ZFS snapshots of all
filesets and nullfs-mounts them under /backup. It then creates
/compat/linux/etc/mtab to list these nullfs filesystems as ext2 file systems,
so that the Tivoli backup client can know about them to back them up. The
postsc
"who /var/log/utx.log" broken in 9.0-RELEASE?
Hi, According to the who(1) manpage in 9.0-RELEASE, "who /var/log/utx.log" should be roughly similar to "who /var/log/wtmp" in 8.whever (and earlier). I'm getting this on multiple 9.0-RELEASE systems: janm@mlb-primary: log $ who /var/log/utx.log who: /var/log/utx.log: Inappropriate file type or format Is the manpage wrong? Thanks, Jan. ___ 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"
ssh-add echos passphrase
Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? FreeBSD lightning 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Tue Feb 21 15:37:08 MST 2012 root@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 ___ 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: ssh-add echos passphrase
On 02/21/2012 16:16, Warren Block wrote: > Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? No. Are you sure that you're running the agent before you ssh-add? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: ssh-add echos passphrase
On Tue, 21 Feb 2012, Doug Barton wrote: On 02/21/2012 16:16, Warren Block wrote: Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? No. Are you sure that you're running the agent before you ssh-add? 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Tue Feb 21 # pkill ssh-agent % ssh-add ~/keyfile Could not open a connection to your authentication agent. % eval `ssh-agent -c` Agent pid 2658 % ssh-add ~/keyfile Enter passphrase for /home/wblock/keyfile: abc123 Another system has -stable from January 13 and works as expected (no passphrase echo). ___ 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: Reducing the need to compile a custom kernel
Hi! Finally someone thought about this! My 5 cents: IPFIREWALL_FORWARD <- no comment)) options VIMAGE <- not yet production ready, but keep in mind it Forgot this two very usefull options: options RACCT <- resource limits for jail and etc. options RCTL<- resource limits for jail and etc. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Reducing-the-need-to-compile-a-custom-kernel-tp5472542p5504065.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: [CFT] modular kernel config
Sorry, but for loader.conf you need use 'load' instead of 'enable' sed -e "s/enable/load/" loader.conf -- View this message in context: http://freebsd.1045724.n5.nabble.com/CFT-modular-kernel-config-tp5502195p5504219.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: ssh-add echos passphrase
On Tue, 21 Feb 2012, Warren Block wrote: Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? FreeBSD lightning 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Tue Feb 21 15:37:08 MST 2012 root@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 After backdating a few days with no change, then csupping back to RELENG-8, ssh-add is back to normal. Wish I had an idea why. ___ 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"
