Re: __STDC__ removal?
I'd support this. Makes maintaining the code a lot cleaner. M NetBSD is nuking almost all __STDC__ usages because it's always defined. Do we want to do the same? The exception I've seen is for assembler files where old style C is needed to avoid conflicts. mrouted/cfparse.y:#ifdef __STDC__ mrouted/cfparse.y:#ifdef __STDC__ mrouted/cfparse.y:#ifdef __STDC__ mrouted/defs.h:#ifdef __STDC__ mrouted/defs.h:#if defined(__STDC__) || defined(__GNUC__) mrouted/main.c:#ifdef __STDC__ mrouted/main.c:#ifdef __STDC__ mrouted/mapper.c:#ifdef __STDC__ mrouted/mapper.c:#ifdef __STDC__ mrouted/mrinfo.c:#ifdef __STDC__ mrouted/mrinfo.c:#ifdef __STDC__ mrouted/mtrace.c:#ifdef __STDC__ mrouted/mtrace.c:#ifdef __STDC__ mrouted/mtrace.c:#ifdef __STDC__ mrouted/mtrace.h:#if defined(__STDC__) || defined(__GNUC__) mtree/create.c:#if __STDC__ mtree/create.c:#if __STDC__ mtree/create.c:#if __STDC__ pppd/main.c:#if __STDC__ pppd/main.c:#if __STDC__ pppd/options.c:#if __STDC__ pppd/pppd.h:#if __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ rtsold/rtsold.c:#if __STDC__ zic/zdump.c:#ifdef __STDC__ zic/zdump.c:#endif /* defined __STDC__ */ zic/zdump.c:#ifndef __STDC__ zic/zdump.c:#endif /* !defined __STDC__ */ ee/ee.c:#if defined(__STDC__) || defined(__cplusplus) ee/ee.c:#ifndef __STDC__ ee/ee.c:#endif /* __STDC__ */ ee/new_curse.c:#if defined(__STDC__) ee/new_curse.c:#if __STDC__ || defined(__cplusplus) ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#else /* __STDC__ */ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#else /* __STDC__ */ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifdef __STDC__ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.h:#if __STDC__ || defined(__cplusplus) find/getdate.y:#if defined (__STDC__) || defined (USG) find/getdate.y:#if defined (__STDC__) lex/NEWS: - Changed to only use '\a' for __STDC__ compilers. lex/NEWS: and free() for gcc, which defines __STDC__ but (often) doesn't lex/NEWS: - Generated scanner uses prototypes and const for __STDC__. lex/flex.skl:#if __STDC__ lex/flex.skl:#endif /* __STDC__ */ lex/flex.skl:#if __STDC__ lex/flexdef.h:#ifndef __STDC__ lex/flexdef.h:#define __STDC__ 1 lex/flexdef.h:#if __STDC__ lex/initscan.c:#if __STDC__ lex/initscan.c:#endif /* __STDC__ */ lex/initscan.c:#if __STDC__ lex/misc.c:#if __STDC__ lex/misc.c:#if __STDC__ rpcgen/rpc_hout.c: f_print(fout, \n#if defined(__STDC__) || defined(__cplusplus)\n); rpcgen/rpc_main.c: f_print(fout, \n#if defined(__STDC__) || defined(__cplusplus)\n); telnet/externs.h:# ifdef__STDC__ telnet/externs.h:# if defined(__STDC__) telnet/ring.h:#if defined(__STDC__) || defined(LINT_ARGS) yacc/skeleton.c:#if defined(__cplusplus) || __STDC__, yacc/skeleton.c:#if defined(__cplusplus) || __STDC__, yacc/skeleton.c:#if defined(__cplusplus) || __STDC__, -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can I get some comment on my RFC???
Julian Elischer wrote: ah that one. I have no view then :-) (I have the gutt feeling it must be doable in some other way.. but can't think of it now..) :-) I looked at jails, but they put too much other restrictions. It is funny sometimes how you discover things by looking at source code. I was adding my little thing and then saw the Jail stuff. It seemed exactly the right thing, but the other stuff killed it as an idea. In general I really don't like to reinvent the wheel, IF I can avoid it. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can I get some comment on my RFC???
Terry Lambert wrote: Andy Sporner wrote: Hi Hackers, I would really like to have some input otherwise I might consider how usefull my participation on this list really is... Well, far be it for me not to comment, particularly if the lack of comments could hinder your future participation... I had the impression, thought it is rapidly diminishing that only certain people make impacts. I guess it is all about how to ask the question ;-) To me, this looks like a partial implementation of resource containers, with the ability to put each process into an arbitrary resource group If your need is to track all processes owned by init, which is what you say, then really, you are trying to solve a much smaller problem than the patches you give solve. It's possible I incorrectly stated the problem.I needed a container system to track an application (which might include daemon processes that normally attach themselves to init as a parent, or change their Group id) in a way they could not shake off the tagging. The idea was in the cluster software to guage how much resources (by walking the process table and adding up the resources (CPU for example)). This was to be used to find the best node to (re)start an application on failure of a node or on the initial start of the application. My initial approach was very static (no such patch) and it worked, but not well enough.For the sake of brevity, I wanted use the actual usage against the configured limit (a soft limit) to make decision on where to (re)start an application. I spent about 3 hours one afternoon in one of my better hacking moods putting this together. However, I think your patches are really very useful. Coming from you, I take high regard from this, thanks! Obviously, you could do this by GID, instead, if your different classes of demanding users ran under different default GIDs; and since an applicaiton could run under a GID via a single system call, and since it's required to make a system call to run under a different application ID... I'm not really positive that you've done anything that's really orthogonal to the default GID, in terms of providing additional information -- with the exception of the inheritance. That's the point, inheritance (and as I said I want this to be the stuff the process can not shake off it's feet--without knowledge of how). I would suggest that you restrict access to the cse_set_id(2) call. I would also suggest that you change it's name, and make it a mux system call: it's likely that people are going to find all sorts of things they want to do with the value of this; an obvious one will be getcseid, and another obvious one will be getpcseid (this latter is lacking for groups; thus your ID bears the same relationship to GID as UID bears to GID; i.e. it's an orthogonal credential value). I agree, I will do this. I also agree this this should be make as universal as possible. The only sticking point *might* be the other members of the structure that will be later used for process migration (as in Mosix). I have a working approach to failing over network sockets, though lacking in implementation. With this hardware device I am making that can switch the sheer number of trafic, I will use it as a front-end to a cluster and as part of the migration the registration of the endpoint will be changed on the front-end. On another point of usage, it could be a good way of tracking affinity of resources (as with process migration) so you don't have cross-node page fault wars (IE: Shared memory), so that if you move one process, you would have to move all in the group. I would like to start a dialog on this, but yes, I know the cluster list would be the right place ;-) BTW: CSE stands for (Clustered System Environment) so a name change would be very much needed to support a generic case. Perhaps the best thing is to split the patch into two and place the other members in another structure (since it is likely to grow) and perhaps if this patch is usefull it would be good to have it without having to have the clustering stuff too. *** Many other good points *** Thanks for your import--that was the goal of my 'RFC'. Now I have enough to go back and do some more work on it. I will post the new changes to my website later this week along with another piece of candy (graphical top), which was another piece salvaged from my clustering stuff. It's not clear if I will continue this clustering project for many reasons (mostly time related), days seem like months when I say I will put things out and I am sure there are those that think it doesn't exist at all. So this way I can do things more incrementally if at all. Best Regards -Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more info on pccard insertion hang...
M. Warner Losh [EMAIL PROTECTED] wrote:
In message: [EMAIL PROTECTED]
Thomas David Rivers [EMAIL PROTECTED] writes:
: Warner - any ideas?
: pci_write_config(..., bcr,2); hangs
Interesting
So this pretty much confirms what I'd expect. We establish the
interrupt handler, then turn on the interrupts, then hang. I suspect
that there's an interrupt in the bridge that isn't being acked. Maybe
there's something in the pcic_pci_intr that should do that it isn't.
There's also one thing that I've been thinking about in the back of my
mind that you might want to check. I read in the mindshare books that
the we're supposed to mask one of the interrupts while we're powering
the card up. Maybe that's left over and we're not clearing it
properly.
Does adding
for (i = 0; i 0x40) sp-getb(sp, i);
at the end pcic_pci_intr do anything for you? The PCIC_STAT_CHG
should do that, but I'm not sure why it isn't.
I added:
{
int i;
for(i=0;i0x40;i++) {
sp-getb(sp,i);
}
}
to the end of pcic_pci_intr() - but that didn't change anything...
got the same hang in exactly the same place...
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
RE:Do you offer free software on your site?
Hello, I have visited afew Web sites including yours and felt that you might be interested in submitting your link to our Website. We are about to launch a new Website called FindFreeStuff.net and invite you to list your Website URL with us. We are the final development stages and the formal launch of the site will be in 2 weeks. We are offering 1000 FREE banner impressions on the top banner spot as an incentive to the first 50 Website that submit a link. We have been given an advertising budget for this Website and will be advertising the Website through various channels from Internet to television. We ask nothing in return but a linkback would be extremely appreciated. If you're interested simply visit http://www.findfreestuff.net and submit your link. Thank you very much for your time. Edwin Huertas [EMAIL PROTECTED] P.S. This is a one time mailing. You will never receive another email from me or findfreestuff.net unless you request it. If I have emailed you in error please forgive me you will never get another email from me again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: __STDC__ removal?
In message: [EMAIL PROTECTED] Alfred Perlstein [EMAIL PROTECTED] writes: : NetBSD is nuking almost all __STDC__ usages because it's always : defined. Do we want to do the same? The exception I've seen : is for assembler files where old style C is needed to avoid : conflicts. I've already started doing the same. Feel free to beat me to it, however, since I don't have many in my queue right now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more info on pccard insertion hang...
In message: [EMAIL PROTECTED] Thomas David Rivers [EMAIL PROTECTED] writes: : to the end of pcic_pci_intr() - but that didn't change anything... : got the same hang in exactly the same place... Sounds like we may need to do the more extensive interrupt blocking/masking. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
[Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: __STDC__ removal?
* M. Warner Losh [EMAIL PROTECTED] [020527 11:22] wrote: In message: [EMAIL PROTECTED] Alfred Perlstein [EMAIL PROTECTED] writes: : NetBSD is nuking almost all __STDC__ usages because it's always : defined. Do we want to do the same? The exception I've seen : is for assembler files where old style C is needed to avoid : conflicts. I've already started doing the same. Feel free to beat me to it, however, since I don't have many in my queue right now. I really havne't started, I just wanted to get the ball rolling if it needed it. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more info on pccard insertion hang...
M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Thomas David Rivers [EMAIL PROTECTED] writes: : to the end of pcic_pci_intr() - but that didn't change anything... : got the same hang in exactly the same place... Sounds like we may need to do the more extensive interrupt blocking/masking. Warner Well - unfortunately I'm nothing more than a (slow) keyboard/screen for you... I don't know squat about PCI interrupts... But - I'm happy to try things out, just let me know what you need. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
As this thread once more suggests, the whole concept of pidfiles is broken. The proper way is to use a service control manager which keeps track of processes, allowing them to be stopped/restarted etc. through a single API. (I am not going to mention AIX's System Resource Controller again because some people on this list don't seem to like AIX.) Last time the discussion about daemontools seemed to end in it being a good idea but djb's license being unsuitable, iIrc. So on the 22nd I sent an e-mail to -hackers saying that I have found a BSD-licensed service control manager suitable for import into the base OS, in the hope of restarting this discussion. init(8) doesn't cut it for various reasons: single config file, runs as root, critical to system startup, etc. But it appears I am in a minority because so far I have only received one private response. Mnsho, of course. Jos On Mon, May 27, 2002 at 12:24:56PM -0600, Lyndon Nerenberg wrote: [Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On 27 May 2002, at 12:24, Lyndon Nerenberg boldly uttered: [Redirecting to the hackers list -- please respect the reply-to header] Sigh, well I guess I have another reason to join that list, what the heck.. Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. --lyndon Funny thing about that, I actually created a /var/run/named directory for just the purpose of running named in a 'sandbox', chowned the directory bind:bind, and because I forgot to set the pid file path in named.conf, I see that it seems to write named.pid (owned by bind:bind) into /var/run without a problem. I know some processes demote themselves after they initialize, maybe this is what the named daemon does. But you wouldn't know it, given the ownership of the pid file. (I'm sure this makes sense to people who know about this stuff, it still confuses me) Maybe the daemon creates the file as root than chown's it? -- Philip J. Koenig [EMAIL PROTECTED] Electric Kahuna Systems -- Computers Communications for the New Millenium To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Repeatable mkdir ffs panic (affects both Free- and NetBSD)
[This is sent both to the NetBSD list, plus FreeBSD, again, sorry]
Breaking all accepted rules of etiquette, I followup to meself:
I wrote...
Fatal trap 18: integer divide fault while in kernel mode
#5 0xc0201a7d in ffs_dirpref (pip=0xc14f1500)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:710
710 maxcontigdirs = min(cgsize / dirsize, 255);
int cg, prefcg, dirsize, cgsize;
cgsize = fs-fs_fsize * fs-fs_fpg;
dirsize = fs-fs_avgfilesize * fs-fs_avgfpdir;
the norm, would it be appropriate for me to waddle around in this
section of code, to use 64-bit numbers where appropriate, or is
I'm happy to report that my hacks, changing the types of
cgsize (in my case 8192 * 439808) and dirsize (67108864 * 64),
as well as curdirsize for good measure, from the original signed
32 bit int to a 64-bit type, and then frobbing all references
following, resulted in a failure to panic my machine when `mkdir'ing
a subdirectory, at least under FreeBSD.
I'll see if I can do the same with NetBSD, but I suspect so.
Since I never learned any C, much less the proper way of doing
programming, I'd be happy to submit my hacks to someone who will
not laugh too much, but gently advise me on the proper way to do
what I tried to do, and who can merge them into the source tree
if appropriate, to avoid these kernel panics, assuming it's not
blindingly obvious how to do this right from my description.
Now to re-newfs that big drive with even larger numbers, and see
if I can induce panics elsewhere...
And concerning `newfs', I figured out what's going on, and I
suggest that FreeBSD imitate NetBSD here, and add the following
lines to newfs/mkfs.c for a second exit(19) case:
if (sblock.fs_bsize MAXBSIZE) {
printf(block size %d is too large, maximum is %d\n,
sblock.fs_bsize, MAXBSIZE);
exit(19);
}
rather than letting memset() later overwrite zeros everywhere...
thanks
barry bouwsma
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
pjklist Funny thing about that, I actually created a /var/run/named directory pjklist for just the purpose of running named in a 'sandbox', chowned the pjklist directory bind:bind, and because I forgot to set the pid file path in pjklist named.conf, I see that it seems to write named.pid (owned by pjklist bind:bind) into /var/run without a problem. For named, the initial creation isn't the problem, it's the reloads and restarts: # ndc reload Reload initiated. # tail -2 /var/log/messages May 27 12:36:35 horsey named[142]: couldn't create pid file '/var/run/named.pid' May 27 12:36:35 horsey named[142]: Ready to answer queries. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On 27 May 2002, at 12:38, Gregory Neil Shapiro boldly uttered: pjklist Funny thing about that, I actually created a /var/run/named directory pjklist for just the purpose of running named in a 'sandbox', chowned the pjklist directory bind:bind, and because I forgot to set the pid file path in pjklist named.conf, I see that it seems to write named.pid (owned by pjklist bind:bind) into /var/run without a problem. For named, the initial creation isn't the problem, it's the reloads and restarts: # ndc reload Reload initiated. # tail -2 /var/log/messages May 27 12:36:35 horsey named[142]: couldn't create pid file '/var/run/named.pid' May 27 12:36:35 horsey named[142]: Ready to answer queries. Good point, I think I've seen that before. SO I suppose it's safe to say there is a different method of startup, IE named apparently creates the pid file as root, then chowns it afterwards and demotes itself, whereas sendmail doesn't bother. (not that it matters, as you mention, since named's handicap is just delayed) I have to say that with Bind-9, the fact that it starts as one uid and ends up as another is a hassle, because it makes logging more complicated than it should be. (starting as root then demoting, startup messages can only be logged in syslog, when I prefer logging everything to dedicated named logfiles) -- Philip J. Koenig [EMAIL PROTECTED] Electric Kahuna Systems -- Computers Communications for the New Millenium To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
Jos Backus writes: As this thread once more suggests, the whole concept of pidfiles is broken. The proper way is to use a service control manager which keeps track of processes, allowing them to be stopped/restarted etc. through a single API. (I I understand, but there no control manager now, and I suggest some tuning of rights --- etc/mtree/BSD.var.dist Mon Jan 14 14:23:15 2002 +++ etc/mtree/BSD.var.dist Sat Mar 9 20:32:38 2002 @@ -53,7 +53,7 @@ .. preserve .. -run +run gname=daemon mode=1775 ppp gname=network mode=0770 .. .. and every daemon in group 'daemon' while no better method am not going to mention AIX's System Resource Controller again because some people on this list don't seem to like AIX.) Last time the discussion about daemontools seemed to end in it being a good idea but djb's license being unsuitable, iIrc. So on the 22nd I sent an e-mail to -hackers saying that I have found a BSD-licensed service control manager suitable for import into the base OS, in the hope of restarting this discussion. init(8) doesn't cut it for various reasons: single config file, runs as root, critical to system startup, etc. I have a lot of troubles with djb's tools in jail environment: they are unreliable. Are you sure that http://www.io.com/~manoj/file/mktool-0.0.7.tar.gz (are you mean this one?) is better? I do not find docs or mans and am not sure that it is worth-while to dig in thist code instead of simple shell scripts (as in ports/38593 - that is my way to service control manager) But it appears I am in a minority because so far I have only received one private response. Mnsho, of course. Jos On Mon, May 27, 2002 at 12:24:56PM -0600, Lyndon Nerenberg wrote: [Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Tue, May 28, 2002 at 01:36:00AM +0400, .@babolo.ru wrote: I have a lot of troubles with djb's tools in jail environment: they are unreliable. Huh? What is the problem? While the license causes plenty of problems I have yet to see the programs themselves cause any. Now they may not be a natural fit to what you are trying to do in this case but that doesn't invalidate the idea of a service control manager in general - only perhaps the daemontools implementation for your particular application. Are you sure that http://www.io.com/~manoj/file/mktool-0.0.7.tar.gz (are you mean this one?) is better? It's hackable, which compared to daemontools is a big plus. And the author has said he is willing to add some more improvements and documentation. I do not find docs or mans and am not sure that it is worth-while to dig in thist code instead of simple shell scripts (as in ports/38593 - that is my way to service control manager) Re: docs, see above. If there's sufficient interest I can prod the author or write some myself. The problem with all these homegrown solutions is that they are not portable and lack the necessary features to be of general use, among others. I think first there needs to be consensus that having some sort of service control manager in the base OS is a good idea. Then we can look into possible candidates. Given the long tradition that pidfiles have in UNIX this is probably an uphill battle, even though I think there are plenty of reasons to consider them the result of poor engineering. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
In message [EMAIL PROTECTED], Lyndon Nerenberg writes : [Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. Maybe not for named because you're better off using the -t option. -- Cheers, Phone: 250-387-8437 Cy SchubertFax: 250-387-5766 Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED] Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Norton AntiVirus .
Recipient of the infected attachment: Ðûáèòâà Þëèÿ Âàñèëüåâíà\Âõîäÿùèå Subject of the message: Entertainment Group. One or more attachments were deleted Attachment height.exe was Deleted for the following reasons: Virus W32.Klez.H@mm was found. application/ms-tnef
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
Jos Backus writes: On Tue, May 28, 2002 at 01:36:00AM +0400, .@babolo.ru wrote: I have a lot of troubles with djb's tools in jail environment: they are unreliable. Huh? What is the problem? While the license causes plenty of problems I have yet to see the programs themselves cause any. Now they may not be a natural fit to what you are trying to do in this case but that doesn't invalidate the idea of a service control manager in general - only perhaps the daemontools implementation for your particular application. There are usual retrieval errors in jail+nullfs on startup I never see without jail+nullfs. May be it is the reason for daemontools not to work reliable when nonexpected errors occur - but I am not shure because a lack of time. Are you sure that http://www.io.com/~manoj/file/mktool-0.0.7.tar.gz (are you mean this one?) is better? It's hackable, which compared to daemontools is a big plus. And the author has said he is willing to add some more improvements and documentation. And it is simple. And not terrible disturb usual agreements. Good candidate for ports? as first step to your aim. I do not find docs or mans and am not sure that it is worth-while to dig in thist code instead of simple shell scripts (as in ports/38593 - that is my way to service control manager) Re: docs, see above. If there's sufficient interest I can prod the author or write some myself. Begin with port. I am interested in particular. For my hundreds jailed services The problem with all these homegrown solutions is that they are not portable jails not portable now. But it is most reliable way now. and lack the necessary features to be of general use, among others. Yes. I think first there needs to be consensus that having some sort of service control manager in the base OS is a good idea. Then we can look into possible candidates. Given the long tradition that pidfiles have in UNIX this is probably an uphill battle, even though I think there are plenty of reasons to consider them the result of poor engineering. The way: - make a port of service control manager(s) which writes down own pid as usual but handles controled processes himself - give a control step by step (service by service) - may be at FreeBSD 6..8 time it will be accepted in base -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ruby ports and PREFIX
So, what I'm doing here is experimenting with encap, a nifty little
package standard where the idea is that you install your software with
PREFIX set to /usr/local/encap/pkgname-version, and the package manager,
epkg, will look through that dir and symlink files from that hierarchy
in to /usr/local for you. It makes stuff like identifying the source of
a file, or rolling back to an earlier version of a software package,
downright trivial,
Of course, in terms of FreeBSD, I like to use ports to build packages,
so I've patched up bsd.port.mk to re-define PREFIX for intallations, and
run the package manager after install completes, etc. Most ports work
really well, assuming they honor PREFIX.
Which, ruby add-ons do not seem to do. For example, optparse:
do-install:
${MKDIR} ${RUBY_SITELIBDIR}/${PORTNAME}
${INSTALL_DATA} ${WRKSRC}/optparse.rb ${RUBY_SITELIBDIR}/
${INSTALL_DATA} ${WRKSRC}/optparse/*.rb ${RUBY_SITELIBDIR}/${PORTNAME}/
What the heck is that? On my test system, the RUBY_SITELIBDIR is
defined by interrogating RUBY, and the result is
/usr/local/encap/ruby-1.6.7.2002.05.02p/lib/ruby/site_ruby/1.6 ... what
I REALLY want is for the Port to install files based on PREFIX,
/usr/local/encap/ruby-optparse-0.8.6, and then I will link them in to
the proper ruby site directories which contain files in /usr/local
symlinked to their appropriate source packages.
A few questions:
1) Shouldn't the ruby add-on ports honor PREFIX?
2) To that end, is there a good way to define RUBY_SITELIBDIR and
friends in bsd.ruby.mk to honor PREFIX?
3) Once I symlink new files in to the ruby file hierarchy, so I have to
do any magic for Ruby to pick up to this fact? Is ruby going to do
anything troublesome like go looking in the encap directory it was built
for, instead of /usr/local?
Thanks,
-danny
--
http://dannyman.toldme.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Tue, May 28, 2002 at 03:42:31AM +0400, .@babolo.ru wrote: There are usual retrieval errors in jail+nullfs on startup I never see without jail+nullfs. May be it is the reason for daemontools not to work reliable when nonexpected errors occur - but I am not shure because a lack of time. Possibly, yes. And it is simple. And not terrible disturb usual agreements. Good candidate for ports? as first step to your aim. I would like to see this integrated into the base OS (a la inetd) to manage the daemons that are already part of the base OS and are currently not being managed. First, people have to agree that having some kind of generic service control manager is a good idea. After all, inetd was written so people would not have to duplicate its functionality every time. inetd could be run under this manager btw. If people think this is a bad idea (and consequently think that pidfiles are the right solution for this type of problem instead of fork()/wait()) I suppose I (or somebody else) could create a port but my main goal would have been lost at that point. I would really like some more discussion on the pros and cons of the basic idea. Begin with port. I am interested in particular. For my hundreds jailed services See above... The problem with all these homegrown solutions is that they are not portable jails not portable now. But it is most reliable way now. Yes, some OS constructs such as jails are non-portable but service monitoring should not be one of them. The SysV rc.d mechanism, while standardized, doesn't provide for any kind of monitoring facility. This software fills that gap, and it would be nice to see the *BSDs at least to incorporate this functionality. The way: - make a port of service control manager(s) which writes down own pid as usual but handles controled processes himself I will look into creating a port since you insist :-) - give a control step by step (service by service) I'm not sure what you mean by this? - may be at FreeBSD 6..8 time it will be accepted in base I will have given up long before if it looks like it is going to take that long to get such basic functionality into FreeBSD. Thanks for your feedback. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ruby ports and PREFIX
So, what I'm doing here is experimenting with encap, a nifty little
package standard where the idea is that you install your software with
PREFIX set to /usr/local/encap/pkgname-version, and the package manager,
epkg, will look through that dir and symlink files from that hierarchy
in to /usr/local for you. It makes stuff like identifying the source of
a file, or rolling back to an earlier version of a software package,
downright trivial,
Of course, in terms of FreeBSD, I like to use ports to build packages,
so I've patched up bsd.port.mk to re-define PREFIX for intallations, and
run the package manager after install completes, etc. Most ports work
really well, assuming they honor PREFIX.
Which, ruby add-ons do not seem to do. For example, optparse:
do-install:
${MKDIR} ${RUBY_SITELIBDIR}/${PORTNAME}
${INSTALL_DATA} ${WRKSRC}/optparse.rb ${RUBY_SITELIBDIR}/
${INSTALL_DATA} ${WRKSRC}/optparse/*.rb
${RUBY_SITELIBDIR}/${PORTNAME}/
What the heck is that? On my test system, the RUBY_SITELIBDIR is
defined by interrogating RUBY, and the result is
/usr/local/encap/ruby-1.6.7.2002.05.02p/lib/ruby/site_ruby/1.6 ... what
I REALLY want is for the Port to install files based on PREFIX,
/usr/local/encap/ruby-optparse-0.8.6, and then I will link them in to
the proper ruby site directories which contain files in /usr/local
symlinked to their appropriate source packages.
A few questions:
1) Shouldn't the ruby add-on ports honor PREFIX?
But they do! When you install Ruby, it will install into ${PREFIX}. By
interrogating Ruby to get the RUBY_SITELIBDIR, you'll get the proper site
library directory, which is most definitely under ruby's install directory,
which is under the ${PREFIX} that was specified at compile-time.
2) To that end, is there a good way to define RUBY_SITELIBDIR and
friends in bsd.ruby.mk to honor PREFIX?
See above.
3) Once I symlink new files in to the ruby file hierarchy, so I have to
do any magic for Ruby to pick up to this fact? Is ruby going to do
anything troublesome like go looking in the encap directory it was built
for, instead of /usr/local?
As long as the files can be found (physically or via symlinks) via the
RUBY_SITELIBDIR that ruby think it's using, you shouldn't have any problems.
IIRC, this situation is one of the reasons why Perl is coming out of the
base system in -CURRENT right now, in order to make all things Perl
PREFIX-clean.
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Mon, 2002-05-27 at 13:38, Gregory Neil Shapiro wrote: pjklist Funny thing about that, I actually created a /var/run/named directory pjklist for just the purpose of running named in a 'sandbox', chowned the pjklist directory bind:bind, and because I forgot to set the pid file path in pjklist named.conf, I see that it seems to write named.pid (owned by pjklist bind:bind) into /var/run without a problem. For named, the initial creation isn't the problem, it's the reloads and restarts: # ndc reload Reload initiated. # tail -2 /var/log/messages May 27 12:36:35 horsey named[142]: couldn't create pid file '/var/run/named.pid' May 27 12:36:35 horsey named[142]: Ready to answer queries. named(8) starts up as root, but demotes itself and chroots to the sandbox immediately after reading the command line. I assume it creates the pid file as soon as it starts up, before it processes its arguments. Using ndc isn't a problem if you use the -c option to point it to the correct socket. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
how to automagically restart net/pptpclient?
I have installed net/pptpclient (1.0.3). About 5 times a week, it dies and must be restarted. Does anyone have a script which checks and restarts it if it has died? FWIW: here's my ppp.conf. From what I can tell, the redial does nothing. And from what I know, the alias command is deprecated. Guess I should be using -nat. PONTEOTTAWA: set authname myname set authkey mypassword set timeout 0 set ifaddr 0 0 set redial 15 0 add 10.0.1.0/24 HISADDR alias enable yes And here is how it dies: May 21 20:55:43 ns1 ppp[74801]: Phase: deflink: lcp - open May 21 20:55:43 ns1 ppp[74801]: Phase: bundle: Network May 23 16:41:59 ns1 ppp[74801]: Phase: Signal 15, terminate. May 23 16:41:59 ns1 ppp[74801]: Phase: Signal 15, terminate. May 23 16:41:59 ns1 ppp[74801]: Phase: deflink: read (0): Got zero bytes May 23 16:41:59 ns1 ppp[74801]: Phase: deflink: open - lcp May 23 16:41:59 ns1 ppp[74801]: Phase: bundle: Terminate May 23 16:41:59 ns1 ppp[74801]: Phase: deflink: Disconnected! May 23 16:41:59 ns1 ppp[74801]: Phase: deflink: Connect time: 157578 secs: 5756166 octets in, 123806252 octets out May 23 16:41:59 ns1 ppp[74801]: Phase: deflink: : 54244 packets in, 88738 packets out May 23 16:41:59 ns1 ppp[74801]: Phase: total 822 bytes/sec, peak 63761 bytes/sec on Thu May 23 16:41:59 2002 May 23 16:41:59 ns1 ppp[74801]: Phase: deflink: lcp - closed May 23 16:41:59 ns1 ppp[74801]: Phase: bundle: Dead May 23 16:41:59 ns1 ppp[74801]: Phase: PPP Terminated (normal). -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ - practical examples To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to automagically restart net/pptpclient?
On Tue, May 28, 2002 at 12:57:52AM -0400, Dan Langille wrote: I have installed net/pptpclient (1.0.3). About 5 times a week, it dies and must be restarted. Does anyone have a script which checks and restarts it if it has died? What perfect timing. Please see my responses to the ``non-root /var/run files'' thread on this list. Another case which shows we need some kind of service control manager. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
