Jump to content

dnLL

Members
  • Content Count

    116
  • Joined

  • Last visited

Community Reputation

5 Neutral

About dnLL

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi y'all, My check_mk monitors my syslog just in case something weird happens and it detected the print_req_error below, twice today simultaneously and the same thing last week. It happened both times while I was updating plugins... so writing to the flash drive. Is my flash drive about to die? I have 226d of uptime currently and don't plan on rebooting for a while still (probably at least until ~6.9.0), I'm on 6.7.0. I do have weekly backups of my flash drive with smart retention (12 months) so it's not a problem to restore my config if need be. It's the 2 same sectors both times... not sure if that's great or not. Unraid webUI has it at 0 error still. Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 f8 1e 00 00 40 00 Jan 17 02:35:41 server kernel: print_req_error: critical medium error, dev sda, sector 63518 Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jan 17 02:35:41 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 f8 5e 00 00 80 00 Jan 17 02:35:41 server kernel: print_req_error: critical medium error, dev sda, sector 63582 Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 f8 1e 00 00 40 00 Jan 24 18:50:39 server kernel: print_req_error: critical medium error, dev sda, sector 63518 Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jan 24 18:50:39 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 f8 5e 00 00 80 00 Jan 24 18:50:39 server kernel: print_req_error: critical medium error, dev sda, sector 63582
  2. I agree. But I don't backup everything (such as my Plex library). While losing any of the data I don't backup wouldn't bother me that much, I would still rather not. And when you use your server for some small projects that eventually grow up over time you want to avoid big downtimes for your friends (I host a webserver, a gaming server, Discord bots and so on). For the most part in my case it's more about the time involved in restarting from your backups rather than stressing out about actual data loss.
  3. Thanks to everyone involved in this, this issue has been bothering me for quite a while. I just edited the php file with vi and it fixed my issues immediately. I'm waiting for 6.8.1 to update (never been a fan of X.X.0 versions in general, I know it's silly), I'm on 210 days of uptime.
  4. My stress levels are so high while reading this thread. I really hope all will go well.
  5. Not really the end of the world but unRAID keeps saying there is a new update for this Plex docker even if I just updated it. Sorry if this has been discussed previously (didn't find it).
  6. Not sure why I didn't read about this before but I've just set it up (takes 30 seconds to do) and tested it and it works perfectly. Transcoding a 1080p movie to 480p on a poor connection with the server's IGP (some Intel HD something integrated into my Xeon E3-1245 V6) and it took about ~30MB of space on the FS... which translated to +30MB of RAM used too. As soon as I stopped the playback, the files were deleted. I'll test it for a while and as long as Plex keeps deleting its transcoding cache, this should be fine. CPU is usually around ~120% when transcoding with the GPU (or like 12% in the webUI, it's a 4c8t CPU). Without GPU transcoding it would usually gobble all 8 threads immediately until it throttled a little bit. I added another extra parameter to the docker to make sure it never takes more than 75% of my CPU: --cpus=6.
  7. Thanks for the quick reply and fixing the support thread for your docker. Since I don't see any reason to use a docker only to run a ~40ish lines script, I won't use it, but for people less at ease with programming, I can see the ease of use of just clicking buttons in the UI being helpful for them.
  8. I don't have access to this sadly: https://access.redhat.com/solutions/3249121 unRAID uses logrotate as shown here: root@server:~# cat /etc/logrotate.d/docker /var/log/docker.log { rotate 5 notifempty missingok size=5M compress delaycompress } Another suggestion coming from the Redhat community: https://bugzilla.redhat.com/show_bug.cgi?id=1477486 Maybe I should report this as a bug for unRAID. Multiple events must happen for this bug to even exist: 1) dockerd not properly closing handles on rotated logs 2) the log rotation must move files rather than copy them 3) having limited /var/log space 4) dockerd must not be restarted for a long time Workaround: using copytruncate option with logrotate. http://man7.org/linux/man-pages/man8/logrotate.8.html I added copytruncate to the config file shown above and tested before/after with logrotate -f and lsof and I can see this fixes the issue completely. I'm gonna add a user script to modify the docker logrotate config file on boot.
  9. I'm thinking docker.log is empty solely because the process is writing in the moved (but deleted) file. Since the file is still opened by dockers, despite not having a pointer on the filesystem is can still be read (and shown in the GUI) as long as you go through the dockerd process. unRAID does have logrotate not only for dockerd. I will take a look at the config and see what I can do but I'm thinking everyone has the same problem here.
  10. Traditionally when rotating a log manually you make a copy of it and empty the original, this way the process keeps writing in the original file and there is no handle on the copy. This is weird.
  11. The issue here is that we move files that are being used by the process (dockerd) so the handles stays there. Deleting it just remove the pointer to the file but the space isn't freed until the handle is fully closed. There is a workaround described here: https://unix.stackexchange.com/questions/68523/find-and-remove-large-files-that-are-open-but-have-been-deleted Now, why is docker.log rotated? To prevent it from taking too much space... but we don't prevent anything by rotating it, and since we delete the old file rather than archiving it, wouldn't it be better to just empty the file rather than move it and delete it? Not sure if this is a dockerd issue or unRAID issue, really. Who handles the log rotation?
  12. I stopped the docker engine through the webUI... here are the results: root@server:~# df -h /var/log Filesystem Size Used Avail Use% Mounted on tmpfs 256M 2.9M 254M 2% /var/log root@server:~# lsof | grep deleted ipmitail 5272 root 0r REG 0,2 1598 2925 /var/spool/atjobs/a00001018cd2c1 (deleted) tail 5279 root 0r REG 0,2 1598 2925 /var/spool/atjobs/a00001018cd2c1 (deleted) What this shows is... the problem is indeed caused by dockerd. The handles on deleted files are gone, so it was most likely the deleted files. Maybe one of the docker.log actually had stuff in it, I will never know? I still think it's a problem that deleted files take space on /var/log, I will try to find a creative solution to avoid having to stop dockerd while still getting rid of the handles.
  13. The file is actually empty. root@server:~# ls -lh /var/log/docker.log -rw-rw-rw- 1 root root 0 Sep 13 04:40 /var/log/docker.log Something else is taking space... I have no idea how? root@server:~# du -sm /var/log/* 1 /var/log/apcupsd.events 1 /var/log/apcupsd.events.1 1 /var/log/apcupsd.events.2 1 /var/log/apcupsd.events.3 1 /var/log/apcupsd.events.4 0 /var/log/btmp 1 /var/log/btmp.1 0 /var/log/cron 0 /var/log/debug 1 /var/log/dmesg 0 /var/log/docker.log 0 /var/log/faillog 1 /var/log/lastlog 1 /var/log/libvirt 1 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 1 /var/log/nginx 0 /var/log/packages 1 /var/log/pkgtools 0 /var/log/plugins 0 /var/log/removed_packages 0 /var/log/removed_scripts 0 /var/log/samba 0 /var/log/scripts 0 /var/log/secure 0 /var/log/setup 0 /var/log/spooler 0 /var/log/swtpm 1 /var/log/syslog 2 /var/log/syslog.1 2 /var/log/syslog.2 1 /var/log/wtmp That doesn't make sense at all, df says I have 168MB used.
  14. As shown in my original post I have 256MB for mine which is already double the size. Expanding it further only buys time and doesn't solve the issue. I will take a look tonight at what's in the docker logs but 200MB in 7 months ain't that bad overall considering how we use Plex alone.
  15. That won't prevent it from happening again. Of course I could do a script to do this every once in a while but I can't have Plex randomly reboot when busy, so most likely I'd need to keep doing it manually. I can't be the only one with this problem.