From owner-fam@oss.sgi.com Fri Oct 6 20:25:54 2000 Received: by oss.sgi.com id ; Fri, 6 Oct 2000 20:25:34 -0700 Received: from newman.bch.uc.edu ([129.137.195.205]:520 "EHLO smtp.uc.edu") by oss.sgi.com with ESMTP id ; Fri, 6 Oct 2000 20:25:03 -0700 Received: from cicero.ra.uc.edu (t04-02.ra.uc.edu [129.137.228.74]) by smtp.uc.edu (8.9.3/8.9.2) with ESMTP id VAA02767 for ; Fri, 6 Oct 2000 21:51:26 -0400 Received: (from ebg@localhost) by cicero.ra.uc.edu (8.9.3/8.9.3) id XAA18191 for fam@oss.sgi.com; Fri, 6 Oct 2000 23:23:35 -0400 Date: Fri, 6 Oct 2000 23:23:35 -0400 From: "E. Brian Gast" To: fam@oss.sgi.com Subject: [fam] possible imon bug? Message-ID: <20001006232335.A18179@cicero.ra.uc.edu> Mail-Followup-To: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing All, In case anyone was wondering, I'm still looking at imon stuff when I get the time, which hasn't been real often lately. Anyway, I've got what may be a bug or just an inconsistency to ask about. In short: if you monitor an empty directory, and the directory is deleted, fam doesn't produce an event. However, if the directory has one or more items in it, you do get a deleted event on the directory. This gets kind of long, so if you're not interested feel free to delete now. :) To reproduce you need the test program in the test subdirectory of the fam distribution and a couple of terms open. I'm getting these results with fam-oss 2.6.4 and imon for 2.2.x and 2.4.x. Here goes... In term 1: 'mkdir /tmp/foo && touch /tmp/foo/bar' In term 2: '/usr/src/fam-oss-2.6.4/test/test -r -d /tmp/foo' test should produce output something like: FAMMonitorDirectory("/tmp/foo") req 1: FAMMonitorDirectory("/tmp/foo") DIR /tmp/foo: req 1: /tmp/foo Exists DIR /tmp/foo: req 1: bar Exists DIR /tmp/foo: req 1: /tmp/foo EndExist Then in term 1: 'rm -r /tmp/foo' The following should be added to term 2: DIR /tmp/foo: req 1: /tmp/foo was deleted DIR /tmp/foo: req 1: /tmp/foo Changed DIR /tmp/foo: req 1: bar was deleted This is all good, and is actually part of an example from the IRIX docs (linked to on http://oss.sgi.com/projects/fam/doc.html -- big URL). Now, in term 1: 'mkdir /tmp/foo' <-- empty directory and, in term 2: '/usr/src/fam-oss-2.6.4/test/test -r -d /tmp/foo' and the output: FAMMonitorDirectory("/tmp/foo") req 1: FAMMonitorDirectory("/tmp/foo") DIR /tmp/foo: req 1: /tmp/foo Exists DIR /tmp/foo: req 1: /tmp/foo EndExist Then in term 1: 'rm -r /tmp/foo' or 'rmdir /tmp/foo' And in term 2 you get nothing... So, why do you get a deleted event for /tmp/foo in the first case when the directory has something in it, but not the second with the empty directory? It would interesting to see what IRIX does with this. I'm guessing the idea is to keep the IRIX and Linux versions consistent. And now for some gory details: When vfs_rmdir (in 2.4, do_rmdir in 2.2) is called an IMON_CONTENT event is created for the parent directory. This is why nothing happens in the second case, '/tmp' is not being monitored so imon doesn't report the event. In the first case however, vfs_unlink (both 2.2 & 2.4) is called on 'bar' first. The imon events vfs_unlink creates are first an IMON_CONTENT on the parent, '/tmp/foo', and then an IMON_DELETE on the file, 'bar'. Now, from what I've seen from the fam sources and debug output, when fam gets the first event, the IMON_CONTENT on '/tmp/foo', it tries to do a 'scan' on it and finds out it has been deleted. Fam then reports that to the client, along with the '/tmp/foo' changed and 'bar' deleted. Then it gets the 'bar' deleted event from imon and does nothing with it since it has already been reported. (If any of the last part is false, please let me know. I'm mostly going off of the debug output of fam.) So, it would seem that the correct thing to do would be to add an IMON_DELETE event inside vfs_rmdir for the directory that is being deleted. When I tried this out, the first case worked the same, and on the second case I got a deleted and changed event on '/tmp/foo' (in that order). If there are no objections I'll go ahead and add this to a future patch. Another question: Is there a document available which has a comprehensive list of "when X occurs, imon reports Y" which I haven't stumbled across? It would make knowing what to do in this kind of situation much easier. Brian -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sun Oct 8 10:05:37 2000 Received: by oss.sgi.com id ; Sun, 8 Oct 2000 10:05:27 -0700 Received: from www.npw.net ([195.212.73.17]:7941 "EHLO www.openums.org") by oss.sgi.com with ESMTP id ; Sun, 8 Oct 2000 10:05:18 -0700 Received: from openums.org ([213.54.61.83]) (authenticated (0 bits)) by www.openums.org (8.11.0/8.11.0) with ESMTP id e98HGs917522 (using TLSv1/SSLv3 with cipher EXP1024-RC4-SHA (56 bits) verified NO) for ; Sun, 8 Oct 2000 19:17:01 +0200 Message-ID: <39E0A939.27492226@openums.org> Date: Sun, 08 Oct 2000 19:04:57 +0200 From: Philipp Baer X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test9 i586) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: [fam] imon linux-2.4.0-test9 patch Content-Type: multipart/mixed; boundary="------------35A29F60707E6D7019A27879" Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing This is a multi-part message in MIME format. --------------35A29F60707E6D7019A27879 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I've applied the imon-0.0.1-test6 patch to the newest devel-kernel and changed the rejected files. (It might be interesting for some of you). ciao, phb -- Philipp Baer [www.npw.net] The openums project [www.openums.org] gpg-fp [4525 ef8f 7334 e1ff 9c94 caee 819f d091 6a68 de6e] --------------35A29F60707E6D7019A27879 Content-Type: application/x-gzip; name="imon-0.0.1_linux-2.4.0-test9.patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="imon-0.0.1_linux-2.4.0-test9.patch.gz" H4sICB+f4DkAA2ltb24tMC4wLjFfbGludXgtMi40LjAtdGVzdDkucGF0Y2gAzFvpcxs3lv8s /hUYZSqizEOX7cjW+IqtTLhrSylJcZyammKB3SCJUXej00CL5mzlf993AH3wkDTeL6s4ttgN PDy88/cewFhPp2JwIctCJDorvw6Oh0+HhwOnrHtx8MFEZaoyJ5022cF7k031rCzUcK6SfH34 IFOLe6d0BoPBf7jKzs28FJeRE+KZOHr+8umLlycn4vjw8LDT6/W+gYWd6zJjeqfi6IeXh0cv nx0xvbdvxeDo6PT0af+56PEvx8fi7duOEEJneekOTOngHxHNZSEjpwphlbNDcS2X4ncxV4US U1MIN1ciL9RUFYWKxVVprZYZEmnNG3ZEpzfKTKzEJ5NpBxO7OjXZvrBlnpvCie75l1/Or0af zi9u3n3c7/TeX178NPr7ePTp8qLTE+Jmrq1QmZwkylZzcH2k0icuNJFPmfwQpxSmnM1pBJKQ WSymMuXBP+lEiXcJsEdiC1z1YS9mVsjUikhmQn2FrVkLpGEgCBzJ6Az+xPpOx6VMxFQjQ0g6 1oWKgIRWtk8PcJlbVWQqEQudJCIzTk+X8NhYhYSqlRZzldFoJgaCy2ZquLLnWNlbZ3KgnUqd iELJWBW2TxuLU51p6/xWnDEJDFMuGsLvMNLmBtkxnjJuh5azS+tUSntKUxVr6VSyhHVHU7E0 pYhNtuf8+l7MtozmDb5xV3N5p4A2bcgkQSDdyRJWU9Gtzma4VirUnSqWYqoWYA4R8GP3kaNY gWCBe4VCgHEF0oF/l3tAldmNh50ePr1WSsydy18eHBhrh3amh5FJD4Cbf4Hc7QGo9oAsIjUF GgP8mrJA4A+y7+m0dnebmUVYmh4vZOb8ZrWDQcrisNiARpew1yL1e7XgBRfkBSCwrqfZmIzv P/VR5+L3IZhzR3zWhUOL4Q3LpCO8iX++QXfxJGzlXX0miTKeKdey+UACxHenI4WacPNO/PjQ RuJwX92jIkoY/KhwFgZTIPsvcCFxJCDqHB7CH3H04ofHB7KK0r0h7LB/COELQhfFrt7NXFmF UgeheLULsDYL3iHMlJ0MrNQs0C7BEHEl+5INQ4jDofhtLt2e9xDwvly6aM4vj4biZzAWIrkw xa3lx8eNx3ZuyiSmt/zyZAhOrMAFE9qTnetcTJRbKHB4sFfxfRWchHg6FJe5yg7KDDzWJHcQ TYmotrZUfrFnQ34GwUDPgEQiU3zV6V37rYijvjjm8PNUyAJDs5mAAy9p66kBMYRYBhIY8lSM i0rFExndok8CY28bHibA4IrSuuVb/4BmsRgkSLnQM7RFWGJS6sQJ8Pzf4F9Qw3tZwIYwAwA/ B0Dmx6KMlPhvWdg5amd0NfqC4QbCKlJC81YUpz6ieSChKzOD2e/nOoJAigwL8Y5iiIxjjRsG H5hoZ31kkiALpEKSYHUHa8CwueRgNUHpg/srWgF3Jn4E/oG8gvg/gZQ3MyYWSRmBFsH1HMcw Cc/LJbKH8dbRL9kSrMTLEf/bakBomeETaJS8uDb/5z5PQHYdOXzdzIV9cXnx8Xdx/XH0959v 4Jeb8+ub8w8Q+FHJzd0CT94AJ2hyi0I7p7IzMHMVTB1tY3eTuQ53kcdPBmKIBh1QECe3uBcS Ccw9MYyPm6Noc630PbV+5hDEsuGHiexaUxZgHzAa2aun7BKFT/JWIV+bCHgK0bzMbml5NMUY 9cb+BdOlc8Uw2jg5TEdmx+efQeqoPk7XY05CfUgSGlTHImNnvP+HdJAacGNaXn1V0QPLe5Gd fzl/f/kr8PB9m6HHLBqbMS50p87EaC+l7GNBW1WGI5NEYDNRjyHX3ACZBAEGu74P3gCAEDdG gXf3g7w0hmEIDaXF99NGuLv/B9k0aQ5rIlkByIbZJ9ZRrxKCWVwm6s1jqL2X3htrpbwRLR8I YfIx1GSykEuiFZgYkoQyCMZ6m443WdidLLQpIRiUGUdvCNyQ7c30MVw07XHV2BAcjtH/1QZ2 NnECiuXxlDmqT3f9/ysngFrUVrfrZgGSikGYTxGaWSyz1JSZewwL5Ks6ovDzBtCWzqKkjNUB 4YyDqR3ON8mgzDCLkoVB1CXPwQUxsnMtAZC6jNwqOQvANm5RZHI8GnJz5gDpPrFRoXMi5qS9 HQdaHOkhHmi3US6bY4F1JYA7nbGH65rOFIP3t9GZEkzxdG7tcpNjBzqzBPwj8S6zTCdUYawo /j+IKJCphTVAi9I+lIxQYmC2uYDUvi33VDC0t5Yg6kchSdRPaFrU/gzKAJoRPm6rlgbPQzbf gPg6vd+wWJMYMCKsDA0gHCsOAIjTZPIfCHaW8BY62ejyPYj/l6vz62uhTeQStAhfV+LyDMZI JXUBCbGfxND3Egdmby1XjhV+I4whwWEATDms0SAKfQ4RBfMksMYVIcZS3iYVCjApwjgDfNRR oLuPOI8+/3h1+e7D+3fXN+D9rGIEkqmMCmO9zmk+SRLKuszxZPo8KYyMI2nxmWbAzbYDGkjk zE+imjLGKE+9gR72BqwG/sy0QbYfKJB0ySNRE8QBPqZBwkRRSb0HHQrbTq8WClL00mZHZ9n1 GwQQl5UuFMX87I9SlSHpd3r4PEo0vgh6xySKYRa2OS0AJFcWABCVTIQUB3wIDHI0lxdl6FyJ gIUC9BIFUo4Zuq+qD8pPTOU6u8O6QPhluiPQf3BgVDFDs5iUbErnbYfrxn5lkD7q4zptdXd6 Xseo7swMTG6pcsWiyldSvn8gE4shkk2qVZgWkkv+OfhNiiWzzsDXMqxRQRESPBWjbMmqwXVI d5kDiFCUWcYQn6CythVGR7CPENw02jw+2ML+OWb74i4r0wkABfjkFQUL84oEBh1Qp5piz3JZ 4Es/0hiOI1WAcaMm6sUiU/guSoMPUhKDEZy5R6gQFa7RNetsAoA6QcuLIPZhNRSTWcFcot8Y x8007gxBXY9+zMvXi5SO7TxWFTWSV2AUXt0qTDqoB6RkpsGuwZoGmIhE10tm33PG2xU+XXUr 3CYjbFeAYiT1O1rJzUcBA7EZFNyQFK3HPrbv+y1cAEtrQo+LxGFX1iVwFskSA5zzEJVRI/db bpXKeVvs0ShwSD0K4hBTsF4QpMWIhJE1WnDUJws7wkamKHPfu2SHRsWxDTHVBTY4wSbJgsHR vYWRLBrL1q0+/nzQ0GhiZposyu8Ds58i+/SEpsARV5b1ul4eWBDj6tbwAC+RQmEoI8V7O0Q6 QB8bnqNmMe4KzWN0midkK977AQoc+N9GN+heiTHosyQhJ4BDAxou1IxCTyrz3IeUYIFoSqmG pI19LiyXCVrHOkaXQiqYK8mc2/phc/gRVkNlokmH/vG6t3jnJxUWUL/miYzIWyHsHe2LEXtr H7UWK1xggqBiAtiChhzTEAQ4/SbxFIp9lGLLGYPZUZAHx4yDSQQ8g1nKYRuuDiSkLoD7bPW0 5InnSrvWkivOyjIgG0W7weGhL8wwo2oFY16YkXeBkBKDgUxCxZCU5GSHDedakx689+7KTtm2 0NVB1HGtEaqP/k58p6exmnoECc6GGSXIaoTqxsYodTzZQ8HvC6iGIu45gclxW1JgW1JhjBdD 47vDAPJRivUbFAF3MXz/V1j9b9Xo4VDzGCwZEg2uSEmyzGJJ8DARsXTSbwcyoK36MVubcx7H 0QsKrzYcHFBxmbHk+o2eCnge2iB7I72FHBIgBoAbjOjfhyhYp24SAWYEs8h4OO2qKvmCdyMe g20HBwaC1QivvgyRMkcK8MnC5AU27AMIYqsh2BIyKFSpnMSwAvccNjijOB1BtgDPmXjzQ91j A4e0xDvlFmRDOiTcd5jm8HlmFuSFiUG52Q3jMagAuMEGbMZZs99kA/sBTwApPOGE6lNASucY fIRA4msguk3HBhwJK7LcmcyoQCc+fE+rAS6oN2K41TcxoKRg2yHOAxxRGAYk5juMaJyGYQk8 WQhQrT2rDagJTpFubUDSIQJZqFUxTaJm6ZTKlK4+AqI2CyUxf7jgPNP+RKRPkBTgJWx4Wibc 3cU2D51pYGMiW4beN/n/ckHvJ34ReuVbF4TwRpxwKOY6bzsUnaFUMGXOMJqTuKUe7ETPSJ3a mwl3bBH9AFpIDOGx3YXSRbzb2FIoH1I9m7sgSeRIF+Qfsj6PC1pYdagq3+J2JR3OSFYisgym wUABT5y4uc7w3DrsJmGSUxIYMEhgGHYeGheZBv8GEGBNqgzZlgEfn8pUJ1oW7MobdOQJWKgE Y+zKkkuiqWB2WxiP6L8y+uyOUMAZGrWf56BkhaxLHhR6XChT2inXHn8AbNFuGYwMIlyZgE9U jIPbW+qGT4JC8b/HHj5AaHjwVBTxIMGMQQK7w4ALMCE7g13sMfxD6XOZAyLI88Q3YzBEJrcM Q6hoeQeBzpdShSK+LajPHzucEV+Vc9tQf1UjYVguLbm2J9mnKsxyGLQrtRgbC87ggjzliSzU ZhD1BRrwd4kD8iDpxETY9WgeLLdiAAROruf6xDkQvIMq1q6dMxV0TOeLjUGTFDZEnDcpfkmj 6zfV3qeEA6Jw5syDwVjihEqb0EgAdZvIB0GMEU3vw/Duu2oqXmMlVolyofm/9raxdI1SfO2p yQ8bFWg4mA/FYZVwUUrahlqPQ7R3JQ4N4cSV+oCe/PpxPzbA8LSZOx02hPVUyZBRwYkaZuiJ V40ZZOPdLyM+XWVEgAYkqLvVjFS+8iZumhsSVQujKQj07xuMWgHZRHWE9CELF5woPqMGv4Qh y9opVzL092zVnV6zvUk+ZE1fIJAn+yYc7+0/XDTANUCf+k5RUwEDPx7+rfgmn4GjhemCA38d PR46jgQMQL1qD9D4MVkYVB53WlL/XhZVnUIRgpsiUAEQ/PD1S22hKD885icgz6wMxDVEYzpl I1iBdQeZO9Fsk2rY+mCg6Tx9r2g6LpU4VZ9tGXIJaKd6RtapsJUf++ZbsEhUQoT+A7UATUJq rXmUVRba4pJ8kNbAG4vCUHOj+wEKpRGmLE40vLUy91dLGucI5GWpoWBAce14eDw8OnmDhR6E tDINuRrsV/mcyKoeEWteuVxyBmmOGjjl3c3NlcePbpmrgIoypWLavVtv6jMj3CYd0m0KRwer mD1pGjkpuFfKWlq5J9OFl+FEtWnUqPHSsXpwsoobkg0TfHzivsJA/MqBrE2HG26Oz3jxaDXg NJLO1DRPxFGxzZIVlPPlyxfx++Wv4uL8/IO4uRSfz69GP/1egUwpbiG1jKtq3EHucdzNloLe eN7+weEIBJOZkNhpfKnOKPNLRLRQWYcoyKod/pMSULr0UYiOX/jiDF+aQcNRiHgmUB3MqYZT CkWdLAcTGYcoQDcEMOWIwxq16LGdUEuooF8Hr+2YtP7qlbj49eNHwiaWLQov1URgZ9esfu47 e9rc5481INgC9P1mH+JRFJkitMZYQsN5v2YBKO5mxn/u7yLshiAH+7dsqd7KPE1O1KGH2bxE 1O51kzV7MMWoyBQzmUHdOIggNWgb7EH6RowqCti7R6CgGgkxmstfn8+xTwli+BkDNbW8l+Hu QD2ppU/qC0auuj+y6edQ4BUYIY7h/xMedu1k4Y+1RhmkeydO5JbZJ7I9brJpzATHPWkNPF4l iA9OJk/WBp40j3zww7F80h74gdxufelq8OrATXuhgRGPe+c7RrnR2OPHW06UX4FFnXmRgnum ksIaKbBSKHXXpeOs6k+c6FaWv2/xhiJS5Ct2hMl0vJlgwYGNP0BkoDoMAXwNDiMweDPgApzp Wz4MIJLkzf8/vR6tEjySKwNXpKv9bbegm37lM9XtMleA9AvrQYlHvuhqXhpcdGNZglMwzIOf Q71QLL3L154nFLcaA3xCL5IJInR/sl6rFxegBIkNGoxdmoPPmwBAtt91AhpL3mS41sIAVNYX NbXvRmDNoB3dXwTcQ0hxRNF3Zph5QERxzGbgd66++jNpAmyUmKoE0GwkUZmNo5PSAs4ScYFo q9PrSt8b2e8Lijd+apVNJdYFVKLXpxW+AEFp4oliXcIAf9g4ocBEXbe6i81H5dgaszXErcCA dIS4uj7b5AVkUVBCBhlrn1EC4QuwBoPdQOIxVwZrfd6z5jOjpag7zuwtgOsUXZcC3opZyfoO clqG9AagFm9+wYYYPLu6Ec1ghQEhDaa9QXRlZbD7ecr+KiTLlMzVIjnPKTHkdFo1+6clNgB9 J3+J98r4PL9QucKwwQn6/quSrdtKm28qNodsuRbZHLJ+q/vp8UO3ulvz77/Fffy0/1T08J9n dIG7vkcFANzRPbkmv1C7xCDasjkwS5ojettuYtVzH5JgdVtr6+6qo/qt8gsjvlF81fQV6cGf k1p6x8d4AR7+fkGyM5N/DZai9woS/R+lcUNDW9ZTvL9uywmg0sFfu43Lbfs4lh0Vp25+17p0 YPAy8CqpX64u349/ut7fgRkIvqoRy50delYpEhh5SPb+qttWwfD77XLn9xuk/uBXEerJKzI/ fXn0rJb5CxT5i/4PJPHvwkHy3/gORpoO56/XH1tHzeeNr9J8nJjoFl/2Vl9yrfJaiIMn9fW3 mRESw8+iOgQIJ05PDtbpx3xCs3HtaZS5hN6wL54cghP2jk6OYIu4u50diEXdOBun0t7u4+cd aieNQbljptvlQ9XB63iMBXPm8Dd//hAmnsHMP2swUreZxxeX51dXXcK2/XBqQa/Bsm5gAE2F 4F8WGSNg+Pzngybkrytu1TK/325C/H7nplTiWuXi+Lk4Pnp5cvry5DGO6yffG/ROnqMNwd+b jcjmOgsmIb6LIQ6AbscgrDGUdNcjEM94g+VxR/xRVsQtbMQA/kjifpNqLiZtelDKCM8WVkwK 3+QzxAcRvsF9nj57hhs9ffbcB6gdf0xHwfUJ/o0K1tRPdXcyCZ/0Ge6icYRXXQKrzGjlwpo/ H8R5IeSJHVrmFYESOmbs4gPsUKBdMYenFEFPTysOg7lN8iIdquwuYusVDzPEB5SvRAxVLq00 eD0dM3/7Db52eKsCY6VCnxlPdAaLdb/HJcni0ev8qL+Jw33cys7MILwq3Rkz/uLwsH90BIHo 8If+8alnvTFGNBeyShbRHNeRxXJMbVdV8Hr9Qs0sLDpoLvr6Faza6a09Ev+Dq4AV8T1dvLdO 1w/ASB6STvhBkv7aDBTxJDIku61SweGDweqMKsYMXtfnx/vYDDi8j9h6ANpKuC+qWwb7Z1vI /Ll1oTgv3douz9aGrxNYmYOqC2a9QTD3CAMi1EPSaEhh2+bP32/mujLl4CzBe3vVGLA/MERq LjxgGSSsWkaeNsAMNLS6f7pAPE19SDw1oVXrmzt0SoVXLehsJKDvXM6UxQC2Q1ULXwsec/Dq kn+jl1YeVz95MMO075NvzQWtYdvzTWvYNyKXNo17s88xBWX4G+IHxg31FWqdjO8R4yV4qN5y Z8dT270zOkbxVCF1RZf8BYnV+XSJnqZC0sInTa2CXvGVf9Noeo8tKDXneR0KNIGZKfGCbggG IX6m7w5yBsGeVoonkJTVVJq7pcBgRDmWdvkUouQh7bLTvhMy/nD++Zeba4CtjZX8tltmuHHL lRfWXxpoiOnPR8DcdmmyXa8rJcxWG2qP+5YvsK0Tecx311i6ve/gT/WFNTpIo5Y2vcBbjik5 5N6oeRhZf3tWfc1Vofk6zP5epwdoGesN9cgJbd10euDM/xC7f2083RV/eSV2s13xzzO6jUJd YMJV44kxydpNc7px8jgdPlwrtu9236/BVtX4jQrcVjpu1t/TWn/VVsLVNr4YQWotDF4eo9tJ NPbCOPUX8UHhvQGVRdofnxFmlKUzqZzpiL9YtxR75KSxyvdCNxov4SIZPpmx1FDCVk7cIDgU Hy4v9m7ofvMSanq6ZdEcQO0VpFJmCX3RGc/z62Mpm6tIA3Tp/m9739rVNpIt+pn8iuqc6bQN NtiQJ4TMOOAkPk2ANqQzWXfOeAlbBg225Vg2hJnO+e1nv6pUJZVkk07fe9a64zXTMVbVVj12 7VftB96pBAoINRF3ewZq+wdyMzh4c9R6e8YoEYnjEnmS3WrbzDiAL2NZILLDnPROXv/nmdpl LRk14/e5X4yLvvpT5fzk9LDTrW51F3jpi6BWsOXQhnbbrcP37SW7zo2WoBc3+j3IJRBWQS3S ITe0GRqvRgvieBHdnKhXidy5JWM5buoQ9UNk8uiaTb9czOLrcLKaQcwKpVgyO4m3KF9EbvR7 FlEgrHQ+d5qkJG5siYmcTmPddetQ0yRcDPQlFbc7iKd3M9LzKgdVGNiLF+osGkVAntXbWTCF U5iAnDfpi1tLF5smqhuiB4fx9ZQbYAmap9hPlLKSeDi/hQOyR0Z1jiYYYAx/dIEuttFcx8zS VfIdeTwgsMVkwN5uFAROvoTaALytLdhvjz+ot+EknMHJPV1cwIiBDPXDSRJShCyCmeLPaIBH 2kKePzioMxmUehOjcyW5GxTNIh3sIL2Nn2r/SMurapGgjxqZnBnSx875u5MP56p1/El9bHW7 rePzT3vmwo/8MNhJDS326Nc1mwUT8n7i/u/b3YN30Kn1unPUOf+ERvY3nfNjDLB5c9JVLXXa 6p53Dj4ctbrq9EP39OSsDTv0ZjFDGzeeAbmLGMmaiNfOgGhhNKlZ1n4eAbzAXO2TK9QoGkdz 45qu5MJFr81EBXQhiteJ6fWrTiVBb0usCGXcLgbj3zMY+yk6isz1gBO61YFp1LJDF3cVhoae HuQRB6IDqq1WVLQ1WhqfWP/JfXeO09UpHvAGQ6Ahd3GaIWlJYryd3izHDr2zZuHNjhrXd7un 9lrhc6Jd3vBsARqp/iiIxhxLcmcWfzbAK1yMMABsRiMMhSEM0WDInu/CjEfRNS7nmWg51jlh UJnDYpJJDMJ5EI0ScxY+YaIGK15xFvbDiMLaYLGnd6ucQ7xEltVgDEnXbw+3F7YREJFCMsuO J9OfmnryQk5piJcs6pRclevqbIEAdnYaNfU6Tubo0ddSje1ms4mWymc19eGsBbNC40OhzSv/ oMRONky8P+MVzcz7BL24/JC0YTX3JBkFF/5xjf2vmMX9Hg0MtR8KRxZfFVjnw/brDyDgHp+f kA1eQtKAbuEdHRtlMqsC7IJes7XuGu4sk6Pbjx6GY2AY8Sy7ahlb4AaCVcry+IXBiB8Su3bh edP4poba73GThyp2zsPOWev1UZstE2eqUQR2EF4sLi/JUQcDExPjnSYOiwMXbOvo6ORjTxbs 5OD8aCXQ7PgDtIn2wbwiuIETRZ4c7tAz29H0vICbDmpqjI6i7GeUJnvRL7ikkHEdHzULKeIL Dsm64qtxYlqL2YR9SyIWnOzUMBTkRkYSeJIZlzvo9+3zdrd3csyjBWXX/EJjf6+HSRdAGMvJ 5j70vkG1WMywNBvL2LTokU89bH4PI3QW04StaADRcoaXRwQw35EdHcT6Bh0BhcPA9n+wIPkh XEXzxFjvEIK8j3WQIRIidR3eFfRGdz37/dCS/bO4o79TMBg4r0TzLylHFIns73M5i29NJ7TR 05SA5wYT5rX+bskVbMx1urDcDW+4kVeXdGR/irSjHqP2oS3oZe+H1Yt9ISQskEAguhTAIG0v XVINg93zPCC+Mmb1yIZkYyyaAGZVEkzQWDPCrFSeBtqQQ28zqK5ZxnCCKNw6O2t3z9Pu8uGf KyL6RJju61/qb2ZWaDH8wX7qPtYfNmjBTkb9iuex/jxEN2/KhqL+9vDH5G8P1TDA/BG7bOji 32p0BNSPg79N4HsxsP9IR1XWrNd70wFC26vBt6POMXyr7lnNv+L31NjLpIxidKwAIFxJvhom +x9+BiE1qpAHz2f0qenN1Tra1KQh2f/gE064IXslwn/pCrBHAUr4dY6Xh7251VO/AtkY9xUL ZRY0Sl/eBgYCMKXPqJiZBtb0TCwWRw70o1l/MQLKg5LfHYs8RIVBaiMXEQywJDdNzG1mrYjQ RossmuX43MNeNqGYhKAJf6bbuCTkjGcYsmAfJKs3virXm9iSwEBfFInmmBfAuAiS0IYxjGbJ XDtBIX39HMqU/f1HQTJ3qGuwvLtef5jBFaDolUX1Pi+i/jUIwNchBbfiU7QIWZ1lPUke640w KxaAwT/2iPzBN3L9GfhfSPcizpoZBybxDsUx230xCaAMFo1OQJNSWisvk9/9vYCozdLLIxTf 4IchymYUIOntgz4/4cBaFkIClExGEnfKZBFPCpybz3tsYSHrwDrI0xJIkbJG/D3Pr2FZqInN sfVSycJdAYOJhnNrKKP4crtiMV0Mc6y6lD4HAxYZD6NZOBPwTgqSpv8eBNOfdQBiYyrAGNxN grFYF+m+mfyY/dKADxxpwDYTooDSTH9XEpLewozsCdJPiXVj8FUvLjEtIisE2ks0NcGiDArY rIii4TM2ljK9FFpZTiexU0S+l6t14t9YwqLB2L3cpjxBzndxRatGk7VH3etZSTacmN51HaA6 YZPJPDth6Zrm43B4hNWJlhcVF3W5CNiN28qB4RBj0XAAzGf8V3ceg5r/Je0d5U+QDeWwfXDU 6rZ77z+ct/9KZwGVIzMSAgM8g2Kf53BAxovRPJiEmA4BvRC2+hgMXQyQErLYAMU0msYIpNTK AnIbRPMezZjYit4X/NlMM/gHgjIkT7xTyck9w8SpL7WHzu9PDj+AkHDa6r6vpA9q6mH00AyS VWqFjhU2LCJq69SJHu3ztfJx633bBxjbANwkhZsNKTKBWflxJ0iL9LwptUnO06QmA7pYDEsy QwmcUTi5nF+BwBUPh8jt4B9QDS00ddMv4VvRGOB56xJvBOmAnXuEbTqSfZ3+yhxqehHpu/4D tfLrneH3x6CPml84GHp26Xs14ueKb/Z1n4UYSx3eA0JWlsLfe3YcOIIdxqDT7SMvW8Ot311b M2gA81/DtdW/4Xf8jdZQ/0h/4K84Pf0jfq8RRBrz7po9A3jwdU/ryxn1Oj9topVkyEFdv8Jo qNERvhCOEWHzLRrznJW7i74DxydrjmCtRySF9Ooa/+SfDkN2w4CV3eVf8NPBG7FghA7yRDhr EsXjUBSTDCM9njX1iBJxJHNKjCvQimwrm+kwuuTdkaRDaFBcM/sakTW+Hs5mkxh/JafATZFx cMnEryDjiPBgw/KDYXczDK/Ys2IkpqBMz68rP7e7x7Bmb04UqFyq4lyzVGvqT92QDeC76k+k hRnSZXnK0MuR+KYkufLIUGSrIfIkcv6kQVce0fpW7VHpOJB9s5S9/tUMFtghxhb9fGROhO26 w45cBOllgVeQPf+Pre5x5/gtLsEuXu/8NKc95x0X9TN9Z7Hzlhmix41IGdch2Qn9+1d32CmQ Yo8mu40XoPeYyuM+xcGlB6xHHnuVhwi0jkcXJtug24p+bxbH894wWZpZ0HPsrSUofSMd9299 ZYZW2I4s7qo39ki3t/xbmB/nKATz9mU04oDTIaXuoyIS4HUTiHBkyHyboxppfw/5+F4EwZpF nhbIajhuPLwuehFQMJ8spr9/HRYTsxJdZiLOWughk/jrvtQadhkes3bAm+9BYRuZLFws6qXR MNstg04KI6xXIExmXS1znKCc8CUL7wxPXrbc2BLTFVNmQnT7wMzHmB6L0iHhXszM1SUmgg5v 4us0B6EFByP5WUZEOw4nbhla8U8iclNOatb4LfQ8DWYBa4H20IhxOOIq/bRpIT3nA7abiHOJ bgGCGf0Tj8c4ropOyfgLplGuZTM01nQSRPyt2/715Od2NYUFEl2Cb6O1MqFP3+OUwVa2um/P Ppy1DzOqhKQL/GaBdQUpNXHOs95aMiLaDHkuAbT7RPkM7iM+9ObyxeLLPCqKZafsTJNB7qGe x3Qv9XHBp7cRZsmuwGiJVZkH2n8DP+uqnanNkKIgYWA85fzgmFlQ+7oGcxsANkVvJ1jr1F4J tOU98L5oOjJX9iQlc5kDzFRjg0hzccazn9DgeBlKZhnTxrJQIcHKINxujiehChzOrUNE1ivJ AmKD0x9yB4+ndz0Mze9ha5CUJjU2m69XcYNrpJPFw0q6udWqelXu3CyrVm+/aX04Ol/F9Zrs +dFkEyQy8jv67TeU/syfj9R/k/YKWN593zr7ubrS2zvHv7aOVnm7xk5cgd40mF+BqDi6lgEM RbSbDDxyFI6beq8wIAmhWWExpjCWyWAzDe4hdPe/HRtzGH7ZEGhSWgH0TyUz2nr7+KR97N88 H+bBWAjd0ISKdns6G/M4ZoWFctXdbhYhIa90clE2hWEwRphAMORb8RSkwWZCfsWwmNEU3fPh +0p9YLVNH/he3Mecn3nMp0fPA9BF4K2UBps/ctCk4/JTpj/32Fv9WXZA9SePm0W7zzHmNkEl nMVgZBhgNCu+MdYffQgts6nZtlq6G6hqa7pQcCB/WHoiYcQHnB9uKMnoPMlkPWO038IjSuNf lm+UvnLzT6ss6kN/Vt4P8gTmBILEKdmSeeub0wrokyFgBVy16wp4zFTT/MuIBZQlSyqKGAZo wyCvYaojcaFbMQfgzJMoArK4MNDJksk5K0gc9lw2BM7SQyBk6+38NDaUXNoQ88haRIczs9iX Z8w+Pstj8PJaGd8fwGb5eDD4zdlNymszP+X5bTFyL2O39uVJ+hrC/vRPOgHuIHzH4AJ09+u9 Avz7Zc5JzEiQBmyf1P8ZzmKTcUwys2hlQjsRuXhjpcJcLoiRIpDfba3Wmktuz0z0RLQVM+8g VXjMzq8kA3KCKhz0OcBt6nHoBKeYMpk0TR4UTkCJyYRtUHDGyKcNiYXoyhXO+onqscmdgy/L pOzXYRwaEmajrVopq3Tu4dRDWadANW+CWeN77JIV6xxpMCexuD+Lg+s0mQ+X2clPeYV9Amm5 7dkn2+ZGK68euj3oZR06BShjiekt/dGzr+REU7H6vVLNan7QZQhRvOmDKOEssLS/jMjIDnm2 aejFZUyOQXe30cxB78FCkvXdhKN4ihroCosnHoH3Wj7dR0asi+nA8vk49tjKae9oiG4Lulhk SbegibmwLGyWrnJqqPf4JrJNRPoMwmEAal3hOc8RvpTsZs19jo0FL0iWmVi6oZWZazjU3sGG QK27TSkVOeXO11ROHDOHZJQnAR2jNxaYYhBO6zG6Po6odI1AQRM5X/U5qXd58U024ZnzroBM M5atQ5NWc3gv0LLOCfo7pixDxBkO8aaHbAwpACTdg3CE4YVkpqB36hwuhrqasoMs57Rbb1ud 42WGIZg6/fsW7VRkXMC5WEYfvnpU1l3txR3GxlAiGKclX0rCZl5OMElwiSnnOAMLAd3furPN 5h2+IhXbzvK71iVXqhnzjZrQ2PbR/k0uL7HFbbUzx+fQplMoUciivdQqjLT0auklpyY14/Cr YRw/mFB+dNrBvJaVk97xyfHro5ODn3+Dr4fto9anqkVW2I1RD+nVvpapPoe+0VCGDXFWk7eC 7oZti25q5JORRPTHb9lwdETaFZH64E01e4DfXeBDfN+w1iDfh3e8vI0sZr20UbppDf+u4koI fkEb9eiR+kH6lOLJx5MPR4e0336w0pAgewkt3jovI7RydXCB2RJHYZ9pHRUl1dmaMc06pWwm F8GQYlh+SjxUD4ncmEqHju7StL4C1vEmGZJVXIhKCdHKm6rTZ6xOS3EmBDhdcMpLXZwCh4ur zJEhTPMia9wqO/wSQvaGziCm5sQZYFoAlPGAspMLl4DOgNryOm0I/Srw2ljql+GQLTIdpsK2 95iLv96mdvEDLG3mUZjehyywwsNIr41ryjiE+PG0UcL/T0+OjjrH6jf60j08Pum+9yIqssJl iIqJdbOXdSC0303FI89kf6tqXRv5d1qWQmMr3gZS9jOUztMcxTiEb71cKUNYxZW1fvdtR+52 4z4+MVlml7NnDOLbSeWR7QYmD8hTTUz7Ot+eLnYhYfGu5765OxfB1oeUi6n3XRnEqoNgevap mKJWtN0sdcuuFnKv1V6ZMVTrG3wnNMg89agBxyfnJj5GYor1OogKICED6epSxRfRLLnYIgmA VGmPkyaH2kOab1b+7Ky2rSDYjo97bhNbQcg6OWaapgpJM3/vyvqdV58rWOElmgAZ31bkUSaD unMAsQxYnIRLecn/qsN7T480+/wWHtVidbJEjSxSHwu08bOrxRwHYJsHeX84czPX/MFc7cEg NKG+3Dd1762qYDiXiGw3oDxb4Q3X27XcoDKYRBOxqOh2SI4A/hwkDTKQHojRJPVvrtpASJ8K KZVxdIOKlBgYnDFqSw7s55DjoG0QtjwjuiYV1SswLKTjsBc3jRdxfi6xmqx8yuolH3ZSZnfG eJaUNWVVjBD+XOvfVDTQyksaONEqIykbroMsFdanTB0ZCNQYSzpjT3FY1qZs9cvr1sHPZ+ft 0zPTZTLIVzSkjPlXDCuhS8q5pg1YPMRym3CvmJVqDbm0dlrGkIptsxabJsWXUoaBCbjQNRY/ I8JxZUmJeoUeJniEirYNxKtGa/wSuxThGbkI7zAjuQ5DMal/uZKICSWhhIv9EE8C1TMRmzwD p8T4mIXCNgVoSkOK8y8cToSukxU0jpGwSqlKuFAKLNHjnzlNFea+nV9Vvb7YnwnCvgL9Wz1u NBpqK6vmao9pKbUZkxUFJkk542/ZjgoLYwKKcm/A1YQXNDQgzLMxBCTSZdUxcpKEe94uHWTo B4adQGUhp9wmg8x5e9OcjBt5/jEMqOSpeYPjiM7sQJRpxoVlHO0jJqaBlUlrouLK6fJuxIE6 J6kpRFtCMhEcDzacl1byvtQ248BGvcW0R3dEswUMCSie30HU0hp0CFKGo3jUihyLl1u/ZWvR 5mZUQMyYd5dxc7xd5X+QTWtyYxmp8Cpbaa7vec4VqJQpRJU+z67xivGCDMpZcZd3fuTEYegU QHcylLTDuOzZ9V0bdoWswIYxw6sEXfqEBEYd3sOE0pYtqn5WlBXQC91bmacUZSHky2/rfT+5 eoBj1dL+xj5XYwyQxdNANdcNf2FBIiD+TKm88aJdit0SjNyUUozEsK3CWZlcld6RmnDCSUq1 8Tzhb8ko5vhCE+Ljfz1G233Tm83FPKeV0wwqrXmB8ZXiXqDz7VOaeJTGbCyBRvAerCFrRSYJ I03QnEsVB6lkBA5Jm7ltfLHB6VQAQKxizKmCya0IEbG6RsQlRKDFLjK8QCfksAGgq0BSx5sy /G/YTyx+TbzBJFYxtdg4QawNZB5KuT9xWCA/m1BnKkCOU5OyOsL+OQ3B0Lll47Jp5LcQzjA/ tFzYaUO/GVESkrl6iLYrq2wCQ3FHUHzKLCqKEbI/7Nt0E93zfWiSRrqGyulAsbceAw+Og5me 5wZpEC/JcvqZjkrm9JRceptRuoMbOYpk9uMovUUfkEs9xlV3rPVXn0P2CZNRozFVfiaHp30k 0Ku4pJB1mmjs/r7lgbJCT/2R17LbwL74DWDm1uVeSF9pRbxj6Jx/hzG0D1YYwwp7nAL/bZ/5 23K4eTK3/M1f9eUFoFX+lOAeE4pvbKiXWVmvWkhOT0GSZsssxlcT9XYCtJ2DZSOWclzffA1Z +iBcK29Ia6fStbPH93oxnuqAfqTDaSw9RzmPOJtRQAbs2xCrcknmJwok3lxGbvZzBzR/rHN9 spQgnZ73DGf6b2zYc9zYsB5zGLy7AphTiud2Q0VMMWscCMWcXgvdIQDkPadZRFUz/NlvBZfU G17pF8UJjPe3U1hRkUTQ5liZ83mY+YKbjKF614kZ1kH6rq+ARSmyi4ljatJlkmfAvsP36FFe bvetFSV8sg2POEo0SwG/tFRiUXwdBa8EPVI9wrPyFAlDORXQDzvthL/4PCcyTTbDL9MI9kDt p3rlCr2IOvgdL7JNjZi97yp6+a7BYLDCTGRfPYZqR4eju1/PjSNgH98LV+i/niXqjyKf+5Wt kugPbXeyuEhwYjrKPalZ8SgByHvTaDC6I4EYd1FrdjlQKGaKPYSwIgxm0I0ET0/zIqdoF9Nf 2QvJhhMXlzVylbHOQTi6B4aZ4SzThPOvsTXyxkrp19FjE+TXgh0ltsZJzeUX0qcWk4xG5eje tsVZm9utxDPLdPJzdCiU+162vokToSmSLEJ2PiwpZyRvkjk8F8lUAzXXZIgsMpQ7Q0731sTP ZSjin+Flu3lDhOzJsklTpODEpJJBS7PP58hrj9A+ADjXpriQyA2OMTaSfTjR1kyt6qYwzIcy ilu2is86OdRbHWSWtZGsfDNRuuJWCiVlfEIsfcTZA+moH8coOP0L3Wca4tF98mu7q77amW9O dB6aOZkvHWezZTaCjpYTNJ/EZHaiRc4ApKRBnd2xJyCSIWZYMSXbvL+6npcYyvmE8GRfK/95 zTRifS/2SNjei3bzXSTnlcQiWUtjZeHU9QVUuMxH5V4zy8yjzg5rK7kQrea9sNIoqHIFsNZg 1BMKpEtlrBZT1W2fnbe652efzlYbuWVk7dFK9uKJ39rqTMM/CXvDGVHWM7ubtq3Xy8TuDPZf iVfSfTQF7vPtmgL2dzWF0g0svEHW1/7L6LqVScISuL879cxkh7NppaGh7kIhndWXLOnthL0w bMpU12PKN1XhxuvZa5iaevvmtIdaRvvItuJjcRGxhRaFyVkxb+/b732uPKUb71ca4ZfsRB3s kudqQ2Zftw91Xtbbl2Zb6rG3mYfyFuGMuXBdhjOHM0y8j1xEqoBmMSd7S5BJ/WfvPsXWr8vC NHJ4X8T0SpdZtqJRcrTJkOfZchlI4fFV+fdbY0/xo1ArLxHG7yeELxW+c5cMORqSOwy+UV3j 5vFTB/YKV+nkB7HSTXpdsn/qxMAH551f25UvVX5bBb4Zi1FVbkPRnp7Ko5HO5orXAOL+qKta 8DVAP57M8UJdfTg9bXd7raPTd63KhIPx05tm7U+O6V83ld0WX9HcopT423+faDTXI3aBqkpT vXwJ44avcH4xTso3YqcEujtqGoQeOlVKooEenXy0X2OK48Ks8WKAVkBumHEGpEmYMqeUmnYz CwcHsrP1GOdlTSI7v8yLK9kJwn/lJyyEsFOtVi3KckC5VWCGk/DWDvfEauNIu7b/TlkNdeZB L/+4gr6VNMfdenRVU4tecoWlZ6h3zo9PUz4aFqdNzPMcsqqXphUkMVAyCrIUf1RTX/PeX5n7 TKDkIV0KzXSKOFJNJLcilvej1CuXcYz1e6dXQcFVyVX9VZqxEd5vIxrPey/bmBdzPztneZrh mrxK9+GaDpzfxTwZEBlskeZacDeUzySqB60GcUj1mTGSr04pP9Fdw3H+Q8tMhS9iUrh7qC2+ dF68pzY2/EEAtoU/T1i9OIO5NNGZiQPaGGXym2lwyUatPEIVsGlJJkHeVTcSikpGYTsVd/4I pemPriKRqprPKEfrOPjCx1Dn2wSCUGm+fJnp4HeDweejWAA+53JgYyyDXgaQO1RFx815kqTv LPY2ScFY3iaZZNGn7zrMPjALW+PLi3Dn2bMXFy9wiJXLeDQA9XgcBkDB4O9tJc5NO9t6XBlo nXfvWmfvKkh3IlD70pzMlUqFcqzubMO5qeBLAV4F2pjbkL8r8yfdolQxiv+VquxsI9mMrqrp sXXoJoveREXMRYimInfsJ0ZBdDpgPfwSJcjEjCROUHQnUme5a6SLe0PXtPg4epuRM2kGewyx RDLM6dqzlNg0ia45GSiwIpRyvHJ+dOWI8ZwZ3Dkbm2mK+o0Nh8Ahmj2yTvT/cbflv9K2ovqL KAE9q+rRI+eQ44/W1RberV1bf//2m9INcBPTx3iJ6r8ayCvK6+q1eKtYVPyW6sprvYtkFssB jYqOj0Y+WPpUuTHoio/BbUhVKMjdM7VOz91o5hQWvmOCVSKU+kj3Z5gnFe0IPKCriO19hDWV H6xl9Nx/rwteiegxo3x8cx0oPJ1F42BGjhhXm57OeQtLAUpwsnsHI/QHGZPBuewbdJsr985W ihofHXWwfq8fJmGcw0NK4afshplLrm29ztgvf3oilvi5TfFbmDacZKfr8G7rJhgtJGeBnGxG V726xrWSpW8xCCacRQvDOAmJyJt+RIW70Dn5SzRejGskMxrfUep/cQfMdiHBurozQpqFdU7H QQZFdPAdUgMtkvqFONiiEtJRRi70GvsCNORqUuPoddUvsRghqsD7KR3YPLqy4as8LJGx9rNs tRg7iuQh/fFTj3fpKSd/Ngy5T2Lek7BgR3A7fLDEYUzLoNPRgu3liFnxBFM/X692PE1sCQnl j+ZEfO112QCVwH+evntWpAJSQeU7vJSCBEPnqLJkiD9lRUP4DWAUH/ihw19W8U1Bv0A8BZLB EwtKkH9YTXs1LoWAHvqh+scimVt51mELRAe8iLzX21kQ4SReXPqoca5pcbob/XHoqnG0KSGs 2Y8UpmXyQOiEy1nqI+MVv/UHIGzacraDHXuS8n56l5XSs2kU5cMGEJsDeO4nIrTEMdlIB5mR W1LhiYSVmnNIsriUPz0Z7lURaUQys7iJWVx7swcvC44NVsrxnhrt/eFSUgxM9vM4u5l3udhM f+2sl3wrUHy6ZC1hJ09J5EOGE8Pr6FqLjBxZAQmDXEO0V4MY4jVQRldsyfwDmFPB3jcye18u YYm7sQ3UPXIWMrhwK27T7OGsolzbWP7CAnyRqkUOyvhR5aVjubC5RTVvwZBO7j1Ijvu+yqmg GQE/h622FcsdwreIA36OfZ5BvcRoXkhx2TX5NvzJGOSAiX8nrlsv5LrLU585WFLqw1GACVL4 yks89Oc7sl57dvdkwfpTxIpNfAGs8MrAMD4qQeZr9hlUKCyVI6Kx4yS9HJaW0dizEeielMGI /dhSCGg589af383E9SfPzFU5N9efZVxdf74vd9efVbi8/ni4vTUJ/c1yTnRJcJYCe0mPuLji f7drRFDyL7O50PbqFKoz5Ah1OrF0RTAL49llMGFNAq9KRqOIoyNSi3wWTB610EL717/+lbNS jeJLVPvgTMSXi0RHIrCblM4htE05pbD0XzjLH4/1damDexlhNXLMGRZN+vFshhkzOKF8IrVX qbDo/IvnaHiGSc7O+7yyhD54x2rTI7/KsLf3fehnadCBAQdYU6/zEF/6+HPRh7tsyK2HzR6W H0DEoqx5jeD91wp9XRFmuyw1YOaTFTWKPkUiSIlVKPshvrzvmHJxrCWahjYjVmQvOBEpeljS vy9pwZfNFVMpEta9lP2B7hWr/+oE3YHpDKlaLZlG0dJR5cfSlTOSOlOYglaap5e1sY9dKd3M eCWkiV8fLHVlYesHGTSsZJ8UcjHLJO1cHj+Zhk9qWE4E5WJsBVB6WnB0A3tGYBDk98jqbhvT snXE3OBLtOal0Zdyb57XX2wFrCAhu7wT3RCgA8ZhkON+TU0osHkem4pW0oFzMLhluPQrdFIe KU+2qXmthyRmxF2rVy0r9xf4gpVLvtH1ZlGwitskDXxZjIva6FAW0b9KJkNSkT2ZR1GRL5ux l6GdUeyGSDr+EQ2HKBy+2k+3Y/X7iNMZ4ySHXySsQ/dH8cUF1xSehjOqfTzphz62r1qS6obi ddGpAtaF0l+F2fT5lMfCa4h0nADEQr2ajOEJGimiOHYsied9BWknYc3N+qbLqzYcdC8m+HYr irRvmCqLlVlYZa9bn3KnZUUHwEv19HGjUeX+/w08fQyLPffmyfYOYH1feWhtOqt9g0sb2eMs bW18xPQa9rGWnzMW2xzxZi+XZcS7yLrzfSg3J2rENyyn4d62WWpe0iFrW8pWifx2Qv29SWzB hupPVjBzaFMx9SyjmuXU0ljhXGovFLIQD22MM2HiAakNE0+ab0nn7Ckqyfst3DltQPuNN+wT JSMqDc7grXywkanYmd32VfixhRUrbj8qv3oJXCsUqnzphcFdOM+5/eeRpsy/ZyXkKfSKvCf6 mKeiXxlzapaV1hrVnKpNqcnQLJ73OqBmf1aZqacSMhar38izc/jsFnfiGvUsVq9IPGWHc1Wu KC3SMtLZJvtiPi99jhJlCtr63XBzJlc/WqxgM86jqTzQTrZ5yBYa+F5ro1PBgrruqs6C2ing lq1pmvmTSiJKtk/ESUpKkmbVJnsulxWLMES37yY9vkDvNE5SkdgpKlZNyGals3AipWBs8cTi T/zIsCadsCGQ5rOcU8+9qwG77pWS4oVdpQdhriaKIXl2C/ecA245JJKIo9eCayWZqXFiGVNr WFpklMbXJmebLERMdli5AMfhJBjWGdhl7fxLs6TasfdO6HMmmD2djz0yIk2H7SOgQxxGCgO0 qj9JBhsRZW4zifXT/H6LyZgSdgyKU21IcjtxePlw/B6zpnnXWbLgWUPzk+9v5DKFBOGPYj+F o58tODSOLPU09rQ8Vhj0Te6xAo9SD+ESz1L3idxlfMarjII002Iz+0zuaZh1mvJ0pFk7Sq80 nINhJwDJnxD9+epdEq9IVVDa0GS8Q9NsOEHv/jCxashikUtaLKohuzVMtkzJw8KUj95qvBdD U1CX9Capqisp1vkYjsJJzvH7NmPBcA+m1TDK5u2CvmP4DYCqunre4MuEq3gaouPNHWagN+53 6G2rfahuJa8jRqWjxit+fME8UzKgWGyDIWOubdLKhpWLIehjt1jQmyy3u3+b/7hI67um6JX1 /y6CgiyxEIjcjq4ABvEcwYy+EJwKTrfqO7fVP1YjgdH4D3bRwOUWY9dV+fk2klAAMMF/dvFm wHfYNzYiv8u4nzrAQKKCm1mLAMBR1/aUfOOiuf042FU/jgZb8H/c25pFOlySUGDs+Fx6NVX0 VrX+I7wOAIop3VXYPoc+Y3QRLNkV7+igzys4k2U0sAhshTcQJPgfqn5bj/4sQTr98SCf/viJ atHITn7+wR3QEt0ga1W5L+Ul4bKQ9PpLmf9u2ltwmUs3m0i2airnHaQjbhyFr1Bm0FEuPpqY tkoDZ/xkz3p7vo2JzCjYJ4fEGY9Qr29pES6ACM2+S3MpgkT1d/z4+o3Uj8IxNB8ZqAr8Xwhi 1eIHVjwFB3JlbewrMAiKJFnlTTq6I/MmcaFd4U36Lf73CIJV0sivVWAuQEmbcSwWjX9LKjvl I67uDRozMqwGGhiO7aRU9L6t9dL3GT2C2DWWVkAeoReJXj3eHGPQClp+8StHP+pv1T1Xcil6 j871Rycmw14Lyf1cIjtobCySwOmzQj5WAsK3vowCGso4DRJYCQZad1wIAgMfrASBTT2eUfCD lWCgz6V3FPhgJQjk7JwBMTZe0CuBEPet/J7Ig5WAiDdgHog8WA2I2dkskHvsLN9se/aFHyAM t9hACX0mLkAV0oJ5sAdU+GIRjTid7GbMoXeazankwUZoyHdaTMw8d05Vjr+nHTJKF/aDJ0NV Pw4WmEV8svhS3958vNmoYw6gF5rV0396zOI3+/l29Ul462/7oF6vrwp37fxqof4TVBzVVI3m bqMB/1PNF88aDzY2Nu7z0rUzUMNP+nOlnqvms12A9aSpthuNxoO//EXVG7WG2mjWdl6ov/xF ZB8ldkERYur6cjq5G1/Eo8Tkh+amB/H0bkZGucpBFQb44oU6i0YRyNjq7SyYXkWYa7Uz6WPm c1Dgutg0Ud0wCWc3ZE9hMCRu6SSsGISB8kQSD+e3wQxUgbSW4SBKgL5e4AUdBU8NtmA44xg2 7g5+YGCLyUBy+wNSjbF8m7oBGQNDhLe1avn2+IN6S+LdSJ1i7E1fHUV9TGuvdCrbKf6cXKUF Ud/goM5kUOpNDO+h7PuFs0gHO9A3Iqjoij0TBDkdFbhIQnJJgKYM6WPn/N3Jh3PVOv6kPra6 3dbx+ac9U9SNEjdzHYrpCCu2woAwrOzOlHR83+4evINOrdedo875Jyzy8aZzftw+O1NvTrqq pU5b3fPOwYejVledfuienpy1YYfecJUBDGO6YzgjWRMppjQg502sU357RQntzQjgBea6poZz J82AwtwY0txZm4kK+v14NsAbcD7eFD4pt9v0Nq7gnm4Xg/Hv2SZaeDEzsB4wZhnATAB3tezQ 0Tdsot2BgukUS+LGmNf9IppILYV46I6W00HSdOGnARpwY5MyGENB5QIe3frcZqjxJXFICaBK sUPvrFl4s6OEKxzhl/YMR9EN1gzgcyJrRMcQ0Ej1R0E0pszdGhpMZzZAr4MEzgBg821wx5er QyS6km1sJjaX61A8/jLnhEFlDsuQjt8MayNgjpDEnIVPcGTtVJWzsB9GmIghYM/RFc4h2j5k NRhD0vXb45palJ8U0Kz0eDL9qaknL+SUhlg6Qp1SVdS6OlsggJ2dRk29jpM5LND7lmpsN5vN enOn8QwEyDPM1KBrGzyQ6L9AXYezSTiiWgnxZBhd0oWByZ4vtYlqduo6NQxvNR0lOJI9Y0YU YGAlZDdFZnTF1kRNEI3UKA4GVGDknbaYPZDiDEmoE1qM1GWsAtxjk9ydM2FgIVgdMDrneqaw DVTm5dEDLj9B9/SUTQSPQlrU4T+iSX+0gIcvifcQj9m8eqV1UA7jHlQOTo7fdICpvkfDxm+/ +X7vcZw5aLV0B1BZT69Hqpn7EVKBkcvbLc1tQdV/XbCHiZDmTkp7IycsZfCTYBxGZVxdGhSz cmlA/JvY7hPVfLr7+MXu4x1mu6X8W/fOMO0Xu81GyrS3m7WnagP++wy5tspuzedFPA/iaYLb k3uISRzGwdT7DFa1fxXSrhZsN9lq51wFeeLHMip/DjiTh04Fa+7ozfbTIBlvLQJyy8NnOMEX TZrhi+a2THENs+n0+MBhUlG1pp29BtEMb73iaf1VnzKgVOCXGuAExkrXqIoptee8PBYIo/in 19e945N2t8vuYDVFcMRWd3wOjxEOppCnfEm7CHNaeSTv/yfyD36T5RFHk2lu79Bs4N8dPZ01 U9kWvpu5mMKc8KMnOXbhQGmu9VcDfS2RHTS8brrAyzVsRz98ldFPBpuZ3jiZJBxDKx77kxc8 9qf32orxNfzxx+7ECntBM9h5/JxmsPPEzCA/Bd8cZuPMHLhl8fC/aRprDr4gNng2hAuw/rav znqH7dYh7yDN7nGD9+dx83Gt+ZSn57pkKhu/TttY/1BeauaKl2LWxGGGoI2WRvn4vB7NZ92U Iu/P4ITvSa2t1PUWs/gCry5IEm2gZBYChcbcKCtVk5OhFBaIeJgrm4K5xVsJfyOyVtZx63ew tyKgDo+bw3+LzeH0eDPiygLZBcnd9hf1Zh8CT2/2JhDWiLh3+MuHk3NQiTvniB2Mn4wrPboB pxwpmpAwulrYxdUSGS+bgpc7j2vP5dTlUR2QXcwWNnHyEj/9uc/hujeQR7hgNftqvirEOCWZ XiLz+Pkzmu6TxuP7kEkQBQmJHUIZjwYoBfy/oJVPnjKnevLsxX2mQXOAYff0FGgQINH0rF39 vzyVZ4CAz2Eqz3ae15pNzXUpo0OPStjhcO2ONcI8pR7RuHNcfe1B3UHfjTyZxTNyE9oL4SxB CZ+oyGiWY7DVR8ZZ2AcQFjRKSUio18qadnIBCNi7GSa9WYgIJ2xfrbm+xryaghjPnu/o41y6 lkWrmGanwAUrSENxn3VZYT3U2hYHDA9jTPFHRkbeqWqalwn0f9DBJqaeEGijKMPyJldyqza/ m2Jl9MSURn9z1js5POx128et9+1qIUK4h2KZMoKJCXuk35ZpJHarYrXEbvWNuokDIqeg7FhW xWaDsKVRoKCgwulVQBZR7P09GU/pxP8vUE2ARhJdefKsBiqZMDbCEsBm2fe1tQTv2EA1razT elXdQts1NBgkc7n75Sr0vXkNdHu6/l0XLojnw9YK6pqFIhTAPpHcKmwB2Vfpz/VX/FrMO0C+ XUCuvrmvnpMMh55Kke6LBd5go2AAJ16DmMZk+qcu1vH06ybU7KswfeG0NE58GWa+oEXfaSDZ 2dhpPDWLTkvOpWmhB5X8uQD0xF80oclMVf+JigieWJDT2r2P3Q4wecxpUF9DelLJLcQNynn5 5cElvV8HXkdexEHcw9N0w8fppvJru9t58wnIR+uwpnhtb8L+HLkgLS+vlLWaGv4y3W+DVnSI 6h8tFnFQvVC75RRIjsGWHFo4AgW0Id+wgA7lG3pI0ZNlpMgDpfSOY+f5EyRH+A/TI5JGrCIn gHEsCqu1YB6Po35vjj/p7JhpYxB+8QFWkONnau2abFB4uFgWB9CIYPITfsXfSFeR3+j7EuLv TpEp3EqrwU1XWn5u+i33TF44q1wzNZ8+d+6Z/n159O/Lo39fHv378uj/r8sjIed15VaeJ1sS KR90N0RN/9QNGZd31Z/4h0PAVPmDfsCKNjdReGt+IEQZzHCLNfZi4dRxCNLmJErGnAgEtjEw lU+p/DNSSBkKwbkJZlG8SJSE5VBYR4REAkM6dIl1itvhvCMONIIgBzK0ovzgBFEXRCO0x+nL KNQ/KaQGwwJISL6JAsBAXq+4Px9xak0qt4OJqbEgGBYgkDJxEqqBSQguMAG9RFkA2gCZ4Fss 1aaQA+v3NFu9BYISeNK+TBbjC5iRySu0zpwC6RWNEFsG8DUcYYkGjG+60NMJuFIbnz4sII4X b1Y40gdcqg4uyhB+t7bOULF6umQ4ezUPrjGj+RViaTC7XFD6z10+2sH8itaPM5XydSC0Ceci SQbqIppzfCVot5jSGobJN492nfo01rZmar7HU1aGR3duguSAnEJQ/h8iGdeZjnPFcZmlrEsp P77HZK2f7jAlzbaZNRNQ3tKEUAKORYTvkGgywR4u4jUDHiExOen6zcKb+Dq8x/Kl+27fgA7l jtReRsY/K36IQpLxdTCVE+RFnBN03YquJvMALw4Rsgssm60PxkBK29HKmMcEgeEOanKXPI+n iT6dJiCO1Ghn8mnEkuwCFr5DeoXzReqZUITbFxDfEiprPcXjRLQiBdShsgmgxSUR10A2FApv ltHyYW6NmTZg2tsRcqBLjVAEBzdJO1DjQUWrf4wX2P1g5JCTyTARQmLGcBwjlSOq4lQjxLdT QBYuHgC+IlGN4/16c6mWckNhc3xiiavyZrIKvpiZiBKrxDkcTwrpCy4BQ4ihSYlzg72Xo+ii Ty84QqkXx03u/Jh3OaKIN16Z7EDgdfHoRicJB0RhQETD6LjEExEv2bNKR0HCWifETtVDPEkP tXgnNo6IKGBwK/gdaVrC1Q/DnwbcF48q3Z0PYkSbZNGnQFfnrSJbsmHWvvAfgiQ8VL2jzvGH v/LVxrs0YXvm57xZhn0ivBYbWim/LQdnk7oV0Pt7fUyii/9/sBF+gXlO1MODh3g7pbONPdhA iNjYYAvXrDDR3Xt2rnkaM9rpxIb4EM/Yw9TGugX4J/yITp8wU83DmXCbmPULvFKyq3jYGjga CMiruFG1oCPfIbqL+435wOjsI3++lBL2DqzW+Xm38/rDeVtgNW1YZM1A+fkWTlpyFU2XAJNg SDOwbRsYlUZC9RT95dUlmsvIipaDggWeuRdD2bGhaIkC1eQFMRtP/8653f9xbhQpEFIE5CKO EYIrZvR6GaASdGmANg3UrXU7whjnRnTYhHX69k/CczSsJxYsOm1oIqaoAkrkRvohUnsnDV4G KNUjpE/jyxA+DspxSTwcW1pf0LNwOsweQDSyIAzbIZzU8a7C4w36ovBRT6ZhH2QZisr0o7F8 nJS3uLTuMHShoLZVR9gO69QHU+yfFCVoXSy71B1ju9iOtWdPyhXG2IS6VQYCDTH2uqSpSrKd 0/QP/NHZXa3OROVlDXWYN4H4qmMe92QNzoBOL7R8o2Uj3AVcss7JAWD9aReUaK3NocR9IZ5f bCRg2oxR8SRlDdApeoybAfJCH3Tj0Z3IEjlhNaCUmnyjvq4ZdjjYQ36feT0QtXE4iIArE0ce MaaRQkBCnRQETRYX/8AkgCjkIGMxVyNSzCDlMHSxjnLFZB7NQgJCEGQFsFA6NiP9IJkCLOJl OY5KdMuV9tAsLzo1bYMrdmIkg/BIXpWxSHmwtliHU0Qx4nWTSJcrzSPlEPRwBFuMlsn8Hjjl 6YzGRfegFuD0Vz2YFKsMtzHyC+GUyJBbLCj6pmWoQTov69qBPuvRpDdE3WEvJd5am7CDsvWY VNotuXBmpBUF2qDcISg5cQDKe+KMnClHj0oBT/TJ03NLlwkk9cwKabTvtn89+fmw41siWbzi jZ/duB4WnudORobs7OC5zjoiL/PIIjjIX87bZ8C5ep2Tyk/RTzUFHDXfSB9g+UDjj9z6cc1a EU9HWoK21eFJzQyHy6bJARU/UhLDQKxPQPlpHR2dfOxJrMTJwfnRGUqMZMPoqxyD4redtZ25 PPUM6bBz1np91LbmIo2fVR3hL+X1eWlxmPxeD1QjUa7uiurpsIJHqvTyOKb6GHwlmtbCG5Q4 TNIG6UBlx6dYSNcdLHfYo/y+OXCpW0VNAKeFlTTiet+D/0UXh+L35V74unvSOjxonZ1TvgR8 Vxa0BcxdOIIoMTqYqY2o7L03NVNYqmQVSlZ+2aTcQKLfMUoDI8X0VP/KqT9fHdEy7WvrYkvD mNzbm6R/FQ5WvFyStivdLklbz/3e0/vd72lA5Vd8T8n/Cv8R9xTN25OefFsfJnsPmFWFEzFG TSgJI9nqyNvDuqW3+uFfHA76BtjKdRhOyQQzE5uBvsyAZ5SYxRi6XP1HnzQByxe3ap3zIvHI uDg0CEKTwUgyasOY4G3kOTXH58Rd8M899Go5ncVzkNES3ROFqQt8yiKqmZBUndYzgj/Zr+cx e/c+fqpdyfGDVrJgsLu2hm6AvfN3dClNt/l/4wbDBB6uPUJjdW+YuI9wrXbNQ/xLP6cF4NlC A/Qs4Ce6qz253bWz085x7+jk4GfQ6vCfNg8hbWtewnNzhyGlWqHNv8iHAT37kutN+XkTS9fW 1L/+1fj69WsNO5WeFzaMbKEiWuiG47QpOB9OG8+5eLbsXLgASs9Dc5u9to0DDtESoUOvzw4p 4BFEiV7r4OA87w8T9PtzdsQRalPmc5OmblnR+6bEwybzZHrJaQLE9+bxDvkVPd5p1ppPxPdm GkyifuVhaz7HChBcVu0aw2DIVDtAAyZg1Q8PjfsZIEL91TSimuPNaikIxK8fOMrUWUC0fqCl IRX7NFzG76I0RPW63crxxNUuBdXC5Ab6Y/EqH7BaamApTUykPxQZYI8938l6qtgnyMmNYNyH qZ1xVT99Q4PoHL/FlTdll3vJ3aRfeURtgc6MTOlltdIpBIJ9vewUcpvyU8ht1s4XoToLp2ob mFJzd+c5/G/FUygASk/hk2fElfCf5rbgaw8lgF7n+ACNKj1Co8q0/gr3vzeIx0E0qb/imC+D sfD4AljVeI7imPnDNCuBmmm5GiJPi9B4amHB4DKcWy33/A29KE4FZ/LoA9OAfoNoQA05wQn9 lNwG0ykZqui3VbDkOrkbJ8vQRBqV44k0+h3kWkMoxZTH5F77uCiiaxqPRl7HyPH4n0BVCx79 Ud6S/QC2IxpF8zvvi6+iy6tFNPA+u5hpN06KY3tKbGr76Y520QYN96R73jv79P71yVGFxJ5x cEe+cngcCh6zg13uOYezUWcOZijSE1N90AVgKTx73mep/uJ/rjWePRvN0RiNhv85yI+E1iQv ylUaJvwCmUrdzoIp/tuf3U3n+CWc9zdJa8hOkgPJeiPQmEJM4fs/5zmzVisfAQA= --------------35A29F60707E6D7019A27879-- -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon Oct 9 17:39:32 2000 Received: by oss.sgi.com id ; Mon, 9 Oct 2000 17:39:22 -0700 Received: from fly.HiWAAY.net ([208.147.154.56]:62215 "EHLO mail.hiwaay.net") by oss.sgi.com with ESMTP id ; Mon, 9 Oct 2000 17:38:42 -0700 Received: from hiwaay.net (IDENT:nickh@tnt11-216-180-50-53.dialup.HiWAAY.net [216.180.50.53]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id e9A0bx708753 for ; Mon, 9 Oct 2000 19:37:59 -0500 (CDT) Message-ID: <39E26609.E3A6CEB9@hiwaay.net> Date: Mon, 09 Oct 2000 19:42:49 -0500 From: Nick Hudson X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: [fam] installing in RH7?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hey guys, Im trying to install fam on RH7 and it doesnt seem to be working with I compile the source this is what i get: make[2]: Entering directory `/home/nickh/fam-oss-2.6.4/test' c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\"/usr/local/etc/fam.conf\" -g -O2 -c test.c++ test.c++: In function `void sendRequests (FAMConnection &, TestRequest *, int)': test.c++:83: `exit' undeclared (first use this function) test.c++:83: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [test.o] Error 1 make[2]: Leaving directory `/home/nickh/fam-oss-2.6.4/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/nickh/fam-oss-2.6.4' make: *** [all-recursive-am] Error 2 [root@Blackhawk fam-oss-2.6.4]# This is what i get when i try and install it via rpm: [root@Blackhawk My Documents]# rpm -Uvh --force fam* fam ################################################## Adding fam to rpc... Adding fam to inetd.conf... Restarting inetd... inetd: no process killed execution of fam-2.6.4-1 script failed, exit status 1 [root@Blackhawk My Documents]# Now Ive asked the redhat mail group about inetd.conf and they tell me that redhat 7 doesnt use that anymore that it uses the xinetd.conf now. So what can I do?? Or what can I change in the code to let me install fam??? Any ideas?? Thx Nick Hudson -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon Oct 9 18:41:33 2000 Received: by oss.sgi.com id ; Mon, 9 Oct 2000 18:41:22 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:24892 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 9 Oct 2000 18:40:43 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA25470 for ; Mon, 9 Oct 2000 18:32:02 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA09689; Mon, 9 Oct 2000 18:38:29 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010091838.ZM9594@rlyeh.engr.sgi.com> Date: Mon, 9 Oct 2000 18:38:29 -0700 In-Reply-To: "E. Brian Gast" "[fam] possible imon bug?" (Oct 6, 11:23pm) References: <20001006232335.A18179@cicero.ra.uc.edu> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: gasteb@email.uc.edu Subject: Re: [fam] possible imon bug? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > So, why do you get a deleted event for /tmp/foo in the first case when the > directory has something in it, but not the second with the empty directory? > It would interesting to see what IRIX does with this. I'm guessing the idea > is to keep the IRIX and Linux versions consistent. (I just tried it on IRIX, and you *do* get notified when the empty directory is deleted.) > When vfs_rmdir (in 2.4, do_rmdir in 2.2) is called an IMON_CONTENT event is > created for the parent directory. This is why nothing happens in the second > case, '/tmp' is not being monitored so imon doesn't report the event. Huh. It looks like this is similar to what happens in IRIX (vfs_rmdir does enqueue an IMON_CONTENT event, but as I'm not much of a kernel guy, I'm not sure whether it's enqueued for the parent of the deleted directory, or for the directory itself). If it's for the directory itself, that might explain why it works; the event is on a monitored inode, so imon passes it to fam, which sees that it no longer exists, and sends delete events to its clients. (On the other hand, it seems like that *wouldn't* work in the case where /tmp/foo/bar is a directory, and you're monitoring /tmp/foo, and rm -r bar; that does work on IRIX, so I don't know.) > So, it would seem that the correct thing to do would be to add an > IMON_DELETE event inside vfs_rmdir for the directory that is being deleted. > When I tried this out, the first case worked the same, and on the second > case I got a deleted and changed event on '/tmp/foo' (in that order). If > there are no objections I'll go ahead and add this to a future patch. That sounds good to me, especially since it works. (I would be curious to see whether making vfs_rmdir send the IMON_CHANGED event for the removed directory instead of its parent would also make fam work correctly, but that is arguably wrong, and your way isn't.) > Another question: Is there a document available which has a comprehensive > list of "when X occurs, imon reports Y" which I haven't stumbled across? It > would make knowing what to do in this kind of situation much easier. Yeah, not that I know of. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon Oct 9 19:31:52 2000 Received: by oss.sgi.com id ; Mon, 9 Oct 2000 19:31:42 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2157 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 9 Oct 2000 19:31:08 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA01921 for ; Mon, 9 Oct 2000 19:37:35 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA92232 for ; Mon, 9 Oct 2000 19:30:26 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA09802; Mon, 9 Oct 2000 19:27:55 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010091927.ZM9794@rlyeh.engr.sgi.com> Date: Mon, 9 Oct 2000 19:27:54 -0700 In-Reply-To: Nick Hudson "[fam] installing in RH7??" (Oct 9, 7:42pm) References: <39E26609.E3A6CEB9@hiwaay.net> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: nhudson@hiwaay.net Subject: Re: [fam] installing in RH7?? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Im trying to install fam on RH7 and it doesnt seem to be working > with I compile the source this is what i get: Does adding #include to the top of test.c++ make it work on your system? > This is what i get when i try and install it via rpm: > > [root@Blackhawk My Documents]# rpm -Uvh --force fam* > fam > ################################################## > Adding fam to rpc... > Adding fam to inetd.conf... > Restarting inetd... > inetd: no process killed > execution of fam-2.6.4-1 script failed, exit status 1 > [root@Blackhawk My Documents]# > > > Now Ive asked the redhat mail group about inetd.conf and they tell me > that redhat 7 doesnt use that anymore that it uses the xinetd.conf > now. So what can I do?? Or what can I change in the code to let me > install fam??? Any ideas?? First, you might see if rpm really did install fam. (I know that if a pre-uninstall-script fails during package removal, rpm will leave the package installed, even if it uninstalled packages the installed package depends on; no idea what state it leaves things in if a post-install script fails.) If it really didn't install fam, try running the rpm command again, but with the --noscripts argument. This should keep the fam rpm from trying to restart inetd. Then you'll probably have to edit xinetd.conf yourself. (Nuts!) I don't know what xinetd.conf looks like; can you post a few lines from your existing xinetd.conf file, and we'll see if we can guess what delightful new syntax it uses? Then I would say you'll need to tell inetd (or whatever equivalent RedHat 7 uses) to reread its configuration file, but my ability to guess how to do that is inversely proportional to the extent to which they changed it. (Did the RedHat guys mention *why* they changed it?) --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon Oct 9 20:06:03 2000 Received: by oss.sgi.com id ; Mon, 9 Oct 2000 20:05:52 -0700 Received: from fly.HiWAAY.net ([208.147.154.56]:39948 "EHLO mail.hiwaay.net") by oss.sgi.com with ESMTP id ; Mon, 9 Oct 2000 20:05:30 -0700 Received: from hiwaay.net (IDENT:nickh@tnt11-216-180-50-53.dialup.HiWAAY.net [216.180.50.53]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id e9A34k718401 for ; Mon, 9 Oct 2000 22:04:47 -0500 (CDT) Message-ID: <39E28871.5D20B9C4@hiwaay.net> Date: Mon, 09 Oct 2000 22:09:37 -0500 From: Nick Hudson X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 CC: fam@oss.sgi.com Subject: Re: [fam] installing in RH7?? References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Rusty Ballinger wrote: > > Im trying to install fam on RH7 and it doesnt seem to be working > > with I compile the source this is what i get: > > Does adding > > #include Ok I did that and it all installed with no erros that time thats the fam-oss-2.6.4 file and still when i try to start efm it says fam is bad!! But it compiled and installed with no errors?? > > > to the top of test.c++ make it work on your system? > > > This is what i get when i try and install it via rpm: > > > > [root@Blackhawk My Documents]# rpm -Uvh --force fam* > > fam > > ################################################## > > Adding fam to rpc... > > Adding fam to inetd.conf... > > Restarting inetd... > > inetd: no process killed > > execution of fam-2.6.4-1 script failed, exit status 1 > > [root@Blackhawk My Documents]# > > > > > > Now Ive asked the redhat mail group about inetd.conf and they tell me > > that redhat 7 doesnt use that anymore that it uses the xinetd.conf > > now. So what can I do?? Or what can I change in the code to let me > > install fam??? Any ideas?? > > First, you might see if rpm really did install fam. (I know that if a > pre-uninstall-script fails during package removal, rpm will leave the > package installed, even if it uninstalled packages the installed package > depends on; no idea what state it leaves things in if a post-install script > fails.) > > If it really didn't install fam, try running the rpm command again, but with > the --noscripts argument. This should keep the fam rpm from trying to > restart inetd. > > Then you'll probably have to edit xinetd.conf yourself. (Nuts!) I don't > know what xinetd.conf looks like; can you post a few lines from your existing > xinetd.conf file, and we'll see if we can guess what delightful new syntax it > uses? > > Then I would say you'll need to tell inetd (or whatever equivalent RedHat 7 > uses) to reread its configuration file, but my ability to guess how to do > that is inversely proportional to the extent to which they changed it. (Did > the RedHat guys mention *why* they changed it?) > > --Rusty The RH ppl didnt say why the changed it they just said that RH doesnt use the inetd.conf file anymore...... But i looked and i have a inted.conf file in my /etc directory and this what it looks like: ./lost+found ./boot ./boot/lost+found ./boot/kernel.h-2.4.0 ./boot/kernel.h ./boot/System.map-2.2.16-22 ./boot/module-info-2.2.16-22 ./boot/vmlinux-2.2.16-22 ./boot/vmlinuz-2.2.16-22 ./boot/vmlinuz ./boot/System.map ./boot/module-info ./boot/kernel.h-2.2.16 ./boot/boot.b ./boot/chain.b ./boot/message ./boot/os2_d.b ./boot/boot.0300 ./boot/map ./proc ./proc/dri ./proc/dri/0 "/etc/inetd.conf" 142899L, 7556074C and so on .......... now I do also have a xinetd.conf file but it looks nothing like this at all i donno why its like this.... here it is .......: # # Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d/ defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST RECORD } includedir /etc/xinetd.d thats what that looks like and i was like what the hell when i saw it doesnt make sence how they both could do the same thing???? weird heh maybe with the rest of the bugs with RH7 that people have seen i donno. See what you can come up with with that if you need anything else let me know ..... Thx Nick Hudson -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon Oct 9 23:05:13 2000 Received: by oss.sgi.com id ; Mon, 9 Oct 2000 23:05:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:45659 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 9 Oct 2000 23:04:31 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA11940 for ; Mon, 9 Oct 2000 22:56:06 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA09976; Mon, 9 Oct 2000 23:02:33 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010092302.ZM10041@rlyeh.engr.sgi.com> Date: Mon, 9 Oct 2000 23:02:33 -0700 In-Reply-To: Nick Hudson "Re: [fam] installing in RH7??" (Oct 9, 10:09pm) References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: nhudson@hiwaay.net Subject: Re: [fam] installing in RH7?? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Ok I did that and it all installed with no erros that time thats the > fam-oss-2.6.4 file and still when i try to start efm it says fam is bad!! > But it compiled and installed with no errors?? My guess is that even though it compiled & installed, it's not being started by inetd/xinetd/whatever. (You can see whether inetd/xinetd registered it with the portmapper by going "rpcinfo -p | grep fam"; if you don't get anything, it wasn't registered. If you do get something like this... 391002 1 tcp 1025 sgi_fam 391002 2 tcp 1025 sgi_fam it tells you that something has registered the fam service on port 1025, and you can go "fuser 1025/tcp" to find the ID of the process, and ps to find out the process' name & other information.) > The RH ppl didnt say why the changed it they just said that RH doesnt use > the inetd.conf file anymore...... But i looked and i have a inted.conf > file in my /etc directory and this what it looks like: > > ./lost+found > ./boot > ./boot/lost+found ... > "/etc/inetd.conf" 142899L, 7556074C > > and so on .......... Yeah, that looks horribly wrong, like the output from "find ." > now I do also have a xinetd.conf file but it looks > nothing like this at all i donno why its like this.... here it is .......: > > # > # Simple configuration file for xinetd > # > # Some defaults, and include /etc/xinetd.d/ There are a bunch of files in your /etc/xinetd.d? (like one per service started by inetd, maybe?) Could you send me a small one? And also the output from the command "ps -ef | grep inetd" ? --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 02:42:14 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 02:42:04 -0700 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]:4740 "EHLO tuminfo2.informatik.tu-muenchen.de") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 02:41:46 -0700 Received: from tuminfo3.informatik.tu-muenchen.de ([131.159.0.26] HELO tuminfo3.informatik.tu-muenchen.de ident: NO-IDENT-SERVICE [port 33135]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <110585-236>; Tue, 10 Oct 2000 11:40:58 +0000 Received: from in.tum.de (kreibich.modem.informatik.tu-muenchen.de [172.16.1.68]) by tuminfo3.informatik.tu-muenchen.de (Postfix) with ESMTP id 6721B2164A for ; Tue, 10 Oct 2000 11:40:56 +0200 (MEST) Message-ID: <39E2E4A7.B9277309@in.tum.de> From: Christian Kreibich Organization: Technische Universitaet Muenchen X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: Re: [fam] installing in RH7?? References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 10 Oct 2000 11:40:57 +0000 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Nick Hudson wrote: > > Ok I did that and it all installed with no erros that time thats the > fam-oss-2.6.4 file and still when i try to start efm it says fam is bad!! But > it compiled and installed with no errors?? I'd like to point out that efm says it's bad that it cannot connect to fam, not that fam is bad :) Best regards, -- Christian. _______________________________________________________________________ mailto:kreibich@in.tum.de http://www.in.tum.de/~kreibich -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 08:11:27 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 08:11:15 -0700 Received: from fly.HiWAAY.net ([208.147.154.56]:14854 "EHLO mail.hiwaay.net") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 08:10:55 -0700 Received: from hiwaay.net (IDENT:nickh@tnt11-216-180-50-53.dialup.HiWAAY.net [216.180.50.53]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id e9AFAB723213 for ; Tue, 10 Oct 2000 10:10:11 -0500 (CDT) Message-ID: <39E33277.B303EDC2@hiwaay.net> Date: Tue, 10 Oct 2000 10:15:03 -0500 From: Nick Hudson X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: Re: [fam] installing in RH7?? References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> <10010092302.ZM10041@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Rusty Ballinger wrote: > > Ok I did that and it all installed with no erros that time thats the > > fam-oss-2.6.4 file and still when i try to start efm it says fam is bad!! > > But it compiled and installed with no errors?? > > My guess is that even though it compiled & installed, it's not being started > by inetd/xinetd/whatever. (You can see whether inetd/xinetd registered it > with the portmapper by going "rpcinfo -p | grep fam"; if you don't get > anything, it wasn't registered. If you do get something like this... > > 391002 1 tcp 1025 sgi_fam > 391002 2 tcp 1025 sgi_fam ok when i do rpcinfo there is no such command for that heh so i donno what to tell you...... > > it tells you that something has registered the fam service on port 1025, > and you can go "fuser 1025/tcp" to find the ID of the process, and ps to > find out the process' name & other information.) > > > The RH ppl didnt say why the changed it they just said that RH doesnt use > > the inetd.conf file anymore...... But i looked and i have a inted.conf > > file in my /etc directory and this what it looks like: > > > > ./lost+found > > ./boot > > ./boot/lost+found > ... > > "/etc/inetd.conf" 142899L, 7556074C > > > > and so on .......... > > Yeah, that looks horribly wrong, like the output from "find ." > > > now I do also have a xinetd.conf file but it looks > > nothing like this at all i donno why its like this.... here it is .......: > > > > # > > # Simple configuration file for xinetd > > # > > # Some defaults, and include /etc/xinetd.d/ > > There are a bunch of files in your /etc/xinetd.d? (like one per service > started by inetd, maybe?) Could you send me a small one? And also the > output from the command "ps -ef | grep inetd" ? > no when i do the "ps -ef | grep inetd" i get this: [root@Blackhawk nickh]# ps -ef | grep inetd root 441 1 0 Oct09 ? 00:00:00 xinetd -reuse -pidfile /var/run/ root 14290 14277 0 09:26 pts/0 00:00:00 grep inetd [root@Blackhawk nickh]# and these are the files that are in me xinetd.d directory: [nickh@Blackhawk xinetd.d]$ ls finger ntalk rlogin swat telnet wu-ftpd linuxconf-web rexec rsh talk tftp [nickh@Blackhawk xinetd.d] and here is what they say in each ::: finger: # default: on # description: The finger server answers finger requests. Finger is \ # a protocol that allows remote users to see information such \ # as login name and last login time for local users. service finger { disable = no socket_type = stream wait = no user = nobody server = /usr/sbin/in.fingerd } ntalk: # default: off # description: The ntalk server accepts ntalk connections, for chatting \ # with users on different systems. service ntalk { disable = yes socket_type = dgram wait = yes user = nobody group = tty server = /usr/sbin/in.ntalkd } rlogin: default: on # description: rlogind is the server for the rlogin(1) program. The server \ # provides a remote login facility with authentication based on \ # privileged port numbers from trusted hosts. service login { disable = no socket_type = stream wait = no user = root log_on_success += USERID log_on_failure += USERID server = /usr/sbin/in.rlogind } swat: default: off # description: SWAT is the Samba Web Admin Tool. Use swat \ # to configure your Samba server. To use SWAT, \ # connect to port 901 with your favorite web browser. service swat { disable = yes port = 901 socket_type = stream wait = no only_from = localhost user = root server = /usr/sbin/swat log_on_failure += USERID } telnet: default: on # description: The telnet server serves telnet sessions; it uses \ # unencrypted username/password pairs for authentication. service telnet { disable = no flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID } wu-ftpd: # default: on # description: The wu-ftpd FTP server serves FTP connections. It uses \ # normal, unencrypted usernames and passwords for authentication. service ftp { disable = no socket_type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l -a log_on_success += DURATION USERID log_on_failure += USERID nice = 10 } linuxconf-web: # default: off # description: The Linuxconf system can also be accessed via a web \ # browser. Enabling this service will allow connections to \ # Linuxconf running in web UI mode. service linuxconf { disable = yes socket_type = stream wait = yes user = root server = /sbin/linuxconf server_args = --http } rexec: default: off # description: Rexecd is the server for the rexec(3) routine. The server \ # provides remote execution facilities with authentication based \ # on user names and passwords. service exec { disable = yes socket_type = stream wait = no user = root log_on_success += USERID log_on_failure += USERID server = /usr/sbin/in.rlogind } rsh: default: on # description: The rshd server is the server for the rcmd(3) routine and, \ # consequently, for the rsh(1) program. The server provides \ # remote execution facilities with authentication based on \ # privileged port numbers from trusted hosts. service shell { disable = no socket_type = stream wait = no user = root log_on_success += USERID log_on_failure += USERID server = /usr/sbin/in.rshd } talk: # default: off # description: The talk server accepts talk requests for chatting with users \ # on other systems. service talk { disable = yes socket_type = dgram wait = yes user = nobody group = tty server = /usr/sbin/in.talkd } tftp: default: off # description: The tftp server serves files using the trivial file transfer \ # protocol. The tftp protocol is often used to boot diskless \ # workstations, download configuration files to network-aware printers, \ # and to start the installation process for some operating systems. service tftp { disable = yes socket_type = dgram wait = yes user = nobody log_on_success += USERID log_on_failure += USERID server = /usr/sbin/in.tftpd server_args = /tftpboot } and thats all thats in that directory. but like i said when i do the "rpcinfo -p | grep fam" i get that rpcinfo there is no such command... but i hope this helps thx Nick > > --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 13:39:35 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 13:39:25 -0700 Received: from newman.bch.uc.edu ([129.137.195.205]:22547 "EHLO smtp.uc.edu") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 13:38:55 -0700 Received: from cicero.ra.uc.edu (t14-22.ra.uc.edu [129.137.229.78]) by smtp.uc.edu (8.9.3/8.9.2) with ESMTP id PAA13140; Tue, 10 Oct 2000 15:04:23 -0400 Received: (from ebg@localhost) by cicero.ra.uc.edu (8.9.3/8.9.3) id QAA11052; Tue, 10 Oct 2000 16:37:05 -0400 Date: Tue, 10 Oct 2000 16:37:03 -0400 From: "E. Brian Gast" To: rusty@sgi.com Cc: fam@oss.sgi.com Subject: Re: [fam] possible imon bug? Message-ID: <20001010163703.A11013@cicero.ra.uc.edu> Mail-Followup-To: rusty@sgi.com, fam@oss.sgi.com References: <20001006232335.A18179@cicero.ra.uc.edu> <10010091838.ZM9594@rlyeh.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <10010091838.ZM9594@rlyeh.engr.sgi.com>; from rusty@rlyeh.engr.sgi.com on Mon, Oct 09, 2000 at 06:38:29PM -0700 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Mon, Oct 09, 2000 at 06:38:29PM -0700, Rusty Ballinger wrote: > > So, it would seem that the correct thing to do would be to add an > > IMON_DELETE event inside vfs_rmdir for the directory that is being deleted. > > When I tried this out, the first case worked the same, and on the second > > case I got a deleted and changed event on '/tmp/foo' (in that order). If > > there are no objections I'll go ahead and add this to a future patch. > > That sounds good to me, especially since it works. (I would be curious to > see whether making vfs_rmdir send the IMON_CHANGED event for the removed > directory instead of its parent would also make fam work correctly, but that > is arguably wrong, and your way isn't.) Ok. It does seem correct that a IMON_CHANGED event gets sent for the parent directory, which was changed, and another IMON_DELETE event is sent for the child, which was deleted. This also seems to be the problem with the other two know bugs -- in each case imon was only generating an event for the parent directory, which isn't monitored, and the event gets ignored. I should do a little more testing to make sure I didn't break something else and then I'll put together an imon-0.0.2 patch for kernels 2.2 and 2.4. > > Another question: Is there a document available which has a comprehensive > > list of "when X occurs, imon reports Y" which I haven't stumbled across? It > > would make knowing what to do in this kind of situation much easier. > > Yeah, not that I know of. I guess I'll just go off of the description of the events on the Fam manpage and try to back out what Fam expects from imon to get there. Brian -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 14:20:35 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 14:20:25 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14396 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 14:19:49 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA09402 for ; Tue, 10 Oct 2000 14:26:17 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA11228; Tue, 10 Oct 2000 14:17:51 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010101417.ZM11251@rlyeh.engr.sgi.com> Date: Tue, 10 Oct 2000 14:17:51 -0700 In-Reply-To: Nick Hudson "Re: [fam] installing in RH7??" (Oct 10, 10:15am) References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> <10010092302.ZM10041@rlyeh.engr.sgi.com> <39E33277.B303EDC2@hiwaay.net> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: nhudson@hiwaay.net Subject: Re: [fam] installing in RH7?? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > > (You can see whether inetd/xinetd registered it with the portmapper by > > going "rpcinfo -p | grep fam"; if you don't get anything, it wasn't > > registered. If you do get something like this... > > ok when i do rpcinfo there is no such command for that heh so i donno what > to tell you...... Is /usr/sbin in your $PATH? If not, does /usr/sbin/rpcinfo -p work? > and these are the files that are in me xinetd.d directory: ... > and here is what they say in each ::: Hoo, hey, look at that: http://www.xinetd.org/ Bummer. From the FAQ: Q. xinetd doesn't work well with RPC, I need RPC and I really want to run xinetd. Can I? A. Yes. xinetd and inetd should happily coexist. Have your RPC stuff run from your normal inetd (removing all other services from your inetd.conf), then have xinetd run all your other services. fam does use RPC, sort of; libfam makes an RPC call to ask the portmapper what port to connect on. On the other hand, xinetd source does come with a program for converting inetd.conf to xinetd.conf; here's what it gave me for fam's entry: service sgi_fam { # itox didn't give this next line, but looking at the files # from your RH7 box make me think it might be a good idea. disable = no type = RPC rpc_version = 1-2 socket_type = stream protocol = tcp wait = yes user = root server = /usr/local/bin/fam } Try putting that in /etc/xinetd.d/fam, and going "killall -HUP xinetd" (hopefully that's one similarity between inetd & xinetd... according to the FAQ, it "understands different signals", and the unofficial tutorial says you should use -USR1 or -USR2, so you might try one of those if -HUP doesn't work). Then try running "/usr/sbin/rpcinfo -p | grep fam" to see whether xinetd registered it with the portmapper. Let me know where that doesn't work. If we can get it to work through xinetd, that will be best, but if we can't do that, there are a couple of other ways we can do it. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 15:21:16 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 15:21:06 -0700 Received: from fly.HiWAAY.net ([208.147.154.56]:25863 "EHLO mail.hiwaay.net") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 15:20:50 -0700 Received: from hiwaay.net (IDENT:nickh@tnt11-216-180-50-164.dialup.HiWAAY.net [216.180.50.164]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id e9AMJZ709377; Tue, 10 Oct 2000 17:19:35 -0500 (CDT) Message-ID: <39E3971C.F8FEEFD5@hiwaay.net> Date: Tue, 10 Oct 2000 17:24:29 -0500 From: Nick Hudson X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: rusty@sgi.com CC: fam@oss.sgi.com Subject: Re: [fam] installing in RH7?? References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> <10010092302.ZM10041@rlyeh.engr.sgi.com> <39E33277.B303EDC2@hiwaay.net> <10010101417.ZM11251@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Rusty Ballinger wrote: > Is /usr/sbin in your $PATH? If not, does /usr/sbin/rpcinfo -p work? Yes that works here is what it gives me when i do that : [root@Blackhawk nickh]# /usr/sbin/rpcinfo -p | grep fam 391002 2 tcp 880 sgi_fam > > > Hoo, hey, look at that: http://www.xinetd.org/ > > Bummer. From the FAQ: > > Q. xinetd doesn't work well with RPC, I need RPC and I really want to > run xinetd. Can I? > > A. Yes. xinetd and inetd should happily coexist. Have your RPC stuff run > from your normal inetd (removing all other services from your > inetd.conf), then have xinetd run all your other services. > > fam does use RPC, sort of; libfam makes an RPC call to ask the portmapper > what port to connect on. > > On the other hand, xinetd source does come with a program for converting > inetd.conf to xinetd.conf; here's what it gave me for fam's entry: > > service sgi_fam > { > # itox didn't give this next line, but looking at the files > # from your RH7 box make me think it might be a good idea. > disable = no > type = RPC > rpc_version = 1-2 > socket_type = stream > protocol = tcp > wait = yes > user = root > server = /usr/local/bin/fam > } OK i added that to /etc/xinetd.d no problem there::: > > > Try putting that in /etc/xinetd.d/fam, and going "killall -HUP xinetd" > (hopefully that's one similarity between inetd & xinetd... according to > the FAQ, it "understands different signals", and the unofficial tutorial > says you should use -USR1 or -USR2, so you might try one of those if -HUP > doesn't work). Then try running "/usr/sbin/rpcinfo -p | grep fam" to > see whether xinetd registered it with the portmapper. I did the killall -HUP , killall -USR1 and USR2 then i ran "/usr/sbin/rpcinfo -p | grep fam" again to see what it gave me after killall that i ran and all said the same thing. [root@Blackhawk nickh]# /usr/sbin/rpcinfo -p | grep fam 391002 2 tcp 880 sgi_fam and i tried uninstalling fam from the bad install im getting and it wont uninstall the rpm it gives me this:: [root@Blackhawk rpm]# rpm -e fam-2.6.4-1 Removing fam from rpc... Original file saved as /etc/rpc.O2 Removing fam from inetd.conf... Original file saved as /etc/inetd.conf.O1 Restarting inetd... inetd: no process killed execution of fam-2.6.4-1 script failed, exit status 1 [root@Blackhawk rpm]# so no it still doesnt work at all when i try to install it again just does the same thing as before > > > Let me know where that doesn't work. If we can get it to work through > xinetd, that will be best, but if we can't do that, there are a couple > of other ways we can do it. > > --Rusty Thx again man for the help Nick -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 15:43:15 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 15:43:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:30023 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 15:42:43 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA29458 for ; Tue, 10 Oct 2000 15:34:17 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA77093 for ; Tue, 10 Oct 2000 15:41:31 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA11405; Tue, 10 Oct 2000 15:38:58 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010101538.ZM11365@rlyeh.engr.sgi.com> Date: Tue, 10 Oct 2000 15:38:58 -0700 In-Reply-To: Nick Hudson "Re: [fam] installing in RH7??" (Oct 10, 5:24pm) References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> <10010092302.ZM10041@rlyeh.engr.sgi.com> <39E33277.B303EDC2@hiwaay.net> <10010101417.ZM11251@rlyeh.engr.sgi.com> <39E3971C.F8FEEFD5@hiwaay.net> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: nhudson@hiwaay.net Subject: Re: [fam] installing in RH7?? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > I did the killall -HUP , killall -USR1 and USR2 then i ran > "/usr/sbin/rpcinfo -p | grep fam" again to see what it gave me after > killall that i ran and all said the same thing. > > [root@Blackhawk nickh]# /usr/sbin/rpcinfo -p | grep fam > 391002 2 tcp 880 sgi_fam Interesting... the portmapper is saying someone (xinetd? fam?) said they're listening for fam clients on port 880. You can find out which process this is by going "/sbin/fuser 880/tcp" (let me know if that doesn't work), and then "ps -ef | grep [that-process-id]" to find out more information about the process. If xinetd is listening on port 880, that's good. (Although if you tried to uninstall fam, and it failed during the post-uninstall-script, the actual files may no longer be there? "ls -l /usr/local/bin/fam" still shows the fam daemon?) If fuser gave an error message like "880/tcp: fuser: No such file or directory", that's bad; it means the process which registered with the portmapper is no longer running. > and i tried uninstalling fam from the bad install im getting and it wont > uninstall the rpm it gives me this:: > > [root@Blackhawk rpm]# rpm -e fam-2.6.4-1 > Removing fam from rpc... > Original file saved as /etc/rpc.O2 > Removing fam from inetd.conf... > Original file saved as /etc/inetd.conf.O1 > Restarting inetd... > inetd: no process killed > execution of fam-2.6.4-1 script failed, exit status 1 Yeah, the fam package has an uninstall script which tries to remove fam from inetd.conf (and tell inetd about it) when fam is uninstalled, and it looks like that's what's failing here. Try "rpm -e --noscripts fam" to uninstall fam without running the script. "Are you sure you want to do that though?!" --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 18:03:35 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 18:03:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38762 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 18:02:53 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA17439 for ; Tue, 10 Oct 2000 17:54:17 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA92548 for ; Tue, 10 Oct 2000 18:01:31 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA11578; Tue, 10 Oct 2000 17:58:59 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010101758.ZM11564@rlyeh.engr.sgi.com> Date: Tue, 10 Oct 2000 17:58:59 -0700 In-Reply-To: "E. Brian Gast" "Re: [fam] possible imon bug?" (Oct 10, 4:37pm) References: <20001006232335.A18179@cicero.ra.uc.edu> <10010091838.ZM9594@rlyeh.engr.sgi.com> <20001010163703.A11013@cicero.ra.uc.edu> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: gasteb@email.uc.edu Subject: Re: [fam] possible imon bug? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Ok. It does seem correct that a IMON_CHANGED event gets sent for the parent > directory, which was changed, and another IMON_DELETE event is sent for the > child, which was deleted. This also seems to be the problem with the other > two know bugs -- in each case imon was only generating an event for the > parent directory, which isn't monitored, and the event gets ignored. I > should do a little more testing to make sure I didn't break something else > and then I'll put together an imon-0.0.2 patch for kernels 2.2 and 2.4. Neat! BUT... As far as 2.4 kernels go, jrodman@suse.com mentioned that another mechanism for directory notification has already gone in. I'm looking at 2.4.0-test9 now, and it looks like include/linux/dnotify.h provides a facility for being notified by signals when the contents of a directory changes, a lot like the patch from willy@thepuffingroup (http://oss.sgi.com/projects/fam/archive/msg00091.html). (It's not there in 2.4.0-test1; I don't know which version it was introduced in.) On 2.4 kernels, fam should be able to use that; in fact, libfam could/should? do the fcntl itself instead of contacting the fam daemon. (The problem there is that it has to open the directory to do the fcntl, which means a client which monitors a lot of directories can run out of file descriptors, and if SIGPOLL/SIGIO is already being handled by the application, it won't like libfam installing its own handler which re-scans the directory--or stats the file, if that's what was being monitored--corresponding to the fd for which the signal was sent.) Anyway, an interesting thing to think about. Unless imon's hooks into the filesystem code are rewritten, in 2.4 kernels I think fam will probably have to live with the fcntl(directory, F_NOTIFY) mechanism. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 18:18:16 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 18:18:06 -0700 Received: from fly.HiWAAY.net ([208.147.154.56]:50959 "EHLO mail.hiwaay.net") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 18:17:47 -0700 Received: from hiwaay.net (IDENT:nickh@tnt11-216-180-50-180.dialup.HiWAAY.net [216.180.50.180]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id e9B1H0703503; Tue, 10 Oct 2000 20:17:01 -0500 (CDT) Message-ID: <39E3C0B0.D740D12A@hiwaay.net> Date: Tue, 10 Oct 2000 20:21:52 -0500 From: Nick Hudson X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: rusty@sgi.com CC: fam@oss.sgi.com Subject: Re: [fam] installing in RH7?? References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> <10010092302.ZM10041@rlyeh.engr.sgi.com> <39E33277.B303EDC2@hiwaay.net> <10010101417.ZM11251@rlyeh.engr.sgi.com> <39E3971C.F8FEEFD5@hiwaay.net> <10010101538.ZM11365@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Rusty Ballinger wrote: > > I did the killall -HUP , killall -USR1 and USR2 then i ran > > "/usr/sbin/rpcinfo -p | grep fam" again to see what it gave me after > > killall that i ran and all said the same thing. > > > > [root@Blackhawk nickh]# /usr/sbin/rpcinfo -p | grep fam > > 391002 2 tcp 880 sgi_fam > > Interesting... the portmapper is saying someone (xinetd? fam?) said they're > listening for fam clients on port 880. You can find out which process this > is by going "/sbin/fuser 880/tcp" (let me know if that doesn't work), and > then "ps -ef | grep [that-process-id]" to find out more information about > the process. Ok here it goes this is what i did : [root@Blackhawk nickh]# /sbin/fuser 880/tcp [root@Blackhawk nickh]# ps -ef | grep xinetd root 444 1 0 19:44 ? 00:00:00 xinetd -reuse -pidfile /var/run/ root 3335 3325 0 20:15 pts/0 00:00:00 grep xinetd [root@Blackhawk nickh]# ps -ef | grep fam root 3337 3325 0 20:16 pts/0 00:00:00 grep fam [root@Blackhawk nickh]# ls -l /usr/local/bin/fam -rwxr-xr-x 1 root root 114232 Oct 9 23:59 /usr/local/bin/fam [root@Blackhawk nickh]# as you can see when i did the "/sbin/fuser 880/tcp" nothing happened just went to the command prompt again. and when I did the "ls -l /usr/local/bin/fam" it gave me that the daemon was still there. No im not sure i wanted to uninstall i just wanted to see what it would do if i did. I donno if i told you what i was doing to try to get fam to work im tryin to install EFM with enlightenment. and they both compiled fine with no probs but when i try and install EFM it says the fam is bad!! but heh it compiled fine so it showed that fam was there so i donno. Thx again man Nick > > > If xinetd is listening on port 880, that's good. (Although if you tried to > uninstall fam, and it failed during the post-uninstall-script, the actual > files may no longer be there? "ls -l /usr/local/bin/fam" still shows the > fam daemon?) > > If fuser gave an error message like "880/tcp: fuser: No such file or > directory", that's bad; it means the process which registered with the > portmapper is no longer running. > > > and i tried uninstalling fam from the bad install im getting and it wont > > uninstall the rpm it gives me this:: > > > > [root@Blackhawk rpm]# rpm -e fam-2.6.4-1 > > Removing fam from rpc... > > Original file saved as /etc/rpc.O2 > > Removing fam from inetd.conf... > > Original file saved as /etc/inetd.conf.O1 > > Restarting inetd... > > inetd: no process killed > > execution of fam-2.6.4-1 script failed, exit status 1 > > Yeah, the fam package has an uninstall script which tries to remove fam > from inetd.conf (and tell inetd about it) when fam is uninstalled, and it > looks like that's what's failing here. Try "rpm -e --noscripts fam" to > uninstall fam without running the script. "Are you sure you want to do > that though?!" > > --Rusty > > -- > Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ > To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue Oct 10 18:44:26 2000 Received: by oss.sgi.com id ; Tue, 10 Oct 2000 18:44:16 -0700 Received: from newman.bch.uc.edu ([129.137.195.205]:43017 "EHLO smtp.uc.edu") by oss.sgi.com with ESMTP id ; Tue, 10 Oct 2000 18:43:46 -0700 Received: from cicero.ra.uc.edu (t12-07.ra.uc.edu [129.137.229.15]) by smtp.uc.edu (8.9.3/8.9.2) with ESMTP id UAA21439; Tue, 10 Oct 2000 20:09:20 -0400 Received: (from ebg@localhost) by cicero.ra.uc.edu (8.9.3/8.9.3) id VAA01062; Tue, 10 Oct 2000 21:42:24 -0400 Date: Tue, 10 Oct 2000 21:42:14 -0400 From: "E. Brian Gast" To: rusty@sgi.com Cc: fam@oss.sgi.com Subject: Re: [fam] possible imon bug? Message-ID: <20001010214214.B1015@cicero.ra.uc.edu> Mail-Followup-To: rusty@sgi.com, fam@oss.sgi.com References: <20001006232335.A18179@cicero.ra.uc.edu> <10010091838.ZM9594@rlyeh.engr.sgi.com> <20001010163703.A11013@cicero.ra.uc.edu> <10010101758.ZM11564@rlyeh.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <10010101758.ZM11564@rlyeh.engr.sgi.com>; from rusty@rlyeh.engr.sgi.com on Tue, Oct 10, 2000 at 05:58:59PM -0700 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Tue, Oct 10, 2000 at 05:58:59PM -0700, Rusty Ballinger wrote: > > As far as 2.4 kernels go, jrodman@suse.com mentioned that another mechanism > for directory notification has already gone in. I'm looking at 2.4.0-test9 > now, and it looks like include/linux/dnotify.h provides a facility for being > notified by signals when the contents of a directory changes, a lot like > the patch from willy@thepuffingroup > (http://oss.sgi.com/projects/fam/archive/msg00091.html). (It's not there in > 2.4.0-test1; I don't know which version it was introduced in.) On 2.4 It just went in with -test9. > kernels, fam should be able to use that; in fact, libfam could/should? do > the fcntl itself instead of contacting the fam daemon. (The problem there > is that it has to open the directory to do the fcntl, which means a client > which monitors a lot of directories can run out of file descriptors, and if > SIGPOLL/SIGIO is already being handled by the application, it won't like > libfam installing its own handler which re-scans the directory--or stats the > file, if that's what was being monitored--corresponding to the fd for which > the signal was sent.) > > Anyway, an interesting thing to think about. Unless imon's hooks into the > filesystem code are rewritten, in 2.4 kernels I think fam will probably have > to live with the fcntl(directory, F_NOTIFY) mechanism. > > --Rusty Yeah, I was looking through it yesterday. (That's part of what caused the collision with the imon patch in -test9 that Philipp Baer fixed.) I haven't written any code to try it out yet -- that's next on my list. It looks like it only supports monitoring the contents of a directory; there's nothing for monitoring a single file or watching execution(s). I think I'll send an email to Stephen Rothwell (his name is at the top of the files) and ask him if there are any plans to expand it to include file only notification. Although I guess Fam could hide that from the client; when a request to monitor a file comes in, monitor the parent dir, and then ignore changes to the other files. As far as execution monitoring goes, how important is that? Brian -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed Oct 11 14:41:22 2000 Received: by oss.sgi.com id ; Wed, 11 Oct 2000 14:41:13 -0700 Received: from fly.HiWAAY.net ([208.147.154.56]:19471 "EHLO mail.hiwaay.net") by oss.sgi.com with ESMTP id ; Wed, 11 Oct 2000 14:40:56 -0700 Received: from hiwaay.net (IDENT:nickh@tnt11-216-180-50-175.dialup.HiWAAY.net [216.180.50.175]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id e9BLds709377; Wed, 11 Oct 2000 16:39:54 -0500 (CDT) Message-ID: <39E4DF4F.BE3FA040@hiwaay.net> Date: Wed, 11 Oct 2000 16:44:47 -0500 From: Nick Hudson X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: rusty@sgi.com CC: fam@oss.sgi.com Subject: Re: [fam] installing in RH7?? References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> <10010092302.ZM10041@rlyeh.engr.sgi.com> <39E33277.B303EDC2@hiwaay.net> <10010101417.ZM11251@rlyeh.engr.sgi.com> <39E3971C.F8FEEFD5@hiwaay.net> <10010101538.ZM11365@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Another question is there a way i can start fam in user not as root?? I can add fam& to my .xsession file and login as root and efm will run fine nbut when i login as user it doesnt work because i need to be root to start fam. ??? thx Nick Hudson Rusty Ballinger wrote: > > I did the killall -HUP , killall -USR1 and USR2 then i ran > > "/usr/sbin/rpcinfo -p | grep fam" again to see what it gave me after > > killall that i ran and all said the same thing. > > > > [root@Blackhawk nickh]# /usr/sbin/rpcinfo -p | grep fam > > 391002 2 tcp 880 sgi_fam > > Interesting... the portmapper is saying someone (xinetd? fam?) said they're > listening for fam clients on port 880. You can find out which process this > is by going "/sbin/fuser 880/tcp" (let me know if that doesn't work), and > then "ps -ef | grep [that-process-id]" to find out more information about > the process. > > If xinetd is listening on port 880, that's good. (Although if you tried to > uninstall fam, and it failed during the post-uninstall-script, the actual > files may no longer be there? "ls -l /usr/local/bin/fam" still shows the > fam daemon?) > > If fuser gave an error message like "880/tcp: fuser: No such file or > directory", that's bad; it means the process which registered with the > portmapper is no longer running. > > > and i tried uninstalling fam from the bad install im getting and it wont > > uninstall the rpm it gives me this:: > > > > [root@Blackhawk rpm]# rpm -e fam-2.6.4-1 > > Removing fam from rpc... > > Original file saved as /etc/rpc.O2 > > Removing fam from inetd.conf... > > Original file saved as /etc/inetd.conf.O1 > > Restarting inetd... > > inetd: no process killed > > execution of fam-2.6.4-1 script failed, exit status 1 > > Yeah, the fam package has an uninstall script which tries to remove fam > from inetd.conf (and tell inetd about it) when fam is uninstalled, and it > looks like that's what's failing here. Try "rpm -e --noscripts fam" to > uninstall fam without running the script. "Are you sure you want to do > that though?!" > > --Rusty > > -- > Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ > To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed Oct 11 23:18:43 2000 Received: by oss.sgi.com id ; Wed, 11 Oct 2000 23:18:33 -0700 Received: from iplsin1-59-250.biz.dsl.gtei.net ([4.3.59.250]:28916 "EHLO publisher.kempler.net") by oss.sgi.com with ESMTP id ; Wed, 11 Oct 2000 23:18:06 -0700 Received: from term by publisher.kempler.net with local (Exim 3.13 #1) id 13jbgB-0000S7-00 for fam@oss.sgi.com; Thu, 12 Oct 2000 01:17:23 -0500 Date: Thu, 12 Oct 2000 01:17:23 -0500 From: Lyle Kempler To: fam@oss.sgi.com Subject: [fam] Re: fam Message-ID: <20001012011723.D618@kempler.net> Mail-Followup-To: Lyle Kempler , fam@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kempler@utdallas.edu on Fri, Aug 25, 2000 at 11:16:40AM -0500 X-Editor: Vim http://www.vim.org/ X-Info: http://www.twistedpath.org/ Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing I've been meaning to get to this for .. I guess 6 weeks? It's been on the back burner while I was busy with other stuff, like moving. :) * Rusty Ballinger (rusty@sgi.com) wrote: > (cc'ing the fam mailing list in case other people may have feedback on adding > a way to get stat information from fam & a way to ask fam for only the first > n files when monitoring a large directory.) Information I would've enjoyed having prior to writing that. :P > Yes. (It's funny, at every layer from imon -> fam -> application, the amount > of information which is discarded.) I agree, anything that fam learns from > stat() should be available to its clients. Absolutely. > Here are some random notes on adding this to the API & the protocol > between fam & its clients: > > - I can't break binary compatibility with the existing API (so no > adding members to the FAMEvent struct, changing arguments to > FAMMonitorFile(), etc.), but I'm happy to add new structs & functions. > Unlike the current API & protocol, whatever we add should be flexible > enough that people can add things in the future without having to come > up with horrible new function names like FAMOpen4(). You and I had discussed a compability layer for older applications. As long as we keep that layer in mind, I think we can break it as required. > - If you want extended events, there ought to be a way to tell fam > which additional attributes you want. (If you want everything fam can > get from stat(), you ought to be able to get it; but if all you want > is one field, you shouldn't have to shuffle the rest of the data > across the socket.) It seems reasonable to me that these settings be > per-connection rather than per-request. Yeah, per session rather than per request seems much wiser to me, and can be relatively easily addressed. > - One potential use of the extended information is inside fam itself. > When fam starts monitoring files/directories which are mounted from a > remote host, it tries to ask fam on the remote machine to monitor > those files (much better than polling over NFS). If the remote fam > can supply all the stat info that the local fam needs, the local fam > shouldn't have to stat the files. (Neat!) I have an issue with that only because I don't like that fam must run as root. While it's certainly nice, it keeps users from being able to use fam-based applications if they don't have root (for instance, like me at work). We should find some way to address that problem, without sacrificing the obvious win in having this (perhaps having fam's internals view a remote fam or having root like imon: it's nice, but not required). Also, does /dev/imon require being accessed by root? Or can an ordinary user talk to it? If not, something else to consider.. > - Since fam clients might be across the network from fam, the stat > info has to be portable. (How do we handle a client on a machine with > a 32-bit off_t famming a large file on a machine with a 64-bit off_t, > for example?) I expect someone's dealt with this before, so we'll just have to find out who and see what they did, and hopefully just follow their conventions. ;) > - As the amount of information fam provides to clients goes up, so > does the risk of a buggy fam being a useful tool for hostile clients. > I think fam is secure but it's one more thing to lose sleep over if > you're so inclined. Security is definately a big deal for any root application. I wonder what kind of chroot()ing et al (e.g, capabilities under Linux) we could add in that would make unforseen bugs less dangerous. > No... & I think most (all?) fs's don't even store them sorted in an > order which is useful to people; ls -1f on both xfs & ext2 gives you > the files in whatever order the filesystem found most useful to store > them in. I think this means that *any* process (even in kernel space) > has to traverse the entire directory before giving you any portion of > a sorted list. (And I believe imon doesn't do this, in case you're > saying it already does!) Yeah. I still like it though. Sure, you pay an up-front cost, but the payoff can be very advantagous. I'm not suggesting imon does this :) > Also, it seems like when you ask for "the first 15 files", keep in > mind the kinds of filters & ordering a decent file manager will give > you: sort by size, by type first & name second, by modification date, > reverse, only show me *.txt, include hidden files, etc. Anything > which is going to give you "the first 15 files" ought to be flexible > enough to let you specify the sort criteria, file globs for filtering, > and the locale. (Is there some existing library which does this? > Seems like a generally useful facility.) I would see this as per-session as well, and I would definately want the number of sorting algorithms limited, to keep complexity down. > Now, in the case where fam is looking at a 1000-file directory, a lot > of traffic can be saved if it can pass back only the "first" 15 > files... so this flexibility, although hard to do, might be worth the > effort. (On the other hand, what's a client application going to do > once it's got the first 15 files? Ask for the remaining 985, I > think... But still, if the application can remain responsive while > this is happening, and without simply processing n events per visit > from the main select() loop, that's an improvement.) I think some applications may immediately ask for the other files, but newer applications can do that smarter. The payoff is in reaction time: after the first read, every subsequent access to that directory yields significantly less traffic. The application would no longer have any good reason to cache file lists between uses, if it does it, and if it doesn't, it would take much less time to go from request for files to display. Of course, it's just a theory. I'd like to see if it pans out. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed Oct 11 23:28:02 2000 Received: by oss.sgi.com id ; Wed, 11 Oct 2000 23:27:52 -0700 Received: from iplsin1-59-250.biz.dsl.gtei.net ([4.3.59.250]:31988 "EHLO publisher.kempler.net") by oss.sgi.com with ESMTP id ; Wed, 11 Oct 2000 23:27:27 -0700 Received: from term by publisher.kempler.net with local (Exim 3.13 #1) id 13jbpG-0000TT-00 for fam@oss.sgi.com; Thu, 12 Oct 2000 01:26:46 -0500 Date: Thu, 12 Oct 2000 01:26:46 -0500 From: Lyle Kempler To: fam@oss.sgi.com Subject: Re: [fam] Re: fam (fwd) Message-ID: <20001012012646.E618@kempler.net> Mail-Followup-To: Lyle Kempler , fam@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kempler@utdallas.edu on Fri, Aug 25, 2000 at 11:16:49AM -0500 X-Editor: Vim http://www.vim.org/ X-Info: http://www.twistedpath.org/ Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing * raster@rasterman.com wrote: > actually i see zero use for pre-sorted files - it just puts complexity > in fam that wont cover all cases - then fam has to also sit and wait > till it's read all 1000 or whaetvere file sfirst then sort THEN dump to > the app - no - i think it's bad. Only the first time. After that, the cost drops significantly, and takes the load of sorting and holding onto all of that information off of the application, saving resources and traffic. Since fam is designed to run (essentially) all the time, only the first access pays. Since users generally access the same directories all of the time, the cost is amortized well. > it shoudl be up to the client to figure what it wants to do with the > files it gets. it can so anything it wants then and save > pre-processing the list which won't save processing - it just shifts > it to fam and then limits it to what fam can do. :) I don't see how it limits fam.. fam can maintain the list pre-sorted to the last sorting request, or by filename (which I'm going to take as the most common sort on the files), and simply resort as needed, with whatever optimizations. Fam is already tracking all of that information and caching it, it costs less to leave it in there and have it maintain that information, sorted, system-wide, for the application. After all, that's one of the main reasons to use fam, having one program doing the file polling on behalf of all fam-using applications.. otherwise, you're just inducing a ton more copying across a connection than is necessary in most cases, for at best a small gain. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed Oct 11 23:35:32 2000 Received: by oss.sgi.com id ; Wed, 11 Oct 2000 23:35:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39759 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 11 Oct 2000 23:35:00 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA03019 for ; Wed, 11 Oct 2000 23:41:30 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA13449 for fam@oss.sgi.com; Wed, 11 Oct 2000 23:33:03 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010112333.ZM13583@rlyeh.engr.sgi.com> Date: Wed, 11 Oct 2000 23:33:03 -0700 X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: fam@oss.sgi.com Subject: [fam] imon 0.0.2! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing E. Brian Gast fixed the most irritating imon bugs, and posted patches for both 2.2.17 and 2.4.0-test9 kernels, but the list bounced the message because of its length. I've added the patches to http://oss.sgi.com/projects/fam/download/ and have updated the web pages. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu Oct 12 01:48:53 2000 Received: by oss.sgi.com id ; Thu, 12 Oct 2000 01:48:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27738 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 12 Oct 2000 01:48:30 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id BAA00130 for ; Thu, 12 Oct 2000 01:55:00 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id BAA13744; Thu, 12 Oct 2000 01:46:33 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010120146.ZM13753@rlyeh.engr.sgi.com> Date: Thu, 12 Oct 2000 01:46:33 -0700 In-Reply-To: "E. Brian Gast" "Re: [fam] possible imon bug?" (Oct 10, 9:42pm) References: <20001006232335.A18179@cicero.ra.uc.edu> <10010091838.ZM9594@rlyeh.engr.sgi.com> <20001010163703.A11013@cicero.ra.uc.edu> <10010101758.ZM11564@rlyeh.engr.sgi.com> <20001010214214.B1015@cicero.ra.uc.edu> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: gasteb@email.uc.edu Subject: Re: [fam] possible imon bug? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > > Anyway, an interesting thing to think about. Unless imon's hooks into the > > filesystem code are rewritten, in 2.4 kernels I think fam will probably > > have to live with the fcntl(directory, F_NOTIFY) mechanism. > > Yeah, I was looking through it yesterday. (That's part of what caused the > collision with the imon patch in -test9 that Philipp Baer fixed.) I haven't > written any code to try it out yet -- that's next on my list. It looks like > it only supports monitoring the contents of a directory; there's nothing > for monitoring a single file or watching execution(s). I think I'll send > an email to Stephen Rothwell (his name is at the top of the files) and ask > him if there are any plans to expand it to include file only notification. > Although I guess Fam could hide that from the client; when a request to > monitor a file comes in, monitor the parent dir, and then ignore changes > to the other files. Yeah, that's the way I was figuring it would work too. The only bummer is having to use one fd per directory! (But really, most clients probably only monitor one directory or file anyway... and if they only monitor local files, it might be just as well--or better--for libfam to use that fd for the open/fcntl on the directory instead of communicating with fam... but for applications which monitor lots of directories, or files mounted from remote hosts, it's not so good.) On the other hand, since that inode_dir_notify is in all (or most?) of the places where IMON_EVENT wants to be, perhaps the imon patch gets a lot simpler for 2.4 kernels: it just adds IMON_EVENT in __inode_dir_notify. :) > As far as execution monitoring goes, how important is that? Arguably "not very". In IRIX, it's used by the desktop to change executables' icons depending on whether they're running. In fact that's about all you can use it for; as long as one instance of an executable is running, I'm pretty sure you don't get execute events when additional instances of that executable start or stop. (So for example you couldn't use it for a security auditing tool or for analyzing usage patterns.) But it depends on who you talk to; some people really like it. (I think it's neat.) --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu Oct 12 17:18:09 2000 Received: by oss.sgi.com id ; Thu, 12 Oct 2000 17:17:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3119 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 12 Oct 2000 17:17:19 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA07182 for ; Thu, 12 Oct 2000 17:24:30 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA14832; Thu, 12 Oct 2000 17:15:59 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010121715.ZM14826@rlyeh.engr.sgi.com> Date: Thu, 12 Oct 2000 17:15:59 -0700 In-Reply-To: Nick Hudson "Re: [fam] installing in RH7??" (Oct 11, 4:44pm) References: <39E26609.E3A6CEB9@hiwaay.net> <10010091927.ZM9794@rlyeh.engr.sgi.com> <39E28871.5D20B9C4@hiwaay.net> <10010092302.ZM10041@rlyeh.engr.sgi.com> <39E33277.B303EDC2@hiwaay.net> <10010101417.ZM11251@rlyeh.engr.sgi.com> <39E3971C.F8FEEFD5@hiwaay.net> <10010101538.ZM11365@rlyeh.engr.sgi.com> <39E4DF4F.BE3FA040@hiwaay.net> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: nhudson@hiwaay.net Subject: Re: [fam] installing in RH7?? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing (apologies if anyone gets this twice) > Another question is there a way i can start fam in user not as root?? I > can add fam& to my .xsession file and login as root and efm will run fine > nbut when i login as user it doesnt work because i need to be root to start > fam. "Sort of." fam needs to run as root, but since you have root access on your box, there are (at least) four ways to do this. 1. (the best, I think) Get it working through xinetd. (I don't actually know whether this is possible, since fam uses RPC a bit.) I will download xinetd and see if I can get it working on my box. 2. Get inetd, and run it in addition to xinetd, and start fam through inetd. (That's what all the existing fam stuff expects.) Kind of lame to have to run both inetd and xinetd, though, and especially lame to have to run inetd just for fam. 3. Start fam through an init script. You would want its start script to be called after the portmapper, and its kill script to be called after any of its clients would have been terminated, and you'd want to start it with its -T 0 argument so that it wouldn't terminate when it didn't have any clients. If I can't get it to work through xinetd, this is probably the second best way to go; it's a mild bummer that it would be one more daemon process hanging around even when it wasn't being used. If you want to pursue this & need help with the init script, let me know. 4. Make fam suid-root, and fix the part in fam's main.c++ where it bails if getuid() != 0, and add fam to your .xsession. (The part where fam bails should first go setreuid(0, 0).) On a generally-single-user box, this might not be a horrible way to go, but I think an init script would be better. Anyway, I will try starting fam through xinetd on my box & let you know how it goes. (Has anyone else already done that?) --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri Oct 13 15:39:35 2000 Received: by oss.sgi.com id ; Fri, 13 Oct 2000 15:39:25 -0700 Received: from newman.bch.uc.edu ([129.137.195.205]:23304 "EHLO smtp.uc.edu") by oss.sgi.com with ESMTP id ; Fri, 13 Oct 2000 15:39:18 -0700 Received: from cicero.ra.uc.edu (t05-21.ra.uc.edu [129.137.228.117]) by smtp.uc.edu (8.9.3/8.9.2) with ESMTP id RAA10992 for ; Fri, 13 Oct 2000 17:05:22 -0400 Received: (from ebg@localhost) by cicero.ra.uc.edu (8.9.3/8.9.3) id SAA05907 for fam@oss.sgi.com; Fri, 13 Oct 2000 18:38:09 -0400 Date: Fri, 13 Oct 2000 18:37:43 -0400 From: "E. Brian Gast" To: fam@oss.sgi.com Subject: [fam] Directory Notification Message-ID: <20001013183742.A5802@cicero.ra.uc.edu> Mail-Followup-To: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing I'm thinking about sending the following questions about the new directory notification feature to the linux-kernel mailing list, with the intent of finding out what the plans are for directory notification and how that can be applied to Fam development. I'm posting here first looking for comments, additions, etc. Brian ---------------- I have a few questions about the directory notification feature that was added in -test9. I recently started contributing to the Fam/Imon project that SGI released (http://oss.sgi.com/projects/fam). Fam is a combination library and daemon which applications can use to monitor files on local and remote filesystems, and Imon is a kernel driver used to notify Fam when a change has been made. With the addition of directory notification into the main kernel, it looks like the Imon portion has become obsolete, and Fam can now be reworked to use it. The questions are: Are there any plans to increase the amount of data sent to the application, either before or after 2.4.0? Imon currently provides the device and inode of the file that changed. Without this, it looks like Fam will have to store the state of the directories it is monitoring so it find out which file actually changed. It looks like the options are increasing the size of the siginfo_t struct, or using the void pointer parameter in the sa_sigaction handler. I'm not seeing anything in the kernel which allows the use of the latter though. Are there any plans to implement file notification? Fam currently supports the ability to monitor a single file. Having this support in the kernel isn't that big a deal, Fam can easily monitor the directory and ignore changes to the other files. There is also some concern about Fam running out of file descriptors with applications which monitor lots of files, so it is probably a good thing to go directory only anyway. Currently, if the directory which is being monitored is deleted, no signal is generated. Any plans to change this? It would be possible to have Fam monitor the directory that the application is interested in along with its parent, but this would require two file descriptors for each "monitored" directory, cutting the number of directories Fam could monitor in half. Any plans to back-port directory notification to 2.2.x? I'm fairly new to kernel development, but I'm willing to help out with any changes that may or may not be decided on. Thanks for the time, Brian -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon Oct 16 02:51:48 2000 Received: by oss.sgi.com id ; Mon, 16 Oct 2000 02:51:38 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23874 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 16 Oct 2000 02:51:35 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA28210 for ; Mon, 16 Oct 2000 02:43:48 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id CAA28687 for ; Mon, 16 Oct 2000 02:51:04 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (SGI-8.9.3/8.9.3) id CAA20287 for fam@oss.sgi.com; Mon, 16 Oct 2000 02:48:33 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10010160248.ZM20300@rlyeh.engr.sgi.com> Date: Mon, 16 Oct 2000 02:48:33 -0700 In-Reply-To: "E. Brian Gast" "[fam] Directory Notification" (Oct 13, 6:37pm) References: <20001013183742.A5802@cicero.ra.uc.edu> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: fam@oss.sgi.com Subject: Re: [fam] Directory Notification Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > The questions are: > > Are there any plans to increase the amount of data sent to the application, > either before or after 2.4.0? Imon currently provides the device and inode > of the file that changed. Without this, it looks like Fam will have to store > the state of the directories it is monitoring so it find out which file > actually changed. Actually, it already has to store the state of all the things its monitoring; I think the problem here is that it will have to poll everything it's monitoring every time anything changes, which sucks. (So if you're monitoring a directory with a thousand files, every time one of them changes, you'll have to stat all of them.) If there's a way we can get the device & inode in the signal handler, that would be great. (Seems like there must be a way to get more information--otherwise, what is the point of the DN_ACCESS fcntl flag?) > Are there any plans to implement file notification? Fam currently supports > the ability to monitor a single file. Having this support in the kernel > isn't that big a deal, Fam can easily monitor the directory and ignore > changes to the other files. (especially if we can get the device & inode!) > There is also some concern about Fam running out of file descriptors with > applications which monitor lots of files This seems like a serious problem to me, but maybe it's not that big of a deal--if you're running out of fd's, fork and have the child handle the additional requests? (Seems like there's the potential for a lot of ugliness here.) --Rusty P.S. This is only related because it's something imon does: if someone is adding a way to get the device & inode in the signal handler, they should take the code from imon which keeps track of executing files (I think imon.txt describes it) and make it send notification whenever a file starts & stops executing (imon currently only sends notification when the first instance of a file starts executing, and when the last instance terminates). If you had that, and it also gave you the PID, you could write some really interesting tools. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com