[OpenAFS] 1.6.0pre2 Filelog CB: WhoAreYou failed for host
Hi, I know this topic has been discussed before, but the conclusion was that it is caused by NAT. This is impossible in my case, as openafs servers are firewalled from the outside world. The fileserver has 3 ethernet interfaces: 1: connected to the clients, two IP addresses one active (other in the NetRestrict file) 2: connected to a SAN, no IP addresses 3: connected to other cluster memebers, IP address in the NetRestrict file vos listaddrs gives nothing just the right IP address for the vol and fileserver. The FileLog is full of entries like: CB: WhoAreYou failed for host FILESERVER Besides that all the clients (1.6.0pre2 on linux, 1.5.78 and 1.6.0pre3 on windows) are working as expected. Except one (1.6.0pre2 on linux) which has two interfaces (one connected two the Fileservers network and the other in its NetRestrict file). This has entries in its syslog like this: Mar 21 07:31:36 ssh-gate kernel: [ 4879.645660] afs: WARM shutting down of: CBCELLNAME afsCELLNAME BkGCELLNAME CTruncCELLNAME AFSDBCELLNAME RxEventCELLNAME UnmaskRxkSignalsCELLNAME RxListenerCELLNAME ALL allocated tablesCELLNAME done Mar 21 07:31:36 HOSTNAME kernel: [ 4880.229317] enabling dynamically allocated vcaches Mar 21 07:31:36 HOSTNAME kernel: [ 4880.229321] Starting AFS cache scanCELLNAMEfound 70 non-empty cache files (2%). Mar 21 07:32:51 HOSTNAME kernel: [ 4954.852104] afs: Lost contact with file server FILESERVER in cell CELLNAME (all multi-homed ip addresses down for the server) Mar 21 07:32:51 HOSTNAME kernel: [ 4954.852115] afs: Lost contact with file server FILESERVER in cell CELLNAME (all multi-homed ip addresses down for the server) Mar 21 07:32:51 HOSTNAME kernel: [ 4954.852119] RXAFS_GetCapabilities failed with code -3 Mar 21 07:32:54 HOSTNAME kernel: [ 4958.304958] afs: file server FILESERVER in cell CELLNAME is back up (multi-homed address; other same-host interfaces may still be down) Mar 21 07:32:54 HOSTNAME kernel: [ 4958.304965] afs: file server FILESERVER in cell CELLNAME is back up (multi-homed address; other same-host interfaces may still be down) the first ls on /afs/CELLNAME/ always fail, and later on (after those syslog entries, except restarting of course) it starts working. Thanks for any idea! Cheers Geza ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Crazy DAFS problem (with log)
Well, that didn't take long, it already blew up again, in exactly the same fashion, with the same two culprit volumes. -- Ryan C. Underwood, ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Crazy DAFS problem (with log)
On Sun, Mar 20, 2011 at 09:57:22PM -0500, Andrew Deason wrote: > > Oh, hmm, this starts too late. I guess you don't have the BosLog before > this? Nope, wish it rotated more old logs out but haven't looked into this. > > 03/20/2011 16:36:17 The volume header file /vicepa/V0536871274.vol is not > > associated with any actual data (deleted) > > 03/20/2011 16:40:14 dispatching child to salvage volume 536871273... > > 03/20/2011 16:40:14 2 nVolumesInInodeFile 56 > > 03/20/2011 16:40:14 CHECKING CLONED VOLUME 536871274. > > 03/20/2011 16:40:14 www_logs.readonly (536871274) updated 03/20/2011 16:39 > > 03/20/2011 16:40:14 Vnode 22: length incorrect; (is 1794950 should be 0) > > Do you know if this volume was recreated between these times? I'm not > sure if the salvager is just lying, but this would indicate it deleted > the RO, and then it came back again and again has invalid metadata. If by recreated you mean a remsite/addsite, the answer is no. > > [.. ad infinitum ] > > Actually, it may help to continue for an interation or two more. I don't > think these salvages have repeated themselves yet. Will attach at the end. > > It's a RO clone, should I just delete it and add it back? > > Yes, if it'll let you. The salvage is supposed to delete it for you, but > if it's not it's not. I deleted all the clones in question and manually salvaged the RW volumes then recreated and re-released the clones. Let's see if the gremlin comes back. > Based on the salsrv logs, I'd be looking at vnodes 264, 266, and 268 in > 536870915/6, and 22, 202, and 204 in 536871273/4. That is, see if the > 'UFS-Filename' file on disk actually has the length in the 'volinfo' > output. If/when it comes back I'll dig into this stuff. > >>>Shortly after the weekly scheduled fileserver restart > > You shouldn't need to have these on. But they shouldn't be causing > salvages or whatever, either. OK, this used to be standard practice, but I set up back in the 1.2 days so a lot could have changed since then. I'll remove it. Long SalsrvLog excerpt: @(#) OpenAFS 1.6.0~pre3-0-debian built 2011-03-18 03/20/2011 04:00:29 Starting OpenAFS Online Salvage Server 2.4 (/usr/lib/openafs/salvageserver) 03/20/2011 04:02:02 dispatching child to salvage volume 536870915... 03/20/2011 04:02:02 2 nVolumesInInodeFile 56 03/20/2011 04:02:02 waiting for fileserver to finish scanning partition /vicepa... 03/20/2011 04:02:03 CHECKING CLONED VOLUME 536870916. 03/20/2011 04:02:03 root.cell.readonly (536870916) updated 03/20/2011 00:12 03/20/2011 04:02:03 Vnode 266: length incorrect; (is 2587609 should be 0) 03/20/2011 04:02:03 SALVAGING VOLUME 536870915. 03/20/2011 04:02:03 root.cell (536870915) updated 03/20/2011 00:12 03/20/2011 04:02:03 Vnode 266: length incorrect; changed from 2587609 to 0 03/20/2011 04:02:03 totalInodes 190 03/20/2011 04:02:03 Salvaged root.cell (536870915): 183 files, 62821 blocks 03/20/2011 04:02:05 dispatching child to salvage volume 536871273... 03/20/2011 04:02:05 2 nVolumesInInodeFile 56 03/20/2011 04:02:05 CHECKING CLONED VOLUME 536871274. 03/20/2011 04:02:05 www_logs.readonly (536871274) updated 03/19/2011 18:35 03/20/2011 04:02:05 Vnode 22: length incorrect; (is 1683156 should be 0) 03/20/2011 04:02:05 SALVAGING VOLUME 536871273. 03/20/2011 04:02:05 www_logs (536871273) updated 03/19/2011 18:35 03/20/2011 04:02:05 Vnode 22: length incorrect; changed from 1683156 to 0 03/20/2011 04:02:05 Vnode 24: length incorrect; changed from 184572 to 0 03/20/2011 04:02:05 Vnode 202: length incorrect; changed from 232747 to 0 03/20/2011 04:02:05 totalInodes 245 03/20/2011 04:02:05 Salvaged www_logs (536871273): 238 files, 241815 blocks 03/20/2011 04:04:01 dispatching child to salvage volume 536870916... 03/20/2011 04:04:01 dispatching child to salvage volume 536870915... 03/20/2011 04:04:01 namei_ListAFSSubDirs: warning: VG 536870916 does not have a link table; salvager will recreate it. 03/20/2011 04:04:01 fileserver requested salvage of clone 536870916; scheduling salvage of volume group 536870915... 03/20/2011 04:04:01 1 nVolumesInInodeFile 28 03/20/2011 04:04:01 SALVAGING VOLUME 536870915. 03/20/2011 04:04:01 root.cell (536870915) updated 03/20/2011 04:03 03/20/2011 04:04:01 totalInodes 187 03/20/2011 04:04:01 Salvaged root.cell (536870915): 183 files, 62824 blocks 03/20/2011 04:04:01 The volume header file /vicepa/V0536870916.vol is not associated with any actual data (deleted) 03/20/2011 04:04:13 dispatching child to salvage volume 536871274... 03/20/2011 04:04:13 dispatching child to salvage volume 536871273... 03/20/2011 04:04:13 namei_ListAFSSubDirs: warning: VG 536871274 does not have a link table; salvager will recreate it. 03/20/2011 04:04:13 fileserver requested salvage of clone 536871274; scheduling salvage of volume group 536871273... 03/20/2011 04:04:13 1 nVolumesInInodeFile 28 03/20/2011 04:04:13 SALVAGING VOLUME 536871273. 03/20/2011 04:04:13 www_logs (536871273) updated 03/19/2011 18:35 03/20/2011 04:04:
[OpenAFS] Re: Crazy DAFS problem (with log)
On Sun, 20 Mar 2011 20:59:43 -0500 "Ryan C. Underwood" wrote: > Not much interesting in BosLog.old: > Sun Mar 20 04:00:29 2011: Core limits now -1 -1 Oh, hmm, this starts too late. I guess you don't have the BosLog before this? > 03/20/2011 16:34:31 CHECKING CLONED VOLUME 536871274. > 03/20/2011 16:34:31 www_logs.readonly (536871274) updated 03/20/2011 05:45 > 03/20/2011 16:34:31 Vnode 22: length incorrect; (is 1773498 should be 0) > 03/20/2011 16:34:31 SALVAGING VOLUME 536871273. The incorrect vnode length should result in the RO getting deleted. I'm not sure why it's not; I'll look tomorrow. I expect that's not a dafs problem, though; just a general salvager issue. A vnode that keeps having the wrong length might be one explanation for the repeated salvages, but it still seems like the headers are screwed up, which is (probably) unrelated. > 03/20/2011 16:36:17 The volume header file /vicepa/V0536871274.vol is not > associated with any actual data (deleted) > 03/20/2011 16:40:14 dispatching child to salvage volume 536871273... > 03/20/2011 16:40:14 2 nVolumesInInodeFile 56 > 03/20/2011 16:40:14 CHECKING CLONED VOLUME 536871274. > 03/20/2011 16:40:14 www_logs.readonly (536871274) updated 03/20/2011 16:39 > 03/20/2011 16:40:14 Vnode 22: length incorrect; (is 1794950 should be 0) Do you know if this volume was recreated between these times? I'm not sure if the salvager is just lying, but this would indicate it deleted the RO, and then it came back again and again has invalid metadata. > [.. ad infinitum ] Actually, it may help to continue for an interation or two more. I don't think these salvages have repeated themselves yet. > > > Sun Mar 20 04:04:01 2011 VAttachVolume: Error reading diskDataHandle > > > header for vol 536870916; error=101 > > > Sun Mar 20 04:04:01 2011 Scheduling salvage for volume 536870916 on part > > > /vicepa over SALVSYNC > > > > "volume metadata is corrupt for 536870916" > > It's a RO clone, should I just delete it and add it back? Yes, if it'll let you. The salvage is supposed to delete it for you, but if it's not it's not. > Does this look normal? I.e., a whole lot of zero-length vnodes > attached to the same vice file. Those are fine; vnodes like this: > 15040 Vnode 472.0.0 cloned: 0, length: 0 linkCount: 0 parent: 0 UFS-Filename: > /vicepa/AFSIDat/d=/d3++U/+/+/+ That is, vnodes like "Vnode X.0.0", are 'blank'; the vnode entry is just zeroed out because the indices are expanded by some amount at a time in chunks (512, or something?). Based on the salsrv logs, I'd be looking at vnodes 264, 266, and 268 in 536870915/6, and 22, 202, and 204 in 536871273/4. That is, see if the 'UFS-Filename' file on disk actually has the length in the 'volinfo' output. And by the way: >>>Shortly after the weekly scheduled fileserver restart You shouldn't need to have these on. But they shouldn't be causing salvages or whatever, either. -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Crazy DAFS problem (with log)
On Sun, Mar 20, 2011 at 07:42:12PM -0500, Andrew Deason wrote: > > What's in SalsrvLog and SalsrvLog.old? It should have a bunch of stuff > on the salvages here. Also, BosLog for this time period would be good > for completeness. Not much interesting in BosLog.old: Sun Mar 20 04:00:29 2011: Core limits now -1 -1 Sun Mar 20 04:00:29 2011: Server directory access is okay Sun Mar 20 16:32:17 2011: ptserver exited on signal 15 Sun Mar 20 16:32:17 2011: vlserver exited on signal 15 Sun Mar 20 16:32:17 2011: dafs:salsrv exited on signal 15 Sun Mar 20 16:32:17 2011: dafs:vol exited on signal 15 Sun Mar 20 16:32:18 2011: dafs:file exited with code 0 Sun Mar 20 16:32:18 2011: Shutdown of BOS server and processes in response to signal 15 SalsrvLog, on the other hand, shows craziness. It just keeps salvaging the same two volumes again and again, for hours. 03/20/2011 16:34:06 Starting OpenAFS Online Salvage Server 2.4 (/usr/lib/openafs/salvageserver) 03/20/2011 16:34:30 dispatching child to salvage volume 536870915... 03/20/2011 16:34:30 dispatching child to salvage volume 536871273... 03/20/2011 16:34:30 2 nVolumesInInodeFile 56 03/20/2011 16:34:30 waiting for fileserver to finish scanning partition /vicepa... 03/20/2011 16:34:31 CHECKING CLONED VOLUME 536871274. 03/20/2011 16:34:31 www_logs.readonly (536871274) updated 03/20/2011 05:45 03/20/2011 16:34:31 Vnode 22: length incorrect; (is 1773498 should be 0) 03/20/2011 16:34:31 SALVAGING VOLUME 536871273. 03/20/2011 16:34:31 www_logs (536871273) updated 03/20/2011 05:45 03/20/2011 16:34:31 Vnode 22: length incorrect; changed from 1773498 to 0 03/20/2011 16:34:31 Vnode 202: length incorrect; changed from 345557 to 0 03/20/2011 16:34:31 Vnode 204: length incorrect; changed from 86723 to 0 03/20/2011 16:34:31 totalInodes 245 03/20/2011 16:34:32 Salvaged www_logs (536871273): 238 files, 241815 blocks 03/20/2011 16:34:30 2 nVolumesInInodeFile 56 03/20/2011 16:34:30 waiting for fileserver to finish scanning partition /vicepa... 03/20/2011 16:34:31 CHECKING CLONED VOLUME 536870916. 03/20/2011 16:34:31 root.cell.readonly (536870916) updated 03/20/2011 12:39 03/20/2011 16:34:31 Vnode 264: length incorrect; (is 15840312 should be 0) 03/20/2011 16:34:31 SALVAGING VOLUME 536870915. 03/20/2011 16:34:31 root.cell (536870915) updated 03/20/2011 12:41 03/20/2011 16:34:31 Vnode 264: length incorrect; changed from 15840312 to 0 03/20/2011 16:34:31 Vnode 266: length incorrect; changed from 2589178 to 0 03/20/2011 16:34:31 Vnode 268: length incorrect; changed from 7364175 to 0 03/20/2011 16:34:31 totalInodes 191 03/20/2011 16:34:32 Salvaged root.cell (536870915): 183 files, 37402 blocks 03/20/2011 16:35:24 dispatching child to salvage volume 536870915... 03/20/2011 16:35:24 1 nVolumesInInodeFile 28 03/20/2011 16:35:25 SALVAGING VOLUME 536870915. 03/20/2011 16:35:25 root.cell (536870915) updated 03/20/2011 12:41 03/20/2011 16:35:25 totalInodes 187 03/20/2011 16:35:25 Salvaged root.cell (536870915): 183 files, 37402 blocks 03/20/2011 16:35:25 The volume header file /vicepa/V0536870916.vol is not associated with any actual data (deleted) 03/20/2011 16:36:17 dispatching child to salvage volume 536871274... 03/20/2011 16:36:17 dispatching child to salvage volume 536871273... 03/20/2011 16:36:17 namei_ListAFSSubDirs: warning: VG 536871274 does not have a link table; salvager will recreate it. 03/20/2011 16:36:17 fileserver requested salvage of clone 536871274; scheduling salvage of volume group 536871273... 03/20/2011 16:36:17 1 nVolumesInInodeFile 28 03/20/2011 16:36:17 SALVAGING VOLUME 536871273. 03/20/2011 16:36:17 www_logs (536871273) updated 03/20/2011 16:36 03/20/2011 16:36:17 totalInodes 242 03/20/2011 16:36:17 Salvaged www_logs (536871273): 238 files, 243808 blocks 03/20/2011 16:36:17 The volume header file /vicepa/V0536871274.vol is not associated with any actual data (deleted) 03/20/2011 16:40:14 dispatching child to salvage volume 536871273... 03/20/2011 16:40:14 2 nVolumesInInodeFile 56 03/20/2011 16:40:14 CHECKING CLONED VOLUME 536871274. 03/20/2011 16:40:14 www_logs.readonly (536871274) updated 03/20/2011 16:39 03/20/2011 16:40:14 Vnode 22: length incorrect; (is 1794950 should be 0) 03/20/2011 16:40:14 SALVAGING VOLUME 536871273. 03/20/2011 16:40:14 www_logs (536871273) updated 03/20/2011 16:39 [.. ad infinitum ] > I am also assuming there's no SalvageLog* files with entries anywhere > near this time. If that's not true, include those. Correct > > Sun Mar 20 04:04:01 2011 VAttachVolume: Error reading diskDataHandle header > > for vol 536870916; error=101 > > Sun Mar 20 04:04:01 2011 Scheduling salvage for volume 536870916 on part > > /vicepa over SALVSYNC > > "volume metadata is corrupt for 536870916" It's a RO clone, should I just delete it and add it back? > > Sun Mar 20 04:14:14 2011 CopyOnWrite failed: volume 536871273 in partition > > /vicepa (tried reading 8192, read 0, wrote 0, errno 0) volume needs salvage > > Someone wrote to a file in 536
Re: [OpenAFS] Multiple logins
Quoting Jason Edgecombe : Is this enforcing a policy decision or just preventing technical problems caused by multiple logins? For my site it is strictly to prevent technical problems. I'm wondering because we us gnome on RHEL5 with AFS home directories and multiple logins on different machines haven't been an issue, but trying to login to gnome multiple times on the same machine does cause error messages. Interesting. Since Xfce is based on the GTK+ v2 toolkit (the same as GNOME), it may not suffer the problems that I anticipate. I'll run some tests later on when I have to opportunity and report the results. Cheers, Jaap ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: Crazy DAFS problem (with log)
On Sun, 20 Mar 2011 16:50:16 -0500 "Ryan C. Underwood" wrote: > Shortly after the weekly scheduled fileserver restart, things blew up > in a big way. My RW root.cell was inaccessible in the end. No kernel > messages indicating filesystem or disk problems underneath. I > force-fscked the vice partition (ext4) and no problems were found. > Any speculation on what in the world happened here? This is running > -pre3 with the patch from Andrew mentioned earlier. What's in SalsrvLog and SalsrvLog.old? It should have a bunch of stuff on the salvages here. Also, BosLog for this time period would be good for completeness. I am also assuming there's no SalvageLog* files with entries anywhere near this time. If that's not true, include those. > Sun Mar 20 04:00:30 2011 File Server started Sun Mar 20 04:00:30 2011 > Sun Mar 20 04:02:02 2011 Scheduling salvage for volume 536870915 on part > /vicepa over SALVSYNC There are not many places that VRequestSalvage_r can get called without logging something about why... I think the only places are when the volume header flags say that the volume needs salvaging. > Sun Mar 20 04:04:01 2011 VAttachVolume: Error reading diskDataHandle header > for vol 536870916; error=101 > Sun Mar 20 04:04:01 2011 Scheduling salvage for volume 536870916 on part > /vicepa over SALVSYNC "volume metadata is corrupt for 536870916" > Sun Mar 20 04:14:14 2011 CopyOnWrite failed: volume 536871273 in partition > /vicepa (tried reading 8192, read 0, wrote 0, errno 0) volume needs salvage Someone wrote to a file in 536871273, and we needed to CoW the file. But we couldn't read all of the data from the file to make a new copy. Based on those values, I'd guess the file is empty on disk, but it's supposed to contain some data. With a patch on the master branch, such a situation should be caught earlier and more information logged. But that wouldn't even really help too much if that were the case. You can find files like this by doing 'volinfo /vicepa 536871273 -filenames', and seeing the alleged length for each vnode, and seeing if the actual file size on disk of the reported filenames match. However, salvaging is supposed to fix that, so it would be good to see what the salvage logs say. -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Crazy DAFS problem (with log)
Shortly after the weekly scheduled fileserver restart, things blew up in a big way. My RW root.cell was inaccessible in the end. No kernel messages indicating filesystem or disk problems underneath. I force-fscked the vice partition (ext4) and no problems were found. Any speculation on what in the world happened here? This is running -pre3 with the patch from Andrew mentioned earlier. Sun Mar 20 04:00:29 2011 File server starting (/usr/lib/openafs/dafileserver -p 123 -pctspare 20 -L -busyat 50 -rxpck 2000 -rxbind -cb 400 -vattachpar 128 -vlruthresh 1440 -vlrumax 8 -vhashsize 11) Sun Mar 20 04:00:29 2011 afs_krb_get_lrealm failed, using icequake.net. Sun Mar 20 04:00:30 2011 VLRU: starting scanner with the following configuration parameters: Sun Mar 20 04:00:30 2011 VLRU: offlining volumes after minimum of 86400 seconds of inactivity Sun Mar 20 04:00:30 2011 VLRU: running VLRU soft detach pass every 120 seconds Sun Mar 20 04:00:30 2011 VLRU: taking up to 8 volumes offline per pass Sun Mar 20 04:00:30 2011 VLRU: scanning generation 0 for inactive volumes every 10800 seconds Sun Mar 20 04:00:30 2011 VLRU: scanning for promotion/demotion between generations 0 and 1 every 172800 seconds Sun Mar 20 04:00:30 2011 VLRU: scanning for promotion/demotion between generations 1 and 2 every 345600 seconds Sun Mar 20 04:00:30 2011 Set thread id 3 for FSYNC_sync Sun Mar 20 04:00:30 2011 VInitVolumePackage: beginning parallel fileserver startup Sun Mar 20 04:00:30 2011 VInitVolumePackage: using 1 threads to pre-attach volumes on 1 partitions Sun Mar 20 04:00:30 2011 Scanning partitions on thread 1 of 1 Sun Mar 20 04:00:30 2011 Partition /vicepa: pre-attaching volumes Sun Mar 20 04:00:30 2011 fs_stateRestore: commencing fileserver state restore Sun Mar 20 04:00:30 2011 Partition scan thread 1 of 1 ended Sun Mar 20 04:00:30 2011 fs_stateRestore: host table restored Sun Mar 20 04:00:30 2011 fs_stateRestore: FileEntry and CallBack tables restored Sun Mar 20 04:00:30 2011 fs_stateRestore: host table indices remapped Sun Mar 20 04:00:30 2011 fs_stateRestore: FileEntry and CallBack indices remapped Sun Mar 20 04:00:30 2011 fs_stateRestore: restore phase complete Sun Mar 20 04:00:30 2011 fs_stateRestore: beginning state verification phase Sun Mar 20 04:00:30 2011 fs_stateRestore: fileserver state verification complete Sun Mar 20 04:00:30 2011 fs_stateRestore: restore was successful Sun Mar 20 04:00:30 2011 Getting FileServer name... Sun Mar 20 04:00:30 2011 Set thread id 007E for 'FiveMinuteCheckLWP' Sun Mar 20 04:00:30 2011 FileServer host name is 'valhalla' Sun Mar 20 04:00:30 2011 Set thread id 0082 for 'FsyncCheckLWP' Sun Mar 20 04:00:30 2011 Set thread id 007F for 'HostCheckLWP' Sun Mar 20 04:00:30 2011 Getting FileServer address... Sun Mar 20 04:00:30 2011 FileServer valhalla has address 10.0.1.232 (0xe801000a or 0xa0001e8 in host byte order) Sun Mar 20 04:00:30 2011 File Server started Sun Mar 20 04:00:30 2011 Sun Mar 20 04:02:02 2011 Scheduling salvage for volume 536870915 on part /vicepa over SALVSYNC Sun Mar 20 04:02:02 2011 VVGC_scan_partition: finished scanning /vicepa: 147 volumes in 74 groups Sun Mar 20 04:02:03 2011 fssync: breaking all call backs for volume 536870915 Sun Mar 20 04:02:05 2011 Scheduling salvage for volume 536871273 on part /vicepa over SALVSYNC Sun Mar 20 04:02:05 2011 fssync: breaking all call backs for volume 536871273 Sun Mar 20 04:04:01 2011 VAttachVolume: Error reading diskDataHandle header for vol 536870916; error=101 Sun Mar 20 04:04:01 2011 Scheduling salvage for volume 536870916 on part /vicepa over SALVSYNC Sun Mar 20 04:04:01 2011 warning: volume 536870916 recursively checked out by programType id 4 Sun Mar 20 04:04:13 2011 Scheduling salvage for volume 536871274 on part /vicepa over SALVSYNC Sun Mar 20 04:04:13 2011 warning: volume 536871274 recursively checked out by programType id 4 Sun Mar 20 04:06:02 2011 fssync: breaking all call backs for volume 536870916 Sun Mar 20 04:10:02 2011 fssync: breaking all call backs for volume 536871274 Sun Mar 20 04:12:02 2011 fssync: breaking all call backs for volume 536871274 Sun Mar 20 04:14:03 2011 fssync: breaking all call backs for volume 536871274 Sun Mar 20 04:14:14 2011 CopyOnWrite failed: volume 536871273 in partition /vicepa (tried reading 8192, read 0, wrote 0, errno 0) volume needs salvage Sun Mar 20 04:14:14 2011 CopyOnWrite failed: requesting salvage Sun Mar 20 04:14:14 2011 Scheduling salvage for volume 536871273 on part /vicepa over SALVSYNC Sun Mar 20 04:14:14 2011 fssync: breaking all call backs for volume 536871273 Sun Mar 20 04:16:02 2011 Scheduling salvage for volume 536871274 on part /vicepa over SALVSYNC Sun Mar 20 04:18:02 2011 fssync: breaking all call backs for volume 536871274 Sun Mar 20 04:20:02 2011 fssync: breaking all call backs for volume 536871274 Sun Mar 20 04:20:04 2011 CopyOnWrite failed: volume 536871273 in partition /vicepa (tried reading 8192, read 0, wrote
Re: [OpenAFS] Multiple logins
On 03/20/2011 08:19 AM, Coy Hile wrote: On Sat, Mar 19, 2011 at 1:23 PM, Jaap Winius wrote: Quoting Dirk Heinrichs: ... Is it possible to prevent users from logging in more than once ... No, you can't. ... Couldn't you potentially write a PAM module to do exactly that? At the top of the session stack, have it store the status of the user's session in LDAP somewhere (or potentially in some other database, and then on logout, remove the "Joe has an active session" flag. Then, upon a second or subsequent attempt at login, the PAM module could kick the user out? I don't know the logistics of doing so, unfortunately; potentially Russ could give a better hand-wave solution? Is this enforcing a policy decision or just preventing technical problems caused by multiple logins? I'm wondering because we us gnome on RHEL5 with AFS home directories and multiple logins on different machines haven't been an issue, but trying to login to gnome multiple times on the same machine does cause error messages. Jason ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Multiple logins
On Sat, Mar 19, 2011 at 1:23 PM, Jaap Winius wrote: > Quoting Dirk Heinrichs : > >>> ... Is it possible to prevent users from logging in more than once ... >> >> No, you can't. ... Couldn't you potentially write a PAM module to do exactly that? At the top of the session stack, have it store the status of the user's session in LDAP somewhere (or potentially in some other database, and then on logout, remove the "Joe has an active session" flag. Then, upon a second or subsequent attempt at login, the PAM module could kick the user out? I don't know the logistics of doing so, unfortunately; potentially Russ could give a better hand-wave solution? -Coy ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
