Re: CARP on -CURRENT
On 2 February 2012 04:26, Andrew Hobbs wrote:
> I much appreciate the responses and I was able to get CARP functioning using
> the new ifconfig syntax under -CURRENT. Having done that, CARP is now acting
> as it should, though now I have a new challenge with devd and automatic
> firing of scripts during CARP failover. It appears that the documented method
> of doing this at http://www.freebsd.org/doc/handbook/disks-hast.html no
> longer works with the suggested devd.conf setup;
> notify 30 {
> match "system" "IFNET";
> match "subsystem" "carp0";
> match "type" "LINK_UP";
> action "/usr/local/sbin/carp-hast-switch master";
> };
>
> notify 30 {
> match "system" "IFNET";
> match "subsystem" "carp0";
> match "type" "LINK_DOWN";
> action "/usr/local/sbin/carp-hast-switch slave";
>
> Is it likely that the triggers associated with CARP for devd have changed due
> to the recent new CARP overhaul? Does anyone know what the new triggers may
> be?
>
You will need to change this to something like (as taken from man carp):
match "system" "CARP";
match "subsystem" "[0-9]+@";
match "type""(MASTER|BACKUP)";
The subsystem now is generated as
snprintf(subsys, IFNAMSIZ+5, "%u@%s", sc->sc_vhid, sc->sc_carpdev->if_xname);
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
On Thu, Feb 02, 2012 at 08:46:47AM +0800, Paul Ambrose wrote: > Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 > box, system panic Unfortunately, you did not provided any details of the panic. Panic message and backtrace is the absolute minimum. pgpxg4eyJtcbA.pgp Description: PGP signature
Re: Smartmontools
In message , Scott Long writes : > > On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote: > > > Other than nooptions ATA_CAM, is there a fix or circumvention to allow > > smartmontools to work correctly under 9.0 and -CURRENT? > > > > slippy# smartctl -a /dev/ad0 > > smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) > > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > > > error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device > > Unable to get CAM device list > > /dev/ad0: Unable to detect device type > > Smartctl: please specify device type with the -d option. > > > > Use smartctl -h to get a usage summary > > > > slippy# > > > > > > I can't say for certain, but my guess is that you've been victimized by recen > t changes to CAM headers. Have you tried recompiling to get everything in sy > nc? Everything (kernel and userland) but smaartmontools (and other ports) has been rebuilt (two days ago). Rebuilding the port did the trick. Thanks. :) -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Smartmontools
On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote: > Other than nooptions ATA_CAM, is there a fix or circumvention to allow > smartmontools to work correctly under 9.0 and -CURRENT? > > slippy# smartctl -a /dev/ad0 > smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device > Unable to get CAM device list > /dev/ad0: Unable to detect device type > Smartctl: please specify device type with the -d option. > > Use smartctl -h to get a usage summary > > slippy# > > I can't say for certain, but my guess is that you've been victimized by recent changes to CAM headers. Have you tried recompiling to get everything in sync? Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Smartmontools
Other than nooptions ATA_CAM, is there a fix or circumvention to allow smartmontools to work correctly under 9.0 and -CURRENT? slippy# smartctl -a /dev/ad0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ad0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary slippy# -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/i386
TB --- 2012-02-01 22:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-02-01 22:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-02-01 22:20:00 - cleaning the object tree TB --- 2012-02-01 22:21:02 - cvsupping the source tree TB --- 2012-02-01 22:21:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-02-01 22:26:27 - building world TB --- 2012-02-01 22:26:27 - CROSS_BUILD_TESTING=YES TB --- 2012-02-01 22:26:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-01 22:26:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-01 22:26:27 - SRCCONF=/dev/null TB --- 2012-02-01 22:26:27 - TARGET=i386 TB --- 2012-02-01 22:26:27 - TARGET_ARCH=i386 TB --- 2012-02-01 22:26:27 - TZ=UTC TB --- 2012-02-01 22:26:27 - __MAKE_CONF=/dev/null TB --- 2012-02-01 22:26:27 - cd /src TB --- 2012-02-01 22:26:27 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 1 22:26:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 2 00:30:56 UTC 2012 TB --- 2012-02-02 00:30:56 - generating LINT kernel config TB --- 2012-02-02 00:30:56 - cd /src/sys/i386/conf TB --- 2012-02-02 00:30:56 - /usr/bin/make -B LINT TB --- 2012-02-02 00:30:57 - cd /src/sys/i386/conf TB --- 2012-02-02 00:30:57 - /usr/sbin/config -m LINT TB --- 2012-02-02 00:30:57 - building LINT kernel TB --- 2012-02-02 00:30:57 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 00:30:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 00:30:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 00:30:57 - SRCCONF=/dev/null TB --- 2012-02-02 00:30:57 - TARGET=i386 TB --- 2012-02-02 00:30:57 - TARGET_ARCH=i386 TB --- 2012-02-02 00:30:57 - TZ=UTC TB --- 2012-02-02 00:30:57 - __MAKE_CONF=/dev/null TB --- 2012-02-02 00:30:57 - cd /src TB --- 2012-02-02 00:30:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 2 00:30:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Feb 2 01:02:24 UTC 2012 TB --- 2012-02-02 01:02:24 - cd /src/sys/i386/conf TB --- 2012-02-02 01:02:24 - /usr/sbin/config -m LINT-NOINET TB --- 2012-02-02 01:02:24 - building LINT-NOINET kernel TB --- 2012-02-02 01:02:24 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 01:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 01:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 01:02:24 - SRCCONF=/dev/null TB --- 2012-02-02 01:02:24 - TARGET=i386 TB --- 2012-02-02 01:02:24 - TARGET_ARCH=i386 TB --- 2012-02-02 01:02:24 - TZ=UTC TB --- 2012-02-02 01:02:24 - __MAKE_CONF=/dev/null TB --- 2012-02-02 01:02:24 - cd /src TB --- 2012-02-02 01:02:24 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Feb 2 01:02:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Thu Feb 2 01:32:19 UTC 2012 TB --- 2012-02-02 01:32:19 - cd /src/sys/i386/conf TB --- 2012-02-02 01:32:19 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-02-02 01:32:19 - building LINT-NOINET6 kernel TB --- 2012-02-02 01:32:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 01:32:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 01:32:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 01:32:19 - SRCCONF=/dev/null TB --- 2012-02-02 01:32:19 - TARGET=i386 TB --- 2012-02-02 01:32:19 - TARGET_ARCH=i386 TB --- 2012-02-02 01:32:19 - TZ=UTC TB --- 2012-02-02 01:32:19 - __MAKE_CONF=/dev/null TB --- 2012-02-02 01:32:19 - cd /src TB --- 2012-02-02 01:32:19 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Feb 2 01:32:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Thu Feb 2 02:02:32 UTC 2012 TB --- 2012-02-02 02:02:32 - cd /src/sys/i386/conf TB --- 2012-02-02 02:02:32 - /usr/sbin/config -m LINT-NOIP TB --- 2012-02-02 02:02:32 - building LINT-NOIP kernel TB --- 2012-02-02 02:02:32 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 02:02:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 02:02:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 下午11:28，Konstantin Belousov 写道： > On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: >> ?? 2012??1??31?? 12:43??Kostik Belousov ?? >> > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: >> >> ?? 2012??1??30?? 2:36??Kostik Belousov ?? >> >> > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: >> >> >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current >> >> >> patched with pcid.2.patch? It works well without other issue and it >> >> >> seem the pcid patch >> >> >> does not affect other part of the kernel. The other one is Sandy >> >> > Athlons do not have PCID and probably will never implement it. They use >> >> > other tricks to get similar optimizations, transparently to the OS. >> >> > >> >> Just curious, is this AMD similar optimizations >> >> Address Space Number (ASN) and Global flag >> >> US Patent 6,604,187. >> >> http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html >> > This and the same-important next item 'The TLB Flush Filter' is what >> > I referred to. >> > >> >> I did not found anything about ASN in the AMD manual >> > It is a transparent optimization, which does not require any OS support. >> > Intel PCID is completely different, it shall be explicitely handled by OS. >> > It is some consequence of the nested pages support, AFAIU. >> > >> >> >> >> >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the >> >> >> pcid.2.patch seems >> >> >> dependent on AVX and XSAVE stuffs which is available on -current). But >> >> >> it hangs up just in a few minutes. I doubt the nvidia-driver which is >> >> >> not recompiled with >> >> >> patched kernel is the root, I will check this out later, but does >> >> >> anyone meet similar problem? >> >> > There are two many variations compared to the config I did tested. >> >> > I do not see anything obvious in the changes between HEAD and stable/9 >> >> > which could be blamed. Nvidia driver might be bigger suspect, but again, >> >> > I am not aware of anything wrong with it. >> >> > >> >> >> >> >> >> I have two question about the pcid.2.patch >> >> > >> >> > Item 2 is clean, I fixed it. >> >> > >> >> > For the item 1, I was only able to decipher the proposal to optimize >> >> > the global shootdown handler to restore the %cr3 with bit 64 set to not >> >> > invalidate current PCID. Is there some more changes ? >> >> > >> >> yes, that is what I meant. I was wondering using another way that each >> >> process has different >> >> pcid in each active processor, just as the freebsd mips and powerpc >> >> uses. But obviously this way >> >> is more friendly to non-pcid x86 processor. >> > Each vmspace (or pmap) has unique PCID with the patch, at least until >> > PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 >> > processes, so it is unlikely but possible event with the current settings. >> > >> Thank you for your explanation. I just disabled nvidia-driver( not >> load it) , and >> use "buildworld buildkernel" to test the pcid.1.patch with 9-release, >> it seems the box reset before >> completing the buildkernel, the attachment is my kernel config, would >> you mind try it on >> 9-release with pcid.1.patch? I will git 10-current a try to see if >> there is something wrong with my hardware > > I just did checkout + buildworld + buildkernel with -j 10 on UFS with > PCID turned on, everything finished fine. It is up to date HEAD. > > sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt > vm.stats.sys.v_swtch: 13743519 > vm.pmap.pcid_save_cnt: 7853519 > I.e. the TLB was not flushed one each second context switch. > > Trying the HEAD with the patch is probably easiest way forward. Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 box, system panic ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: CARP on -CURRENT
I much appreciate the responses and I was able to get CARP functioning using
the new ifconfig syntax under -CURRENT. Having done that, CARP is now acting as
it should, though now I have a new challenge with devd and automatic firing of
scripts during CARP failover. It appears that the documented method of doing
this at http://www.freebsd.org/doc/handbook/disks-hast.html no longer works
with the suggested devd.conf setup;
notify 30 {
match "system" "IFNET";
match "subsystem" "carp0";
match "type" "LINK_UP";
action "/usr/local/sbin/carp-hast-switch master";
};
notify 30 {
match "system" "IFNET";
match "subsystem" "carp0";
match "type" "LINK_DOWN";
action "/usr/local/sbin/carp-hast-switch slave";
Is it likely that the triggers associated with CARP for devd have changed due
to the recent new CARP overhaul? Does anyone know what the new triggers may be?
Love,
Andrew
-Original Message-
From: Sergey Kandaurov [mailto:pluk...@gmail.com]
Sent: Wednesday, January 18, 2012 4:24 PM
To: Andrew Hobbs
Cc: freebsd-current@freebsd.org
Subject: Re: CARP on -CURRENT
On 19 January 2012 00:54, Andrew Hobbs wrote:
> Is CARP implemented on -CURRENT (FreeBSD 10)?
>
> I'm playing around with some test boxes in the office running
> -CURRENT; testbox# uname -a FreeBSD testbox.ai.net 10.0-CURRENT
> FreeBSD 10.0-CURRENT #0: Wed Jan 18 19:21:12 EST 2012
> r...@testbox.ai.net:/usr/obj/usr/src/sys/CARP amd64
>
> I can't seem to create a carp interface despite having compiled a
> kernel with "device carp" in it. Attempts to create a carp
> interface fail; # ifconfig carp create
> ifconfig: SIOCIFCREATE2: Invalid argument
>
> >From what I've read in the handbook entry on CARP
> >(http://www.freebsd.org/doc/handbook/carp.html), I should be able to
> >either compile in the carp device, as above, or load the if_carp.ko
> >kern module. There doesn't appear to be a if_carp.ko module in the
> >-CURRENT source tree, however. Only the carp module itself;
> # ls -ald /usr/src/sys/modules/*carp*
> drwxr-xr-x 2 root wheel 512 Dec 27 15:12 /usr/src/sys/modules/carp
>
> Am I missing something completely obvious? Was the functionality of
> if_carp.ko rolled into another module?
You should definitely read this changeset:
http://svn.freebsd.org/changeset/base/228571
and the updated carp ifconfig syntax in man carp. As for if_carp.ko, it was
renamed into carp.ko as part of the CARP implementation overhaul.
This only affects CURRENT.
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Race between cron and crontab
On Tuesday, January 31, 2012 9:23:12 pm Doug Barton wrote: > On 01/31/2012 08:49, John Baldwin wrote: > > A co-worker ran into a race between updating a cron tab via crontab(8) and > > cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab > > was > > updated. The problem is that 1) by default our filesystems only use second > > granularity for timestamps and 2) cron only caches the seconds portion of a > > file's timestamp when checking for changes anyway. This means that cron > > can > > miss updates to a spool directory if multiple updates to the directory are > > performed within a single second and cron wakes up to scan the spool > > directory > > within the same second and scans it before all of the updates are complete. > > > > Specifically, when replacing a crontab, crontab(8) first creates a > > temporary > > file in /var/cron/tabs and then uses a rename to install it followed by > > touching the spool directory to update its modification time. However, the > > creation of the temporary file already changes the modification time of the > > directory, and cron may "miss" the rename if it scans the directory in > > between > > the creation of the temporary file and the rename. > > > > The "fix" I am planning to use locally is to simply force crontab(8) to > > sleep > > for a second before it touches the spool directory, thus ensuring that it > > the > > touch of the spool directory will use a later modification time than the > > creation of the temporary file. > > If you really want cron to have sub-second granularity I don't see how > you could do it without using flags. > > crontab open sets flag that it is editing a file > crontab close clears "editing" flag, sets "something changed" flag > (if something actually changed of course) > > cron checks existence of "something changed" flag, pulls the > update if there is no "editing" flag, clears "changed" flag I don't want it to have sub-second granularity, I just want to make 'crontab -e' more reliable so that cron doesn't miss edits. cron is currently using the mod-time of the spool directory as the 'something changed' flag (have you read the cron code?). The problem is that it currently can set the 'something changed' flag non-atomically while it is updating a crontab. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: using nscd (ldap) makes passwd/group disappearing while installing ports
Am 01.02.2012 01:03, schrieb Benjamin Lee: > What's going on is: > > 1) The port checks if the group exists > 2) nscd caches that the group does not exist in its negative cache > 3) pw(8) creates the group then checks if it exists > 4) nscd returns the negative cache entry (group does not exist) > > This causes pw(8) to error since it expects the group that it just > created to exist. I had suggested before, that nscd be changed to only rely on cached negative entries, if they have repeatedly been seen in the underlying files/data-bases. E.g. only consider negative entries valid after they have been repeatedly stored into the cache (I'd think 3 times are a reasonable number). That way, the first lookup of an account or group will lead to an entry with count=1, which is found during cache lookup but which is ignored due to a too low "verification count". If the negative lookup is repeated 3 times within some reasonable time window (say 60 seconds), then it is to be considered verified. This will make the above sequence of queries and modifications of the passwd or group databases work with caching. This concept does not protect against scenarios where the negative cache entry is made active by several queries (e.g. manual checking for the presence of an account or group before the software installation repeats these tests). That is the reason to ask for more than 2 negative replies (3, perhaps better 5) before a negative cache entry is trusted. The main purpose of the cache (reduced latency for positive queries, limited load due to negative queries) will still be maintained. >> I also have this error very often when rebuilding/updating or even >> installing cups when "nscd" is enabled. A simple restart of nscd helps >> in most cases, most times I need to disable "cache" tag in >> /etc/nsswitch.conf, then everything runs smooth. >> >> Well, this behaviour is since a couple of years now, occurs sporadic. I >> have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? >> >> I like the cache facility, since in domains with a lot of users >> searching LDAP takes some time and caching help keeping traffic and >> latency short. But the namservice caching mechanism seems to be >> unreliable. What is up there? > > You should put "files" before "cache" in /etc/nsswitch.conf, e.g.: > > group: files cache ldap > passwd: files cache ldap > > The problem is that tools that modify the passwd and group files, like > pw(8), don't invalidate nscd's negative cache entries when making > changes. You point out an alternative to making negative entries trusted only after they have been repeatedly entered into the cache: Tools that are used to modify the passwd/group databases might signal their changes to nscd. They could either purge the modified caches for the current or for all users, or they could just clear the single affected entry. In each case, nscd needs to re-fetch the modified (and possibly all other cached) entries. A simple implementation of such invalidation could be to invoke "nscd -I" after each modification performed by "pw". Still I think that the reduced trust in negative entries that have not been repeatedly tested is the best solution. I had looked into implementing such a logic in the cache, a few months back. It took more effort than I had hoped due to the way the cache is implemented, but I still think it should be possible without major changes to nscd. Regards, STefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: using nscd (ldap) makes passwd/group disappearing while installing ports
On 01/02/2012, at 19:25, O. Hartmann wrote: >> The problem is that tools that modify the passwd and group files, like >> pw(8), don't invalidate nscd's negative cache entries when making >> changes. >> >> > > Thank you for the explanation. How feasible would it be for pw to try and notify nscd? Or for nscd to monitor the passwd & group files? Either would be somewhat racy though.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: using nscd (ldap) makes passwd/group disappearing while installing ports
On 02/01/12 01:03, Benjamin Lee wrote: > On 01/31/2012 03:03 PM, O. Hartmann wrote: >> I'm using on a couple of servers the nameservice cache dameon nscd and >> cache "group", "passwd" and "sudoers". Backend is LDAP, but local files >> should searched first. then ldap. cache is searched the very first even >> before files. >> >> Well, I'd expect that if a group is present, like "cups" or "dhcp" and >> reside in the local file (/etc/group or /etc/passwd), they are cached. >> >> Installing net/isc-dhcp42-server fails with this error: >> >> >> gmake[1]: Leaving directory >> `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2/server' >> gmake[1]: Entering directory >> `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' >> gmake[1]: Nothing to be done for `all-am'. >> gmake[1]: Leaving directory >> `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' >> ===> Installing for isc-dhcp42-server-4.2.3_2 >> ===> Generating temporary packing list >> ===> Creating users and/or groups. >> Creating group `dhcpd' with gid `136'. >> pw: group disappeared during update >> *** Error code 70 >> >> Stop in /usr/ports/net/isc-dhcp42-server. >> *** Error code 1 >> >> Stop in /usr/ports/net/isc-dhcp42-server. > > What's going on is: > > 1) The port checks if the group exists > 2) nscd caches that the group does not exist in its negative cache > 3) pw(8) creates the group then checks if it exists > 4) nscd returns the negative cache entry (group does not exist) > > This causes pw(8) to error since it expects the group that it just > created to exist. > >> I also have this error very often when rebuilding/updating or even >> installing cups when "nscd" is enabled. A simple restart of nscd helps >> in most cases, most times I need to disable "cache" tag in >> /etc/nsswitch.conf, then everything runs smooth. >> >> Well, this behaviour is since a couple of years now, occurs sporadic. I >> have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? >> >> I like the cache facility, since in domains with a lot of users >> searching LDAP takes some time and caching help keeping traffic and >> latency short. But the namservice caching mechanism seems to be >> unreliable. What is up there? > > You should put "files" before "cache" in /etc/nsswitch.conf, e.g.: > > group: files cache ldap > passwd: files cache ldap > > The problem is that tools that modify the passwd and group files, like > pw(8), don't invalidate nscd's negative cache entries when making > changes. > > Thank you for the explanation. Cheers, Oliver signature.asc Description: OpenPGP digital signature
Re: [HEADSUP][CFT] pkgng beta1 is out
On 30.01.2012 16:39, Baptiste Daroussin wrote: Hi, pkgng has just reached the beta phase, and has now found its way to the ports tree (disabled by default). 1/ Why pkgng? Hi, What about pkgng support in tinderbox? -- Andrey Zonov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
