=== daxxar [i=daxxar@daxxar.com] has joined #ubuntu-server [12:19] not as many ppl - which is also nice [12:19] I see your point. :-) [12:23] you should repeat your question in here - they seem to know what they are talking about - although quiet [12:24] Okay [12:25] What could cause Samba to spontaneously reboot my system? I'm running an Ubuntu Server w/ Dapper RC. [12:25] E.g. entering a subdirectory of my share just *reboots* the whole system. My syslog outputs this at the reboot [12:26] May 28 00:12:40 datamania mountd[3869] : authenticated mount request from 192.168.0.14:937 for /storage/movies (/storage) [12:26] May 28 00:15:45 datamania syslogd 1.4.1#17ubuntu7: restart. [12:26] /storage is an LVM mount, it's also exported as NFS. [12:28] And it's also an automount? [12:28] samba's a red herring here, I think. Samba would never cause your system to reboot. [12:28] Yeah, it's an automount. [12:28] mountd could be tickling a kernel bug, though. [12:28] Hm, okay [12:31] Hmm. Yeah, I think you're right. [12:31] I wasn't (previously) able to reproduce this in anything but the samba sessions. [12:31] But I attempted a few IO operations via FTP, rebooted it there too now. [12:31] Could it be my FS setup? [12:31] It's setup for 'largefile' (1mb/inode) [12:32] And data written right before the reboot is gone. (Directories created, files created) [12:33] Just to have mentioned it, the memory passed a single full pass of memtest86. I didn't test it beyond that. [12:33] Okay, it's just not that FS. Could it be my network-card? [12:34] I don't use automounts at all (haven't for years), so not sure how that could be affecting things. [12:34] Is it fine if you access non-mountd directories? [12:34] (Set up a temporary samba share on /tmp, for instance) [12:34] No, accessing /home via FTP crashes it too. [12:34] :o [12:34] Uhm, automounts, is that the same as /etc/fstab-entries without 'noauto', or? :o [12:34] (I assumed so when I answered) [12:35] Well, no. See the "mountd" in your syslog? That's not a samba thing. [12:35] I assumed you were using an automounter of some sort that was mounting filesystems on demand. [12:36] Oh, nope. [12:36] Or, shouldn't be. [12:37] Hrrm. :| [12:37] I guess this is HW-related. [12:37] Oh, wait. mountd is the NFS automounter. [12:37] Silly me. [12:37] You have NFS exports on that machine as well? [12:37] "dd if=/dev/zero of=test-big bs=1024K count=500" crashed it after ~300MB. [12:37] Yes. [12:38] Yeah, okay. The above syslog snippet was when connecting with NFS, not with samba. [12:38] And now I'm less confused. [12:38] Ah, okay. :-) [12:38] Are you using nfs-user-server or nfs-kernel-server? [12:38] kernel-server [12:38] Kay, that should be the more stable of the two. [12:38] Anyhow, you already confirmed that connecting some other way (like FTP) also crashed the box, yeah? [12:38] Yep, and a dd via ssh. [12:39] Oh, you just said dd crashed. I need to wake up a bit. :) [12:39] So I Gess it's hw?: ( [12:39] Fair chance it's hardware, then. [12:39] dd doesn't "just crash" Ever. [12:39] It's far too simple to screw up. [12:39] dd didn't *crash*, it made the box reboot. :-) [12:39] Well, same thing. [12:40] I would only expect dd to bugger the box if either A) you have hardware problems, or B) the kernel REALLY hates you. [12:40] Are you using an Ubuntu kernel, or hand-rolled? [12:40] Ubuntu [12:40] Our kernels definitely shouldn't explode on filesystem access. :) [12:40] (This isn't reiserfs, is it?) [12:42] Nope, ext3. [12:42] Hm. [12:42] Kay, then I'd look at hardware for sure. [12:42] Shutting down the nfs-kernel-server and the smb-server, and running a: [12:42] daxxar@datamania:~$ i=1; while /bin/true; do echo "Pass: $i" && dd if=/dev/zero of=test-big bs=1024K count=50 && rm -f test-big && let i++; done [12:42] Pass: 1 [12:42] I'll see if I manage to crash it now. === Mysta [n=Mysta@c-24-98-118-36.hsd1.ga.comcast.net] has joined #ubuntu-server [12:44] Pass: 90. *me restarts it with count=100* [12:46] Hmm. Now a single process hung, the rm -f test-big at pass #60. strace -p shows nothing on it. [12:46] Can't kill it either. [12:46] maybe you should try running 'badblocks' to see if there's some damage on the HD [12:46] Hrm. What piece of HW would you suspect is the most likely factor to be the cause? [12:46] The HD was unwrapped ~6 hours ago. :-P [12:47] btw, hi ^^ [12:47] SATA or SCSI ? [12:47] IDE [12:47] Hi. :-) [12:47] Hmm. The console shows some huge amount of activity atm. [12:47] Too fast to read. [12:48] I think you should try anyway to eliminate that possibility [12:48] http://www.rafb.net/paste/results/z61UNQ99.html [12:49] x ~ [12:49] sometimes brand new HDs come faulty from factory (very very rare, but happens) [12:49] daxxar@datamania:~$ sudo init 6 [12:49] Segmentation fault [12:49] ... [12:49] :-P [12:50] wow [12:50] But that's after the syslogmessages I pasted. [12:50] It *did* say "a reboot is needed". [12:51] "GRUB loading, please wait..." "Error 17" [12:51] hey guys, I wanted to install vmware server beta and wanted to know if the server distro or the regular distro better suited me [12:52] daxxar: FS crashed? [12:55] Mysta: I think it doesn't matter as they are almost the same... but IIRC, vmware server comes with a gui, so it could be a better idea installing it on a regular (desktop) system [12:56] frinkillo, yep. Seems so. [12:56] Can't remount it via the rescue mode from the install CD. [12:56] Any way to run badblocks without a full reinstall? [12:56] Then you either have a bad disk, or something in the CPU->Cache->RAM pipeline is horribly corrupting data before it gets to the disk. [12:57] (Or the driver for your controller sucks... Which controller is it?) [12:57] yeah, from the rescue CD, try something like 'badblocks -v -s /dev/xxx' [12:57] The rescue-CD doesn't have badblocks, it seems. :| [12:57] ugh [12:57] http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=15 - That mobo [12:57] [12:57] Intel ICH2 Chipset Chipset [12:57] Onboard ATA controller. [12:58] Oh, that's very well supported. [12:58] Mkay. You saw the error i pasted on rafb.net? [12:58] So, you're looking at a bad disk, or corruption on the way to the disk (bad CPU/cache, bad RAM, or bad motherboard) [12:58] How many passes of memtest86 would be needed to rule out RAM-problems? I ran a full pass, no errors. [12:59] Yeah, that didn't tell me much. Bad paging request could be any of the above as well. [12:59] Okay. [01:00] Has that CPU ever been overclocked, by chance? [01:00] anyone/ [01:00] Mysta: If you want to use the GUI, go for a desktop install. [01:01] Mysta: If you want the server kernel on a desktop install, just "apt-get install linux-server" [01:02] infinity, underclocked. :o [01:02] (AFAIK) [01:02] It should be a 1.2GHz P3, but it's clocked at 1.0GHz [01:02] daxxar: And it's never been overclocked in the past? [01:03] thx guys [01:03] Not AFAIK. But this CPU was inherited from someone else. ;-) [01:03] daxxar: Only curious because this smells like "burnt cache", which is a common side-effect of overclocking. [01:03] (For some reason, I can't get the multiplier to 9 which it should be, only to 8) [01:03] daxxar: If that someone else was underclocking it to compensate for overclocking it in the past, that might say something. :) [01:03] Mkay. Doesn't memtest86 test cache too? [01:03] Not reliably, but it tries. [01:04] Okay. Should I use the Ubuntu Dapper Desktop to test the disk, or get the Seagate tool? [01:04] You can disable cache in the BIOS and try to reproduce the crashes, but it'll run REALLY SLOW without a cache. [01:04] Seagate's tool is more likely to find real problems on the physical disk. [01:05] badblocks will only find what's exposed to the ATAPI/IDE layer, which should be "nothing" on a modern disk, since the disk's firmware is supposed to be swapping our bad blocks on the fly. [01:05] Hm, okay. [01:05] (Not that this works as well in practice as it's meant to in theory) [01:06] hmm interesting [01:07] s/swapping our/swapping out/ [01:07] I make more sense with fewer typos. [01:09] It made sense before the regreplace too. ;) [01:11] SeaTools includes a RAM-test. :p [01:13] infinity: i was searching aptitude for that server kernel by searching for linux-server, and came up short, is that the correct name? [01:13] Ugh. 1 hour to run a full scan of the disk. :| [01:14] Mysta: Yeah. "linux-server" is probably in restricted, though. If you only have "main" enabled, "linux-image-server" should do. [01:14] k, thx [01:14] Mysta: If you're on breezy and not dapper, ignore everything I've said, there are no server-tuned kernels on breezy. [01:15] Thanks a lot for the help frinkillo, infinity, gpd, :-) [01:15] infinity: ok, thats why. lol. I just realized i ssh'd to my breezy instead of dapper [01:15] I'll let this disktest from Seagate run, see if it finds anything. [01:15] If not, I'll run memtest86 for a few hours. [01:16] :) [01:16] If not, I'll tear my hair out. :| [01:16] If nothing there, * [01:16] is there any documentation on what is different in this kernel compared to a regular one? [01:17] nvmd, i found something [01:17] https://wiki.ubuntu.com/ServerFaq [01:18] that helps too thx === Mysta [n=Mysta@c-24-98-118-36.hsd1.ga.comcast.net] has left #ubuntu-server [] === eimajenthat [n=jamie@cpe-70-123-133-94.austin.res.rr.com] has joined #ubuntu-server [02:34] the description says "development discussions," is there a general ubuntu-server channel? [02:35] Okay. [02:35] "Full test" completed, no errors. [02:35] So the problem is not controller / disk. *sighs* [02:36] the description says "development discussions," is there a general ubuntu-server channel? [02:36] I bet people actually could see what you said the first time. [02:46] infinity, do you think the error could be caused by a defective PSU? [02:47] infinity, it doesn't seem to be HD, controller or memory. Could be CPU or MB I guess. [02:47] (defective or not powerful enough. It should be 300W.) === eimajenthat [n=jamie@cpe-70-123-133-94.austin.res.rr.com] has left #ubuntu-server ["Konversation] === Zambezi [i=Hideit@dns-cache2.tixit.se] has joined #ubuntu-server [04:33] Is it possible to make Ubuntu-server (Breezy) with to modification, more secure? And how? I would like as high security as possible. Please PM or highlight me name so I won't miss an answer. === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-server === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-server === gpd [n=gpd@www.grahamdavies.net] has left #ubuntu-server [] === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-server === jackc [n=jack@84-72-164-170.dclient.hispeed.ch] has joined #ubuntu-server === jackc [n=jack@84-72-164-170.dclient.hispeed.ch] has left #ubuntu-server ["Leaving"] === phace [n=phace@85.158.38.58] has joined #ubuntu-server [12:14] well how can i get involved with the ubuntu server development ? === kermitX_ [n=kermit@unaffiliated/cxg] has joined #ubuntu-server === jackc [n=jack@84-72-164-170.dclient.hispeed.ch] has joined #ubuntu-server [02:29] Hm, how strange. [02:29] I ran a full pass on memtest86 before installation, no errors. Then, I ran two passes last night before I went to bed, no errors. [02:30] Today, I started a pass, and it found 3 errors before it had run for 5 minutes. [02:31] If it said it found it at address ~122MB, is it safe to assume there are errors on the memorychip in the first slot, since it's 256MB? [02:31] (The 'channel' field of the errors is blank) [02:48] It's not really save to assume anything, unless you know for sure how the memory controller is interleaving the RAM. [02:48] s/save/safe/ [02:49] Your best bet it to do repetitive memtest runs on the machine witch each stick installed individually. [02:49] Pain in the ass, but it's the only reliable way to find a single bad stick. [02:50] So I need to run how many passes on each stick? [02:50] Since this was found 5 minutes into the 4th actual pass. [02:50] = ~5 hours. [02:50] Eh, 4. === infinity shrugs. Your guess is as good as mine. [02:52] RAM errors come and go, depending on how well it decides to hold a charge from one moment to the next. [03:22] new default phpmyadmin theme sux.. no width contstraints. inputs on far left & submit on far right... === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-server === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-server === thefish [n=thefish@unaffiliated/thefish] has joined #ubuntu-server === jackc [n=jack@84-72-164-170.dclient.hispeed.ch] has joined #ubuntu-server === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-server === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-server === mloman [n=malo@81-224-36-188-no51.tbcn.telia.com] has joined #ubuntu-server === sto6ma9ch [n=sto6ma9c@max8-24.rtcol.com] has joined #ubuntu-server === lbm [n=lbm@0x555298ca.adsl.cybercity.dk] has joined #ubuntu-server === gilprice [n=gilprice@cpe-024-168-203-119.sc.res.rr.com] has joined #ubuntu-server === nictuku [n=yves@ubuntu/member/nictuku] has joined #ubuntu-server === mloman [n=malo@81-224-36-188-no51.tbcn.telia.com] has left #ubuntu-server [] === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-server