dtempleton

I'm managing my server from 12,000 miles away and have only a neighbor available to do a pushbutton reboot should things need it. So I'm a little restricted in what I can do to manage the unexpected. Recently one of my images (needo's SABnzbd) has been giving me trouble. The symptom is that the WebUI stops loading. OK, so I'll restart the container. No problem, except I'm unable to shut down (or restart) the container using either the unraid WebUI or the CLI. I can kill it by killing processes labeled "docker" on the server, though sometimes this crashes the server. However, even if I kill it, I can't restart Docker and can't restart the server because /mnt/cache is not unmountable. Powerdown or reboot usually results in an unresponsive server requiring a powerbutton reboot; the webUI hangs on "unmounting array". I can get into the container with docker exec -it. I can kill sabnzbd with kill -9 <pid> and it shows the process as <defunct> But I can't seem to unmount the config directory on /mnt/cache (at /dev/sdk1): "umount: /config: must be superuser to umount" I'm root in the container, and can't figure out what a superuser is in this context. I suspect I will also have a hard time rebooting or shutting down the system within the container<edit: Yes, I am unable to reboot or shutdown or halt>. Q: How can I unmount a mount within a container? superuser??? I did seem to be able to kill docker entirely (shut down all other containers, then identify the remaining processes (2) that are labeled docker. I'm pretty sure which one maps to this container based on uptime. If I kill these, I hope to be able to restart docker, though I'm not sure if the /mnt/cache mount will remain locked up. There is no unRAID webUI page for docker in this instance. Q: how do you restart docker from scratch using the CLI? Finally, I'm not sure what's going on with this container. It's been stable for a year or so, and I have tried rebuilding it, even deleting the image and downloading fresh image from the repository. Mappings have not changed, or anything else in the container. Your advice will be appreciated; Dennis UnRAID 6.0.0

This topic seems to have been dropped, but I had the same question and figured out one way. The Docker "run" syntax includes a target script/argument $ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...] See https://docs.docker.com/reference/run/ I wanted to run a target script /my/script/lives/here/script.sh but I couldn't find where to put that in the UNRAID docker template. I first tried to edit the container from the UNRAID Docker page and paste the path in the docker "extra parameters" field within UNRAID. This works for --cpuset-cpus but adding the script path just deleted the container, though it was easy to restore. Instead, I decided to do it through the CLI. First, I restarted the container, and copied the command that was successfully loaded. Then in terminal I ran docker stop <container> docker rm <container> To stop and then remove the image and then pasted the run command from the UNRAID page and added <space>/my/script/lives/here/script.sh This is literally the command (deleting port numbers): /usr/bin/docker run -d --name="handbrake" --net="bridge" -e WIDTH="1280" -e HEIGHT="720" -e TZ="America/New_York" -p 8**2:8080/tcp -v "/mnt/user/Media/":"/media":rw -v "/mnt/user/Media/handbrake_watch/":"/input":rw -v "/mnt/cache/appdata/handbrake/":"/nobody/.config/ghb":rw -v "/mnt/user/Media/handbrake_out/":"/output":rw --cpuset-cpus="3" pinion/docker-handbrake-cli:latest nobody/.config/ghb/scripts/convert.sh Executing it gave a running container that launched my script. I wasn't sure if the cmd-script would be launched upon container restart, but it is. Now when I start or restart the container the script is launched inside it. The script directory is mapped in the container, so I can edit it in /mnt/cache/appdata/etc The suggestion to edit the container works and I tried that in an earlier iteration, which worked after 'committing' the container. However you will lose these edits if you update the image, which is surprisingly easy to do; it happened to me twice. I like having an editable script launched with the container that can easily be rebuilt. Hope yours works. Dennis

I don't think it's the same. The CPU quota throttles the usage (in their example " Set this value to 50000 to limit the container to 50% of a CPU resource.") rather than prioritizing processes. My understanding of nice is that a process will burn 100% of all CPUs until there is a competing process with a higher priority, at which time the high-priority process runs and the nice process is slowed. When the high priority process is completed, the nice process goes back to being unthrottled. Maybe I'm giving nice too much credit, but that's how I've always understood it. The --cpu-quota looks to be similar to the --cpuset-cpus suggested above that allocate one or a few cores to a process, it's just time managed instead of processor number managed.

You should be able to put those extra paramters in the <ExtraParams> </ExtraParams> tag in the template xml. In the webgui it's under advanced view and Extra Paramters. Actually I found some advice in Jon's "Get Fancy with Docker" pinned thread about it, using a different avenue.

As a suggestion for the FAQ, though possibly not frequent: How can we manually modify the 'docker start' autostart command that seems to be populated through the template? Background: I have a background script that requires launching a container (through 'docker run', not 'docker start') with flags including --rm and -cpuset-cpus. I can't see how to include any of these options in the template. I can keep a copy of the run command (with mappings) handy for use through ssh when the server is rebooted, but it would be great to have this custom container autostarted, or restarted. D

Thanks. I had trouble at first because -cpuset-cpus works on docker run not docker start, for reasons I can't understand. However using the docker run -cpuset-cpus="0,1" ... command the container installed and my cpu% is running between 60 and 80% with mover running, and handbrake is getting the job done too. it would be great to have nice too. Thanks Dennis

Yes, that's a far better solution, I just didn't see at first how to run a script in the container and also monitor a folder in the container. I did that last night by putting the convert script and the watch script in the bound config directory, and passing a docker exec [script] command from the watch script on the tower. Thank you all for your help Dennis

This is a different Q separate from my last message. I have installed Sparkly's HandBrake Docker just to use the HandBrakeCLI interface to convert files placed in a watched folder. I set up the watched folder and the folder monitoring script and then used docker commit to formalize the change in the image. This is working well, but while the docker is running handbrake, all of the CPU for the server is consumed by the conversion process. I would prefer if it could be throttled back to 50 or 75% to leave time for other server activities. I thought first about Nice, but in my reading, running Nice within a Docker restricts the processes *within* the docker, which would result in the docker as a whole running as much CPU as it wants, no different from now. I believe that it is not possible to run Nice on the docker container itself, or am I wrong there? Is that what --cap-add SYS_NICE is all about? (Manual says 'Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes.' but not sure what arbitrary processes means here.) I've also seen the option to launch the docker with a CPU restriction, i.e. docker run --cpuset="0" ... but Nice would be... nice. Also, if there is a special docker run command, is there a way to edit the default autostart or restart script? I'd appreciate any advice you have. Dennis

I have installed Sparkly's HandBrake Docker just to use the HandBrakeCLI interface to convert files placed in a watched folder. I set up the watched folder and the folder monitoring script and then used docker commit to formalize the change in the image. My question. that I haven't found in the Docker FAQs, is whether the changes that I committed to the image will be lost if I update the docker image using the UnRAID script. In other words, is the update 'smart', leaving my changes in place, or will the process replace the whole image back to a state last compiled (by sparkly). I'm guessing that yes, the changes would be lost, but I'm actually more worried about restoring from the my handbrake template. My changes would likely be lost there too. If that's so, what's the best way to back up the image that I have recently 'commit'ed? Thanks D

I've had to replace my flash drive because of apparent data corruption on the flash (thanks Tom for the nice key replacement system), and restore it from the downloaded 6.0.0 image and a month old backup since there seems to be a bad file or two on the original flash. However, I don't have my most recent docker templates (MariaDB) and Docker can't find my-template for this container. I can't see where on the flash drive that the templates are stored. docker.conf doesn't have anything that looks like templates, so, please, Where on the flash drive are the docker templates stored? I don't believe it can be on array drive since those haven't changed. Thanks! D

I've installed it with quite a bit of self-education along the way ;=) I got the MariaDB databases made, but haven't been able to get CP to notify (they only say xbmc 11, 12, 13)... that's for later. SB- you made comment about a command for Kodi (v14) a while back to scan a library: docker exec KODI-Headless-test kodi-send --action="UpdateLibrary(video)" When I try this on v-15 using the appropriate docker container id I get the error "executable file not found in $PATH" Is there a command to replace kodi-send in v 15? (or a URL for additional self education)? Thanks D

Thanks, all, it's fixed. The extra USB stick (not labeled UNRAID) is a red herring, the key was not recognized even with that out. I think the owner shown on Mac is me (dennis) and on UNRAID is root. Just captured it on my mac. What worked was to: Backup the whole flash. Format the drive with mac disk utility. Copied a new DL of 6.0.0 to the flash; added the Pro.key ran make_bootable_mac ===>>> This install worked Copied the misc files and directories that were in /boot and /boot/config that seemed related to my previous setup. ===>>> This install worked and seems to have all my stuff. My first try was similar without the drive format reformat, but that didn't work. Given the file read errors pointed out it must have been a corrupted flash. This must have occurred silently over the last year, or coincidentally with the last upgrade. Thanks all! D

This is a continuing issue first noted on the 6.0.0 announcement thread. While updating from rc5 to 6.0.0, I backed up my /config folder via ssh using the Transmit.app. This made a /config_copy file, and left the original. I updated to 6.0.0 through the plugin update button. Upon restart the webGUI page loaded the 'registration page' i.e. "Your server will not be usable until you download a registration key. " There is a link to purchase a key or get trial key, but not a link to "replace key" that is cited in a recent post about 6b15. I'm not eager to post my GUID here. Things I have tried: Rebooting. Rebooting in safe mode. Renaming the old /config directory to the original name and rebooting removing the flash and checking permissions in /boot/config (all dennis:staff 777) checking the integrity of the flash on mac disk util (no errors found) I note that there is an opportunity to install the ProKey via a URL, which might fix it. I bought the flash preconfigured with 5.0.5 and don't have a link to a key from LT. The flash in question is the original one from LT, modified only with a series of 6.x betas. I am attaching the diagnostic from today, and the ls of the contents of the /boot/config directory. Thanks Dennis tower-diagnostics-20150619-0851.zip Flash_config_directory.txt

Instead of selecting free trial, which might have worked for now, I went back to the command line and rebooted again with powerdown -r. Now I can't login with SSH: ssh: connect to host xxx.xx.xx port 22: Network is unreachable It's not an emergency (since GoT is over), but I'm doing this remotely and won't be at the server physically for a few days. Reporting mainly in case what I did is an error others might do too. Is this related to the duplicated /config folder? The Unassigned Devices plugin? Thanks D Hmm, definitely not the norm as you can see from most folks in this thread who've upgraded. Will need to see diagnostics report from Tools -> Diagnostics to give you any guidance. Thanks Jon; still can't mount the GUI with my pro key after the upgrade. I've tried rebooting in safe mode, and renaming both the 'original' /config and the /config_copy made via SSH (using transmission.app) directly on the flash. The diagnostics report is attached, as is the listing of the /boot/config directory on the flash. The Prokey file is there with the original modification date. I note that when I mount the GUI the terminal reports that /boot/config/*.conf (and *.dat and *.cfg) are not found The GUI has a place to 'install a key file' if you have a key file URL. I bought a preconfigured (5.05) flash and know not of a URL. Thanks D Feel free to transfer this to the support page. I noticed the following lines in the syslog: Jun 19 08:50:35 Tower kernel: read_file: error 2 opening /boot/config/super.dat Jun 19 08:50:35 Tower kernel: md: could not read superblock from /boot/config/super.dat Jun 19 08:50:35 Tower kernel: md: initializing superblock Jun 19 08:50:35 Tower emhttp: Unregistered (-3) This suggest to me that there might be some corruption on the flash drive and unRAID is having trouble reading it. Have you tried putting the flash drive into a Windows PC to see if offers to repait it (and let it do so if it offers). Thanks for the suggestion. Mac disk utility says no errors. Moving this to a support thread, thanks. [edit- reformat flash drive and copy 6.0.0 files over works fine]

Instead of selecting free trial, which might have worked for now, I went back to the command line and rebooted again with powerdown -r. Now I can't login with SSH: ssh: connect to host xxx.xx.xx port 22: Network is unreachable It's not an emergency (since GoT is over), but I'm doing this remotely and won't be at the server physically for a few days. Reporting mainly in case what I did is an error others might do too. Is this related to the duplicated /config folder? The Unassigned Devices plugin? Thanks D Hmm, definitely not the norm as you can see from most folks in this thread who've upgraded. Will need to see diagnostics report from Tools -> Diagnostics to give you any guidance. Thanks Jon; still can't mount the GUI with my pro key after the upgrade. I've tried rebooting in safe mode, and renaming both the 'original' /config and the /config_copy made via SSH (using transmission.app) directly on the flash. The diagnostics report is attached, as is the listing of the /boot/config directory on the flash. The Prokey file is there with the original modification date. I note that when I mount the GUI the terminal reports that /boot/config/*.conf (and *.dat and *.cfg) are not found The GUI has a place to 'install a key file' if you have a key file URL. I bought a preconfigured (5.05) flash and know not of a URL. Thanks D Feel free to transfer this to the support page. tower-diagnostics-20150619-0851.zip Flash_config_directory.txt

Not so smooth an update here. Previously running RC6, with a Pro key. Before update made copy of /boot/config folder and labeled it differently. Updated both UnRAID to v6.0.0 and Unassigned Devices to version released today through the plugin update button. Reboot with powerdown script via SSH, (powerdown -r) Log in via SSH. Hmmm, authorized keys are not working, asks for my password. That's odd. Tower/Main reports this: Instead of selecting free trial, which might have worked for now, I went back to the command line and rebooted again with powerdown -r. Now I can't login with SSH: ssh: connect to host xxx.xx.xx port 22: Network is unreachable It's not an emergency (since GoT is over), but I'm doing this remotely and won't be at the server physically for a few days. Reporting mainly in case what I did is an error others might do too. Is this related to the duplicated /config folder? The Unassigned Devices plugin? Thanks D

Actually it's a neurodegenerative symptom. I neglected to open up these ports on my router, though at one point I thought I had checked that by swapping ports. It's been a long day and I'm sorry for the confusion between my problem and the other 'DNS' problem. I too have been very happy with rc4/5 and am looking forward to a final. Thanks all. D

That's right, other than I rarely use http://tower.local (which works) and instead use a dotted internal IP address, which works. I had assigned a 5 digit port to the app, and thought maybe I was in a prohibited range in the router. I just swapped the port # with a port # successfully used with an app that can be accessed through the internet, and it still doesn't work with Calibre. Therefore the problem does not reside in my router, since the same port can access one but not the other app. I'm sensing that this is not an unRAID issue, but a Docker or app issue.

Above you say: Can't resolve which 'server'? I can reach the RPD-Calibre server on the local network (192.168.1.xxx) but not on mydns.freedns.org, while all the other web interfaces for docker apps or the unRAID array can be accessed either locally or through mydns, i.e. through the internet. It's just this one docker app. Several folks have noted similar issues with different apps. One person recommended switching from bridge mode to host mode and then back but that did not fix the problem for me. Thanks D

root@Tower:~# docker exec RDP-Calibre ping google.com PING google.com (216.58.217.142) 56(84) bytes of data. 64 bytes from iad23s43-in-f142.1e100.net (216.58.217.142): icmp_seq=1 ttl=54 time=26.3 ms 64 bytes from iad23s43-in-f142.1e100.net (216.58.217.142): icmp_seq=2 ttl=54 time=25.6 ms 64 bytes from iad23s43-in-f142.1e100.net (216.58.217.142): icmp_seq=3 ttl=54 time=26.0 ms

Please try these commands and post output: cat /etc/resolv.conf cat /etc/hosts hostname Then pick one of your containers with no dns and type: docker exec <container-name> cat /etc/resolv.conf docker exec <container-name> cat /etc/hosts docker exec <container-name> cat /etc/hostname replacing <container-name> with the actual container name. I have a new docker (RDP-Calibre) that works fine on my local network but can't resolve the server via DNS. My other dockers do both just fine. Here is the output from the request above: root@Tower:~# cat /etc/resolv.conf # Generated entries: nameserver 192.168.1.1 root@Tower:~# cat /etc/hosts # Generated 127.0.0.1 Tower localhost root@Tower:~# hostname Tower root@Tower:~# docker exec RDP-Calibre cat /etc/resolv.conf # Generated entries: nameserver 192.168.1.1 root@Tower:~# docker exec RDP-Calibre cat /etc/hosts 172.17.0.5 654fe35bb0ef 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters root@Tower:~# docker exec RDP-Calibre cat /etc/hostname 654fe35bb0ef So it appears that the Docker is not getting a resolved name the way the server itself is. Both this docker app and the ones that work are bridged and have TCP ports aliased in similar ways. I'm attaching the diagnostic log, though not sure if it has docker app info. Thanks D tower-diagnostics-20150610-1437.zip

I see that the rc3 incorporated APCUPSd into the os. After update from b10a I still see the APCUPSd plugin listed as a plugin, not 'built in' the way dynamix is. I'm running Apcupsd-3.14.10-x86_64_3pb and it shows 'no update'. I have evidence that the APCUPSd plugging is still doing its job, so, it ain't broke... Am I supposed to delete this plugin to get it out of the way of the builtin? Again, it ain't broke... Similar question for Powerdown, cachedirs, preclear_disk, snap-x86_64, ntfs-3g, and Overbyrn's SSH and denyhosts plugins. Can't tell what's still doing its job and what's detritus from the older system. Thanks Dennis

OK, to answer my own question. This seems to be a longstanding problem with netatalk, that places a number of files named .fuse_hidden########### in the .AppleDB directories. These are hard to delete because a netatalk ps called cnid_dbd is open and accessing them. I found this with lsof .fuse_hidden0014ba9300000036 (one of the files) then killed the cnid_dbd ps that showed up. The .AppleDB directories that are a problem can then be emptied and deleted as normal. the cnid_dbd ps seems to restart relatively quickly so it might pay to shut down netatalk entirely or at least be prepared to kill the process again if you don't delete the .AppleDB files right away. Then restart unRAID (or maybe restart netatalk) and mover works as normal. Please let me know if there is a way to prevent it. I do mount most of my shares with SMB but must have used AFP recently.

Since upgrade to 6rc4 Mover has failed to remove files to the array. This might correlate with setting up Dropbox and having a number of my mac files moved to the server cache volume. The forum contains reports that this is due to netatalk, which makes sense since my log is full of the following failures: Jun 8 22:09:43 Tower logger: ./Media/Movies/!New/blank (2015)/blank.mkv Jun 8 22:09:43 Tower logger: .d........x Media/ Jun 8 22:09:43 Tower logger: .d..t...... Media/Movies/!New/blank (2015) Jun 8 22:09:43 Tower logger: >f+++++++++ Media/Movies/!New/blank (2015)/blank.mkv Jun 8 22:10:01 Tower logger: rsync: rsync_xal_set: lsetxattr(""/mnt/user0/Media"","user.org.netatalk.Metadata") failed: Operation not supported (95) Jun 8 22:10:01 Tower logger: rsync: rsync_xal_set: lsetxattr(""/mnt/user0/Media"","user.org.netatalk.has-Extended-Attributes") failed: Operation not supported (95) Jun 8 22:10:01 Tower logger: rsync: rsync_xal_set: lsetxattr(""/mnt/user0/Media"","user.org.netatalk.supports-eas.A2PmUJ") failed: Operation not supported (95) Jun 8 22:10:01 Tower logger: rsync: rsync_xal_set: lsetxattr(""/mnt/user0/Media"","user.org.netatalk.supports-eas.KHFHlm") failed: Operation not supported (95) Jun 8 22:10:01 Tower logger: rsync: rsync_xal_set: lsetxattr(""/mnt/user0/Media"","user.org.netatalk.supports-eas.OFF9mm") failed: Operation not supported (95) One user suggested it was due to Apple's notorious hidden files, so I deleted them from the cache using a script to remove all ".Apple*" files. No joy. Another user said cryptically that he got Mover to run by removing the "-X" argument from the Mover script (I might have that wrong, and I didn't try that.) With all the upgrades in netatalk perhaps others have resolved what seems to be a recurring issue. Advice?

YES! Thanks, I had forgotten that we have access to disk (not just share) settings. It's funny that the default for AFP is noExport and SMB is yesExport. Fixed now, thanks very much. Dennis