superloopy1

Thanks. So its really of no use to me at the moment, the standard eth0 will do the job just the same if i'm running only bridge dockers? I have already tried a post for advice on cpu stalls but as expected its not an issue for the majority of users so little response. I'm not complaining just looking at the system in different ways to try and understand just whats going onand yes, i've tries with syslog caps, again not much to report other than a log full of repeating cpu stall info. System is only running a handful of dockers. Maybe my next step will be to pin dockers to cores only, ignoring HT threads. Will cut available threads but might just work ..... system has enough cores, 32, to enable me to double up on core only.

By default BR0 comes as standard (ie ticked) .... can i disable this interface if i only have bridge enabled docker containers? Daft question ... maybe but i'm trying to troubleshoot a plague of cpu stalls which only happen (maybe obviously) when docker containers are active. rest of the time the system is idle.

Me too ... plagued by cpu stalls daily. Box becomes slowly unresponsive, syslog fills with garbage and ultimately requires hard reset. Just about had enough of it now and considering changing out all hardware, mobo, cpu, ram cos its becoming a real pita! Thereagain it can go for days not needing any attention as it used too but it seems any attempt to actually USE the machine triggers a reaction. Not a lot of good really just having it stand idle ... anyone with any ideas on how to troubleshoot this would be welcome to chip in ...

I'm having a few problems with lockups, mainly timeouts and stalls on my system and am trying to recreate/reformat cache drive with xfs instead of btrfs as btrfs figures a lot in the syslogs at the time of problems so i suspect that maybe the writes to the cached drive are causing timeout/stall issues. I've moved everything off the cache drive with the exception of the docker.cfg which is refusing to go (why?) anywhere. Am i safe to just delete this and then recreate/reinstall? If yes, then how? I've no idea why this file appears locked, dosker service/vm (none) have been disabled and system reloaded but still sitting on cache, other appdata DID move

seems like it ... i'm having thesame issues.

Thanks. That's what i thought, so its just a case of double checking that all ok ... a job in itself. Thanks for our help again.

Crossed posts, apologies. It says corrected which i guess is what's needed but presumably that means there was an underlying problem with the data and previous parity status. I'm looking to try and identify what's been affected if thats possible?

Here's the diagnostics .... tower-diagnostics-20220228-1714.zip

That's what it says and considering the correct errors box is checked then i'd say it's right, there's a pile of errors in the syslog, doesnt look like the full 168 cos it says ';stopped logging' at some point. Just wondering if there's any way, suing the sector info to identify what's been affected. I accept that its been corrected but i what way. Just digging up some old forum posts in anattempt to get my head around this.

Hi .... quick resume, server unresponsive and needed to be 'helped' to reboot following which unlcean shutdoen parity check kicked in. Finished with 168 errors, all corrected and showing in syslog but is this correupted data now? If so, any way to identify what's been affected?

Thanks. Will the share on the incomimg drive also be imported, its named differently on the other array so i'm guessing that it will be created and all incoming data will therefore need to be moved across to the resident share on the receiving array?? Or should i just do it ... after backing up of course!

Guys, a quick question. If I move a drive from be array to another will it be accessible and available to the other array without any further action? Is the existing share created when I add the drive or will it need to be set up in advance if adding the incoming drive? Just looking to consolidate two arrays into one to save on power costs, stupidly high here in the UK, and free up the parity disks and hardware. I've got a spare 24 bay server which will take the total drives currently spread across two arrays. Make sense, or not?

why is that? is it assumed they're from a bad batch?

I'm on 6.9.2 ... so a bug was never raised?

I cant see this bug report anywhere and my system has started to spew out these messages similar to your own php-fpm[13772]: [WARNING] [pool www] server reached max_children setting (50), consider raising it was it ever resolved?

just to say that my server is also hanging moreorless every day, needing reboot, parity etc. Mine seems to be a panic in Samba though, just in case yours is similar, not trying to hijack the thread, i've raised my own.

Having a lot of these messages in the system log ... PANIC: assert failed at ../../source3/modules/vfs_default.c(1953) followed by system lock ups, any ideas? Diagnostics attached. tower-diagnostics-20220215-1421.zip

Took a while, but I have repurposed the second parity drive for the short term. Given the amount of time it took to do I think i'l leave well alone for now. Thanks.

Thanks ... i'm inclined to agree now that i'm short of drives and have time to think about it. From a recovery point of view its down to whether i 'like' the idea of one parity disk just in case so maybe i'll drop down to one and then in a couple of months time i'll reclaim that remaining one. The original intention when i set these two servers up was to be able to flip flop them to keep the servers and disks active so from that point of view dual parity seemed a necessity. But thats long gone now and now i have a full backup, maybe i need another copy, three copies seem a good idea, that should be sufficient fallback. Mind you they all live together so maybe any efforts should be put into relocating a third server .... another project!

Guys, i'm re-assessing my drive allocations across two servers. The second server is a full backup of server 1 approx 130TB using the smaller. older drives freed up whenever i'm able to upgrade on server 1 so it follows that my backups are spread across a larger number of these drives than the main server. So ... i protect them with dual parity 2 x 10TB drives. But, the more i think about this the less i see a need for BOTH drives, one maybe but not both, or maybe even no parity drives given that this is a backup only, what are your thoughts on this? Worst, worst case scenario ... if EVERY drive fails i could just rebuild from server 1, yes? Would take time (and cash!) so is it just the physical effort i'd need for rebuild time that parity drives are saving and do i really need two cos i sure yould use some extra 10TB drives in my system just now!!

looked all through flash drive and i've not got a /config/perms.txt file, should i have? checked other two servers, backups, and no file there either, should i be worried? it's all been aok for a good while now and all the other dockers xxxarr's and sab all aok also, just the makemkv that's sketch ... Found it in the appdata MakeMKV folder, i was just getting confused with config/home locations. Either way i have NO perms file and preferences arent being saved??

I've run into the problem of not being able to save any preferences at all. I see it raised its head in the summer and was 'fixed' by deletion of a symlink??? First noticed this when i realised my rips were defaulting to all languages being saved even when i only save english titles, audio, subs etc. Anyone any idea what needs doing this time around?

<Edit> Fixed!

My system is well and truly screwed up with no gui access after calling 'rm /boot/config/ssl/certs/*.pem' as previosuly referenced in an attempt to tidy up this invalid certificate error, and then setting management access ssl/tls to 'yes', i stupidly misread the help. It was previously set to auto which i now need to reinstate cos i'm apparently not using SSl and each login attempt comes up as https//: not http:// as before. Server is only local to me so this is a real pain of a problem. how can i reinstate http: only access??

Seems like this needs a bit more testing so i'm adopting a hands off approach and just ignoring the warning for now, i've no idea how to get, or why i need a new 'certificate that matches your settings' when nothinh has changed at my (local) end. Just the plugin tht's changed, why??