Re: How to keep java code running after logout
On Mon, Jul 29, 2002 at 11:16:00PM -0700, Vijay Patel wrote: Hi friends, I have installed FreeBSD 4.5 on my machine. I am also having 2 other machines running on linux. We have developed a code in java which we need to run in background for 24 hrs. In linux we use... java Code1 Can you try 'java Code1 /some/log ' and see what sort of a stack trace you get when the process dies? If you're using a bourne style shell then that would be 'java Code1 /some/log 21 '. Its hard to tell what is going on without any sort of error message, there is no inbuilt reason the process should just die. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: squid and datasize kernel problems
On Mon, Jul 29, 2002 at 08:54:40PM -0700, freebsd-hackers-digest wrote: Date: Mon, 29 Jul 2002 15:51:08 +0200 From: Anders Nordby [EMAIL PROTECTED] Subject: Re: squid and datasize kernel problems (was: openoffice stack and datasize kernel problems) On Sat, Jun 08, 2002 at 10:40:54AM -0700, Matthew Dillon wrote: options MAXDSIZ=(1024*1024*1024) options MAXSSIZ=(256*1024*1024) But it doesn't make much sense. A 64 megabyte stack ought to be plenty, as should the default 512MB data size. It should be noted that mmap() uses whatever VM space remains after MAXDSIZ and MAXSSIZ have been reserved, so increasing MAXDSIZ reduces the amount of VM available to mmap(). Still, a 1 GB MAXDSIZ should not result in system utilities / servers running out of mmap() space! Userland has 3G of VM space to play with. I'm running into some similar issues when trying to make Squid eat as much as possible of the 4 GB memory I have installed in a Compaq ProLiant DL 380 G2. At first, Squid seems to die and restart when trying to allocate memory above 512 MB. By tuning MAXDSIZ, I have made it use up to around 2 GB. If I set MAXDSIZ (I now do it in loader.conf with kern.maxdsiz) above around 2950 MB, init starts failing upon boot: init in malloc(): error mmap(2) failed, check limits init in malloc(): warning: recursive call Does anyone have any clues on how to overcome this? I'll be trying out the the dlmalloc library that is distributed with Squid, but I suppose I do need a 4 GB maximum data size to be able to make Squid actually use 4 GB. Is this possible, or am I being totally foolish? Any hint very appreciated. :-) I just this weekend got done upgrading a 3.5-current box to RELENG-4.6.1, to run Squid on. Also upgraded to the latest Squid from /usr/ports, a big step up from the old version we were running. One of the reasons I originally picked FreeBSD for the Squid server, based on advice from the gurus on the Squid users list is because the unified memory management in FreeBSD makes *all* unallocated RAM available for disk buffering, so that you benefit from the full amount of RAM even if it's not allocated to the Squid process. As of a couple years ago, the best advice on Squid was to *not* try to make it buffer everything in the squid process's RAM, but let it do its two-tiered RAM/disk caching with a moderate amount of RAM (e.g. 128MB) and let the OS decide what disk content to buffer with the remainder. I doubt that's changed. Squid performance is also claimed to benefit substantially (up to 4x throughput) from choosing the diskd storage type. However, for this to work you'll need to rebuild your kernel to expand the Sys V message queues and Sys V shared memory allocation to some expanded voodoo values. See http://www.squid-cache.org/Doc/FAQ/FAQ-22.html#ss22.6 and http://www.squid-cache.org/Doc/FAQ/FAQ-22.html#ss22.7 I did this yesterday afternoon and it's looking good so far under light usage. Also enable softupdates, and mount your cache drives with noatime to help performance. For more help, try www.squid-cache.org and ask on the squid-users mailing list at: http://www.squid-cache.org/mailing-lists.html which used to have plenty of Squid experts and Squid-on-FreeBSD experts; I'm far from either. -- Clifton -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] What do we need to make our world come alive? What does it take to make us sing? While we're waiting for the next one to arrive... - Sisters of Mercy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
How to crash FreeBSD for educational purposes?
Hi there! I am currently playing around with analyzing crash dumps on FreeBSD. Are there any ways to crash the system to get a dump? For example, on Solaris it's easy to change the Inode-Number of the root-filesystem, so it crashes the next time it tries to access / - but can i do the same on FBSD? Or can i force the system to write the current memory content to the dump-device without crashing the whole system? Thanks, Egon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to crash FreeBSD for educational purposes?
On Tue, Jul 30, 2002 at 01:15:36PM +0200, Rath, Egon wrote: Or can i force the system to write the current memory content to the dump-device without crashing the whole system? If you compile DDB into the kernel, you can break to the debugger (with ctrl-alt-esc) and then type panic. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to crash FreeBSD for educational purposes?
In message EB808F8B7354D311AE3200508B319CC7CE7F24@OOELKHCO12, Rath, Egon wrote: Hi there! I am currently playing around with analyzing crash dumps on FreeBSD. Are there any ways to crash the system to get a dump? For example, Check ddb(4). Use panic subcommand. Or can i force the system to write the current memory content to the dump-device without crashing the whole system? No, as far as I know. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to keep java code running after logout
I have installed FreeBSD 4.5 on my machine. I am also having 2 other machines running on linux. We have developed a code in java which we need to run in background for 24 hrs. In linux we use... java Code1 command to run our code in background. After starting this command we just logout from that terminal window. We have seen that on linux machine our code works fine in background. IIRC this depends on the shell. But IMHO it is normal behaviour that the child (your program) gets killed if the parent (the shell) got killed. You should read nohup(1). nohup is your friend. :-) But for 24x7 you could also use init(8). Under SysV you could write your program in /etc/inittab and under *BSD in /etc/ttys. So the program gets automatically started by init _and_ restarted if it crashes. msg36006/pgp0.pgp Description: PGP signature
Re: How to keep java code running after logout
Vijay Patel [EMAIL PROTECTED] 69 lines of wisdom included: Hi friends, I have installed FreeBSD 4.5 on my machine. I am also having 2 other machines running on linux. We have developed a code in java which we need to run in background for 24 hrs. In linux we use... java Code1 This is fine, however this sets the process into the background, however the process still has a parent process. It is natural behaviour, that if a parent process dies, so do the children. In innatural situations, this is how ``zombie'' or ``defunct'' processes appear. In (my favourite shell) zsh, putting the program into the background with ``|'' can work. e.g. $ java Code1 | $ jobs $ as opposed to $ java Code1 $ jobs [1] + runningjava Test $ In the second situation however, you can ``disown'' the process, which will leave the process in the same state as the first. See zshbuiltins(1). snip bash-2.05a$ ps PID TT STAT TIME COMMAND 1087 p0- I 0:00.20 /usr/local/jdk1.3.1/bin/i386/green_threads/java Code1 1105 p0 Ss 0:00.01 -bash (bash) 1106 p0 R+ 0:00.00 ps Your main problem is that you're trying to run a ``daemon'' process with Java on a FreeBSD system. As you can see, your Java program is attacked to a TTY, which is a bad idea for a ``daemon''. I have come across a wrapper for this, which is located here: http://www2.dystance.net:8080/ping/djinn/ I can't testify how good or bad this is, but it's something to consider at least. It is showing that code is working right now. But after 2-3 hours code automatically gets killed. I am having good provision for keeping all error log iff my code exists with an error. But here i am sure that it is getting killed - so i am not getting any error log. If your code is getting killed after a few hours, I would have a look at logging information, and where abouts your code is actually falling over. Also have a look at the ``nohup(1)'' command. This basically means that when the shell sends the JVM a signal to terminate (when you type ``exit'', this is what happens) it ignores it and keeps running. $ nohup Java Code1 The above is probably your best bet. I am not that familiar with Java debugging utilities for UNIX, especially FreeBSD. However your problem seems to be the method for spawning your program in the background, which I think you need to rethink. -- Philip Reynolds | Technical Director [EMAIL PROTECTED] | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Accessing memory below 1 MB
Hello, I'm writing some graphics code (just for fun) and I need legal access to the memory addresses below 1 mb. The thing is, I know how to access those addresses (open /dev/mem, mmap, and that's it), but I'd like to be able to alloc some pages so that my accesses are correct and don't make the kernel panic... Does anyone know how I could do that? Thank you in advance. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
select()/poll() i kernel.
Hi, I was wondering if there is a select()/poll() for use in kernel by kernel threads? I've been looking around in sys/kern/ but didn't find anything. I'm currently developing under 4.6. Please CC me since I'm not a member of the list. Kind regards, Daniel Lundqvist To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Accessing memory below 1 MB
[EMAIL PROTECTED] writes:
I'm writing some graphics code (just for fun) and I need legal access to
the memory addresses below 1 mb.
You can't access the framebuffer directly in FreeBSD like you can in
DOS. Take a look at libvgl ('man vgl').
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
system panic
Hi, I read the article System Panics, parts 1 and 2 and send you my system panic :((( When I transfer the big file (about 6Mb) by network, my freebsd crashed :((( And my samba version is: samba-2.2.5_3 I don't know how to correct this, I hope that you help me. Thanks in advanced, Albino caracu# uname -a FreeBSD caracu.nacad.ufrj.br 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Tue Jul 30 16:15:42 BRT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/CARACU i386 caracu# gdb -k kernel.1 vmcore.1 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... (no debugging symbols found)... SMP 2 cpus IdlePTD at phsyical address 0x00418000 initial pcb at physical address 0x003641c0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = fault virtual address = 0x45c7 fault code = supervisor write, page not present instruction pointer = 0x8:0xc019a2e4 stack pointer = 0x10:0xd87aee08 frame pointer = 0x10:0xd87aee44 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 204 (smbd) interrupt mask = none - SMP: XXX trap number = 12 panic: page fault mp_lock = 0002; cpuid = 0; lapic.id = boot() called on cpu#0 syncing disks... 24 2 done Uptime: 5m42s dumping to dev #da/0x20001, offset 2097280 dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc017b10e in dumpsys () (kgdb) where #0 0xc017b10e in dumpsys () #1 0xc017af1e in boot () #2 0xc017b359 in panic () #3 0xc02cb136 in trap_fatal () #4 0xc02cad91 in trap_pfault () #5 0xc02ca8d3 in trap () #6 0xc019a2e4 in soreceive () #7 0xc018dcb9 in soo_read () #8 0xc018a382 in dofileread () #9 0xc018a23f in read () #10 0xc02cb472 in syscall2 () #11 0xc02b832b in Xint0x80_syscall () #12 0x813dc1b in ?? () #13 0x813df3b in ?? () #14 0x813e09c in ?? () #15 0x80a0700 in ?? () #16 0x80a18db in ?? () #17 0x8068b85 in ?? () #18 0x80675c5 in ?? () (kgdb) -- Albino A. Aveleda [EMAIL PROTECTED] Network Manager +55 21 2562-8080 NACAD-COPPE/UFRJhttp://www.nacad.ufrj.br Federal University of Rio de Janeiro (UFRJ) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: system panic
if you compiled your kernel with -g
(config -g MYKERNEL)
then you should use
gdb -k {compiledir}/kernel.debug vmcore.1
gdb set directory {compiledir}
your kernel trace is somewhat useful but would be more useful
if dumped out with the debug kernel instead...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: select()/poll() i kernel.
Daniel Lundqvist wrote: I was wondering if there is a select()/poll() for use in kernel by kernel threads? I've been looking around in sys/kern/ but didn't find anything. I'm currently developing under 4.6. Please CC me since I'm not a member of the list. 4.6 does not have kernel threads; it has kernel processes (kproc's), however, which are just standard processes which have been assumed to have entered the kernel. As such, they are suitable for use as a context for blocking operations (you can only sleep things that have the ability to have scheduler queue entries, and therefore be awakened at a later time). There is no explicit support for a select call; most operations on file descriptors assume a process context in user space from which parameters can be copied, and results copied out. Rather than correcting the FreeBSD model to internally add a space identifier parameter to the body of the call, and make the system calls call that, instead of being directly wired in, you have two real options: 1) Use The mmap trick to obtain memory in the user space portion of the kproc address space, so that when uiomove and/or copyin/copyout operate, they have someplace to get or put the data. 2) Write the moral equivalent of the select(2) (or poll(2)) code that can be called from kernel space, and call it from your kproc. Note that either of these will *only* work from a kproc, where the current process identfier is the kproc. So you can't use them in fault handlers or interrupt handlers, if that's what yu are thinking. Really, FreeBSD needs a better abstraction of the file I/O and other operations in kernel space, so that doing this type of work is much easier. On the other hand... it's likely that your expectations of how a kproc can be used as if it were a kernel thread are unreasonable, so maybe it's just as well that there is not explicit support for this kind of thing, like there is in Linux, AIX, and Solaris. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Accessing memory below 1 MB
[EMAIL PROTECTED] wrote: I'm writing some graphics code (just for fun) and I need legal access to the memory addresses below 1 mb. The thing is, I know how to access those addresses (open /dev/mem, mmap, and that's it), but I'd like to be able to alloc some pages so that my accesses are correct and don't make the kernel panic... Does anyone know how I could do that? Open the device driver for the device for which you need raw access to the memory, and mmap(2) the memory into your process address space. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
