bling
-
Posts
34 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by bling
-
-
closing out my own thread. TLDR, turned out it was one of my docker containers spinning up on a schedule to scan files. took a while to find it, but i think the effort was worth it. i got super annoyed so i used the brute force hammer method. i installed graylog and configured every container to send all logs there. also added all the system stuff like dmesg, syslog, etc. sooooo, yea, scratching this itch gave me centralized logging for everything 🙂
-
2
-
-
does anyone know if there's a way to store files simultaneously on the cache drive and on the array? i'm trying to be a little more green so i'm trying to see if there are ways to minimize disk spin up.
something along the lines of;
- file gets written to cache.
- mover copies to the array instead of moving it.
- after some time or free space threshold, files that were previously copied get deleted from the cache.
applications would still look under /mnt/user, so as far as they're concerned, there's only one copy of the file, but the array will not spin up.
-
12 hours ago, korey_sed said:
I got this to work for one of my dockers buts some do not work. how do you name the tamplate? or what is the trick to make unraid realize and link the template to the contianer?
take a look at /boot/config/plugins/dockerMan/templates-user, which is where unraid stores all the XML templates. any time you add a docker container from the community apps, for example, creates a file and saves it here.
if you're using docker-compose you don't need to fill in the rest, just the high level things like the name, repository, icon, URL, etc.
and of course, this is all non-standard and really the only reason why you would do this is if you want nice icons on your dashboard. you do not want to use unraid to manage your containers because it will mess up both unraid and docker-compose.
-
8 minutes ago, SimonF said:
This thread may be your issue also. Did it happen on 6.9.1?
not sure if it happened in 6.9.1 because i wasn't looking at it. i only stumbled upon this because it appears 6.9.x changed the default for spin down to "never", and when i noticed all my disks were always green i went ahead to changed it and that's when i observed that disks were up when they weren't supposed to.
had a brief read of your linked thread but i don't think my issue is that. i don't have problems spinning down disks, that happens as expected. my problem is they randomly wake up and there's nothing in file activity logs or syslogs to indicate any read/write is happening at the same time.
-
8 minutes ago, dlandon said:
Post diagnostics.
if there's particular information from diagnostics you're specifically looking for i can provide that. but since i have verbose logging turned on everywhere i'd have to go through all the files to ensure it's appropriately anonymized.
-
currently running 6.9.2 and observing disks spinning up when there's no reason to. i've tried tracking it down but no luck.
the syslog pretty much always contains "emhttpd: read SMART /dev/sdb" when the disk spins up. i believe this is a red herring as unraid itself is not the one that actually spins up the disk, but will use smart to read the temperature after something else spins up the disk (please correct if wrong).
i installed the File Activity plugin so there are cases where i observe "read SMART" without a corresponding entry to read/write anything.
what's most confusing is that my parity disk will spin up with no writes logged anywhere.
any other tips & tricks i can try before i brute force turn off all docker containers/plugins to narrow it down one by one?
-
count me as another user who's migrated everything over the docker-compose so this is a welcome development.
i've also found the missing icons annoying. rather than editing core files i'm opted to create templates instead with the same container name and leave everything else blank. this is enough to trick unraid. something like this:
<?xml version="1.0"?> <Container version="2"> <Name>portainer</Name> <Repository>portainer/portainer-ce</Repository> <Registry>https://hub.docker.com/r/portainer/portainer-ce/</Registry> <WebUI>http://[IP]:9000/</WebUI> <Icon>https://secure.gravatar.com/avatar/681edab450c1ebab7d83e7266b1d0fbb.jpg</Icon> </Container>
you'll have to edit the files directly instead of going through dockerman. and while you can use dockerman to start/stop containers, you can't use it to do anything else like editing containers, updates, etc. otherwise you will mess up your compose configuration and be forced to manually delete conflicting containers.
but, once you're fully committed to compose it's literally just a
docker-compose pull docker-compose up -dto get the latest of all images and restart everything.
dockerman will still inaccurately state that everything is out-of-date, but i've learned to ignore that.
-
1
-
-
just upgraded. posting what i had to do for others in case they had similar issues to me.
-
docker-compose
- all of my containers are in a single docker-compose.yml file and that reloaded without any problems after the array was started. hooray!
-
ssh
- per the release notes, a password is required now. i enjoy the convenience of no password so i ended up just setting up private key authentication instead.
and...that's it. pretty seamless upgrade. thank you!
-
2
-
docker-compose
-
On 3/26/2020 at 5:32 AM, nextgenpotato said:
If I change the time zone to something else from UTC, web UI stops working.
This suggestion below worked for me, thanks!
But I think this may be the reason that if I change any other settings UI stops working
the image doesn't have any time zone info so you need to add a volume mount for /usr/share/zoneinfo
-
feature request. can we add the ability to disable certain checks? for me, notably all of the checks for docker (updates, templates, etc) are creating false positives because i've completely swapped everything for docker-compose.
however, even if i didn't do that, i'm sure there's a ton of people that would prefer checking for docker image updates to be disabled. "if it ain't broke, don't fix it". this is especially true when a new docker image introduces a breaking change, which could be especially bad if it corrupts the appdata and there are no backups.
-
1 hour ago, mbc0 said:
Hi, @blingsorry for the delay in thanking/getting back to you! I have just tried this and it unfortunately fails?
This is the docker I wanted to use that uses a vpn and killswitch
These are the extra parameters I put in
--net=container:binhex-delugevpn
and this is the error I get?
/usr/bin/docker: Error response from daemon: Container cannot be connected to network endpoints: container:binhex-delugevpn, host.
See '/usr/bin/docker run --help'.
The command failed.Am I missing something obvious?
Thank you
you need to set the network type to 'none', so that the --net in the extra params will work. also, if your child container has a port exposed you need this defined on the parent container instead otherwise you can't access it.
-
1 hour ago, cbc02009 said:
Thanks, I haven't quite figured out how to manually add dockers to unraid.
Thanks! Maybe the privoxy part was throwing me off, because I haven't come across that yet.. I'll look into it.
hit the 'add container' button at the bottom of the docker tab in unraid and fill in the details. as for privoxy, that's just a proxy that allows other applications to reuse the existing VPN connection of the container. prior to the introduction of --net, this was how you got other containers to reuse a single VPN connection. however, it also means that the software must support specifying a custom proxy server.
with --net, you don't need to define a proxy configuration in any client running in a child container because it's network gets isolated to only use what the parent container can provide. however, it's still useful to have a proxy for non-docker applications. for example, instead of running some VPN software on your windows machine, you can change Chrome/Firefox's proxy settings to go through your docker container.
-
1
-
-
there are tons on docker hub. pick one and add it manually.
-
On 3/11/2020 at 7:11 PM, mbc0 said:
Hi,
Do you mean instead of or as well as?
--net=container:foo
-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.0.138/[email protected]'
instead of.
using --net replaces any existing method for achieving this. you don't need to set up proxies or anything because any "child containers" will reuse the network of the parent. so all you need to do is find a docker container (there are tons) that do openvpn + a kill switch as the parent and you're good.
-
FYI you can put "--net=container:foo" in the extra params to make any docker container reuse the network of an existing container (example here is that "foo" is the docker container connected to the VPN). the recently released 6.8.3 makes this work again without the need for workarounds.
-
it's the PSU. since i swapped with a spare it hasn't crashed regardless of what workloads i threw at it. did a full parity check and some bits needed correcting.
-
memtest passed overnight. rebooted unraid in safe mode, and within moments of a medium workload within a docker container, reboot!
i checked /proc/sys/kernel/panic, and it's set to 0, which is the default meaning it will not auto-reboot.
just swapped out the PSU with a spare...wish me luck!
-
Another bit of useful information, I caught it doing a random boot in the middle of a reboot! I SSHed into the box, was tailing the log, before emhttp started up I lost connection.
-
It's my old rig that I repurposed as a NAS server. 4790k, asrock mobo, 16GB RAM. It's been rock solid since day 1 when it was running Windows. Recently when I rebuilt it for unraid, all the hardware remained the same except for new hard drives, a recently replaced PSU under warranty, and a new UPC.
I'm running memtest right now, directly plugged into the wall.
-
Sigh....while I was rsyncing from the array back to a freshly formatted XFS cache disk, the server hard rebooted again. So I guess that rules out the file system. I had putty tailing the syslog at the time and nothing was logged during the reboot. I'm also tailing dmesg now...
-
Logged in this morning to my server and noticed that a parity check was running, which I thought was odd. I was like hmmmm...I didn't start that. Maybe I had it scheduled for end of the month? Checked that, nope -- it's off. Then I realized that the uptime was an hour. My machine is 24/7 and has been rock solid for 2-3 weeks.
From there, I was experimenting with a new docker app, and then bam!! Random reboot. From here, I turned off docker/VMs and let the parity check run to completion. Thankfully no errors.
Just now, again, playing around with a docker app, and it rebooted again. This time, I'm greeted with an unmountable btrfs cache disk (can't read superblock).
I was able to mount the cache disk in read-only mode with nologreplay and copy everything to the array. I've heard horror stories of others with corrupting btrfs cache disks, and once I copy everything over I'm reformatting my cache disk to XFS. Ironically, this is usually due to sudden power loss, and even though I do have a UPS hooked up, it didn't protect from the computer rebooting itself.
Could a bad hard drive cause random reboots? I'm highly suspecting it's either the drive or btrfs, given that's the only thing common in all 3 reboots. All docker containers are using the cache disk. Thanks in advance.
-
what's the difference between the elements such as Container.Environment.Variable vs Config[Type=Variable]? as far as i can tell, these are always duplicated and they always match. the same applies for ports and device/volume mounts as well.
-
On 2/20/2020 at 12:34 PM, ithelpme said:
Thanks Bling, can you elaborate on how you override the entrypoint? I don't see entrypoint as a variable in Unraid.
turn on advanced view and put it into 'extra parameters'.
-
FYI you can run both the web server and consumer in a single docker container by using a bash script:
#! /bin/bash /sbin/docker-entrypoint.sh document_consumer & /sbin/docker-entrypoint.sh runserver 0.0.0.0:8000 --insecure --noreload & waitsave this file into a volume that's mounted in the container. i just put this in the appdata directory.
then turn on advanced view and override the entry point, e.g.
--entrypoint /usr/src/paperless/data/entry.shclear out the 'post arguments', since you're doing that in the bash script now.
-
3
-
Use docker labels for UnRaid-specific information in docker templates to allow for a 1:1 map between UnRaid templates and docker-compose files.
in Completed
Posted
just upgraded to 6.10.1. are the labels working for anyone else? here's a simple compose file.
version: "2.2" services: nginx: image: nginx labels: - net.unraid.docker.icon=https://some.server.com/image.pnglaunched the container, went to the docker tab, but the image doesn't get loaded.