On 09/13/2016 04:06 AM, Sam Varshavchik wrote: > Rick Stevens writes: > >> On 09/10/2016 08:09 AM, Sam Varshavchik wrote: >> > Sam Varshavchik writes: >> > >> >> Tom Horsley writes: >> >> >> >>> On Sat, 10 Sep 2016 10:20:57 -0400 >> >>> Sam Varshavchik wrote: >> >>> >> >>> > All-righty, this must be something about this particular >> named-chroot >> >>> > configuration… >> >>> >> >>> In the "check the dumb stuff first" category, might want to >> >>> run memtest and check the SMART info on the disk. Always a >> >>> chance the code got corrupted somehow and isn't running the >> >>> instructions intended to run :-). >> >> >> >> I copied the chroot to another server that I can play with. On that >> >> one, named-chroot also segfaults at startup in the same way, so it >> >> looks like I have a weekend project… >> > >> > I have this "options" directive in place for decades: >> > >> > datasize 20M; >> > >> > Commenting it out allows named to start up. I'll try it on my main >> > server, the next time I reboot it. Something about 4.7.2 that makes >> > named blow up, with this directive in place. >> >> Uhm, since that limits the size of memory that named can use, have you >> tried increasing it? I agree that a new kernel shouldn't cause it to >> puke unless there's something wrong with the way RAM is being allocated >> in the kernel (or the limit is actually being enforced in the new kernel >> and it wasn't in the older ones). >> >> It'd be interesting if you had a top report of the memory usage of >> named under the old kernel and the new kernel (with the directive >> disabled), just to see what the memory footprint differences are. Might >> point toward something interesting. > > Yeah, something's definitely going on. > > Freshly restarted named: > > 4.7.2: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 29156 named 20 0 702528 83324 6360 S 12.5 2.1 0:00.23 named > > 4.6.7: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 10208 named 20 0 407084 81908 6828 S 12.5 1.0 0:00.13 named > > With 4.7.2, it's virtual space is nearly twice as much, also RES is just > slightly bigger. Yeah, the virtual usage is significantly bigger, the resident part slightly bigger and the shared segment is actually smaller. Weird. I wonder if it has something to do with the way chroots work in 4.7.x? Is it possible for you to launch it again in both kernels but NOT in a chroot? That might allow you to bugzilla something a bit more focused, but there's SOMETHING weird there. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - I will go to my happy place. I WOULD go to my happy place.... - - if I knew where the @$>&$@#* it is! - ---------------------------------------------------------------------- -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
