Re: maximum process limit

2005-11-30 Thread David Landgren

Tomas Palfi wrote:

To all,

I am running squid-2.5 STABLE10 on 5.4-RELEASE FreeBSD in production,
and I am trying to increase the maximum process size to be 2GB. I have
found a few references, however, they are all related to older releases
(FreeBSD 3) of FreeBSD.  As this server is already in production, I just
want to make sure that I am doing the right thing and the 2GB mem size
is being supported on the above version.

Can I have an option in the kernel 


option  MAXDSIZE=\(2048*1024*1024\)


Don't know that you need to backslash the parens there.


will this option alone change the default maximum process size? Or do I
have to edit the login.conf file to override the details as well as the
kernel changes?


No, recompiling (and installing) the kernel is all you need to do.

David
--
It's overkill of course, but you can never have too much overkill.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Very large directory

2005-01-20 Thread David Landgren
Peter Jeremy wrote:
On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote:
They've been running for a little while now - and recently we've noticed a
lot of disk space disappearing.  Shortly after that, a simple du into our
/var/spool returned a not so nice error:
du: fts_read: Cannot allocate memory
No matter what command I run on that directory, I just don't seem to have
enough available resources  to show the files let alone delete them (echo *,
ls, find, rm -rf, etc.)

I suspect you will need to write something that uses dirent(3) to scan
the offending directory and delete (or whatever) the files one by one.
Skeleton code (in perl) would look like:
chdir $some_dir or die Can't cd $some_dir: $!;
opendir(DIR, .) or die Can't opendir: $!;
while (my $file = readdir(DIR)) {
next if ($file eq '.' || $file eq '..');
next if (this_file_is_still_needed($file));
unlink $file or warn Unable to delete $file: $!;
}
closedir DIR;
similarly,
opendir(DIR, $some_dir ) or die Can't open dir $some_dir: $!;
while ( defined(my $file = readdir(DIR))) {
print $file\n unless ($file eq '.' || $file eq '..');
}
closedir(DIR);
...will print the files one per line, which can be piped to more or 
redirected to another file. This will let you get a feel for the names 
of the files in the directory. It could then be cleaned up with various 
pipelines like egrep 'foo|bar|rat' | xargs rm

Note: you want to wrap the my $file = readdir(DIR) in a defined(), 
otherwise your loop will exit early if you come across a file named 0 
(zero).

David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Very large directory

2005-01-20 Thread David Landgren
Oliver Fromme wrote:
Peter Jeremy [EMAIL PROTECTED] wrote:
  On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote:
   They've been running for a little while now - and recently we've noticed a
   lot of disk space disappearing.  Shortly after that, a simple du into our
   /var/spool returned a not so nice error:
   
 du: fts_read: Cannot allocate memory
   
   No matter what command I run on that directory, I just don't seem to have
   enough available resources  to show the files let alone delete them (echo *,
   ls, find, rm -rf, etc.)
  
  I suspect you will need to write something that uses dirent(3) to scan
  the offending directory and delete (or whatever) the files one by one.
  
  Skeleton code (in perl) would look like:
  [...]

I would suggest trying this simple hack:
cd /var/spool/directory ; cat . | strings | xargs rm -f
It's a dirty hack, but might work, if the file names in
that directory aren't too strange (no spaces etc.).
why suggest a dirty hack that might not work, when the proposed Perl 
script would have worked perfectly?

David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Building your own FreeBSD installation CD-ROM

2005-01-18 Thread David Landgren
List,
(I asked this question last week on -questions but received zero 
answers. My apologies if this is the second time you are seeing this 
question).

how does one go about creating a FreeBSD install CD-ROM? I'd like to be 
able to build my own CD-ROM with as much as possible of the install 
process done automatically. For instance, what parts of FreeBSD to 
install: X or not, games or not, etc. etc. And which ports to install 
straight away. I could also set up cfengine so that as soon as the 
machine came to life it could go and connect to my cfengine repository 
and download all the latest configurations to move into operational status.

E.g., I'd like to just have to specify the partition layout, the name 
and IP of the machine, and its role(s): (web, dns, squid, mta, samba...)

This would make rebuilding so much faster if a machine was 
catastrophically trashed. I could just hand someone a CD and a sheet of 
paper and they should be able to work it out by themselves without 
knowing too much about the ins and outs of FreeBSD. I could go on 
holidays without being stressed out.

Thanks for any pointers to documentation on the subject, I'm sure people 
have done this before, but I can't coax the results out from my web 
searches.

Thanks,
David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: garbled top display

2003-06-26 Thread David Landgren
Eric J. Chet wrote:
[...]
Just a sanity check.  I'm seeing a garbled display with top.  I
rebuild kernel and world a couple times, I even rm -rf /usr/include to
make sure I was up to date.  Anybody else seeing this?
Define garbled.

Thanks,
David


Sure 

Script started on Mon Jun 23 10:39:06 2003
bash-2.05a$ top
last pid:  3359;  load averages:  0.06,  0.02,  0.00 up 
1+13:20:4210:39:09
10 processes:  1 running
CPU states: % user, % nice, % system, % interrupt, % idle
Mem: 16M Active, 55M Inact, 26M Wired, 8748K Cache, 22M Buf, 15M Free
Swap: 256M Total, 52K Used, 256M Free
  PID USERNAME PRI NICE  SIZERES STATETIME   WCPUCPU COMMAND
1 '++*00'* -22 -52 0K 0K ? -128???  0.15%  0.15% 
968972 root -22 -52  3083M 0K ?6???  0.00%  0.05% 
[... etc etc ...]

wow.

I've seen garbled top displays before, like the RES going -ve or things 
like that. But never anything like this. I am reminded of the scene in 
Poltergeist, where the couple get a paranormal expert into the house to 
take a look, and he natters on about how he saw a toy car roll across a 
room over the space of six hours... and then they open the door...

It looks to me like your structs are out of whack, and so when top comes 
along to read an element of a struct, it's using the wrong offset from 
base, and hence printf (or whatever) renders garbage. I.e., as if 
different headers are used in compiling the kernel and the rest.

Does ps give reasonable output? Are you sure you really cleaned out 
/usr/src before recompiling? Has the compiler been upgraded recently?

David

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]