butlerpeter
-
Posts
192 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by butlerpeter
-
-
Knowing that the script got called (or not) should be enough for now.
Thanks.
-
Thanks for that - I've just put my scripts in place - will see what happens next time containers are updated.
Incidentally - does anything get logged anywhere when the scripts are called?
-
9 hours ago, Squid said:
Actually hadn't forgotten...
I have to wait until Friday's round of lsio updates, but what I'm going to do is this.
No GUI as I see this as rather limited in user needs
- Prior to stopping containers, if it exists, something like "/boot/..../stop/stoppingAll.sh"
- Prior to stopping any particular container, a script called "/boot/.../stop/nameOfContainer.sh" will be called if it exists
- After restarting any particular container, a script called "/boot/.../start/nameOfContainer.sh" will be called if it exists
- After restarting all the containers, a script called "/boot/.../start/startingAll.sh" will be called if it exists
Should allow you the flexibility to do just about anything you want. Work for you?
Yes that should do the job. Thanks
-
On 12/03/2017 at 5:54 AM, Squid said:
Remind me to do this in a couple of days....
Bumping as a reminder as requested.
-
Is there any possibility for the ability to run a custom script after dockers have been updated?
I have a self built docker container which doesn't get updated very often. But it depends on a mariadb container that does get updated. When the weekly docker update process happens, if the mariadb container has been updated then my custom one falls over.
It's a simple fix for me to ssh in and restart that container, but if it was possible to script it then it would save me having to (remember to) check.
-
Sparklyballs has pushed an update to hopefully fix this...
Excellent news. Look forward to it being merged and released.
-
Recently had a bit of a strange issue with the mariadb container.
It's had been running fine for weeks, ever since migrating to it from a container from another author.
Yesterday I did the upgrade to unRAID 6.1.7, so during the course of stopping the array to reboot the dockers were stopper. The upgrade went to plan, rebooted the server, started the array again and all of my docker containers came back up - or so I thought.
It was only some hours later that I noticed something was wrong with the mariadb container. Looking in the logs (which I don't have to hand unfortunately) I saw continuous, repeated, failed attempts to start mariadb.
There was a log message about it having not been shutdown cleanly (sorry I don't have the exact text), with messages about recovering from a crash, and then each attempt to start was followed by a message saying that the table mysql.users didn't exist (again sorry for not having the exact text).
Looking at the /config/databases folder I saw that the owner of the mysql directory had been changed from 'nobody' to '103' - 103 seems to be the uid of the mysql user inside the container. "chown -R nobody:users mysql" fixed the complaint about the mysql.users table. But then there was a similar message about another mysql.*something* table, and when I looked the owner of the mysql folder had changed to 103 again.
Changing the owner back to nobody this time fixed things and mariadb started up correctly.
I suspect that what happened was that there was an unclean shutdown (of mariab) and when starting up again it attempted to recover and during that process tries to ensure that it has correct access so changes the owner of the folder to the mysql user. Which then leads to access problems and stops it accessing those mysql.* tables.
I wonder if the mariadb startup script "/usr/bin/mysqld_safe" (I think!) should be changed to take into account the uid that has been specified for the container to run as, instead of just using the mysql user?
Hope that makes sense!
-
As posted in the KVM forum, in the PXE booting OpenELEC thread.
I've created a container, based off of sparklyballs tftpdserver dockerfile that runs dnsmasq configured to proxy dns/dhcp to an existing service (e.g. a router) and which provides the tftp server required for pxe booting.
I've not created an unRAID template or repository, but the link to it on the docker hub is https://registry.hub.docker.com/u/butlerpeter/dnsmasq-docker-unraid/
-
I would attempt two things:
1) The BIOS updates
2) Try the command line methods to reading CPU usage and see if they fluctuate better
It appears this issue really is resolved, but that the way scaling occurs on more modern systems is different than the way we used to see it occur.
jon,
I will try the bios updates when I get the chance. But, I have already been using the command line methods to read usage - mentioned in my post - I'm not going by the web gui dashboard figures at all.
Booting without the "intel_pstate=disable" the figures are always very high whereas with that in place, and the server in the same state, the figures drop to expected levels.
-
For me on RC4, removing "intel_pstate=disable" and then running "cat /proc/cpuinfo | grep MHz" (at various different times and without dashboard open) always shows all cpus (cores) running at 3400MHz+
Adding "intel_pstate=disable" back in and they are back to dropping to 800MHz.
The cpu is a Xeon E3-1240v3 on a Supermicro X10SL7-F motherboard. There are bios updates for the board that I haven't had chance to apply yet, it's running v1.1a and I see that v3 is the latest available, but I can't find anything to detail what the changes have been to see if there is anything relevant.
-
Disabling intel_pstate works like a champ for me.
grep -m 1 'model name' < /proc/cpuinfo
returns
Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
Cpu's are now mostly sitting at 800Mhz and ramping up when necessary
-
Hmmm
Having upgraded to b12 running
awk '/^cpu MHz/ {print $4*1" MHz"}' /proc/cpuinfo
or
cat /proc/cpuinfo |egrep -i mhz
boths shows all of my cpus pretty much pegged at 3400 MHz.
Which tallies with what Dynamix gui is showing. Dynamix is also showing cpu utilization in the low single digits (currently hovering between 1 and 4%).
Doesn't look like my cpus are stepping down. Am booted with the default KVM option and
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
shows powersave for all cores.
-
I saw the original posts in the announcement thread and then here, but nothing seems to have been confirmed either way.
So, is this a thing, or just a reporting issue?
-
Just tried and all seems to be fine. Thanks for those changes
-
Okay,so the screen session merely needs the xterm prompt wrapping in an <ESC>P....<ESC>\ pair?
I can add that easily enough.
Yep, if that's what those codes mean (I found it in a forum somewhere).
Having it added to your plugin would be great if you get a chance.
-
Nice little addition
I installed it and logged in as a non-root user via ssh, worked great. But if I ran su to do something as root it didn't updated the window title anymore.
So I added a ~/.bashrc file which just contains
source /etc/profile
and now it works just fine
Any possibility you could add the creation of the .bashrc file to the plugin?
It also doesn't update from within a screen session, not found a fix for that yet though.
Edit:
I think I found a fix for the screen issue. I changed the added code in /etc/profile to be
if [ $?TERM ]; then #paob case $TERM #paob in #paob xterm*) #paob PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"' #paob ;; #paob screen) #paob PROMPT_COMMAND='echo -ne "\033P\033]0;${USER}@${HOSTNAME}: ${PWD}\007\033\\"' #paob ;; #paob *) #paob esac #paob fi #paob
and it works from within a screen session too
-
Has anyone looked into Newznab+ ?
Thanks
I am not sure the licensing would allow it.
This one instead - better fork of it: http://forums.nzedb.com/index.php
Myk
Newznab+ cant be forked so whatever that is it is not a fork of Newznab+ (at least a legal one)
It could be a fork of Newznab (non plus) but thats like putting a bigger engine in a cheap car and claiming its as good as a Ferrari.
I have been thinking about it an NN+ could be put in a docker if the user was able to define the SVN URL and pass as a variable.
I have a docker container running for nZEDb - it is configured to access the nZEDb files from a mapped volume, so that nZEDb is installed outside of the docker. I have it that way because I already had it installed and couldn't be bothered with getting the container to do the installing, and my Linux scripting isn't the greatest.
It works well though, I have it connecting to a database hosted in needos mariadb container.
It would need more work to make it suitable for distribution through the docker hub but, if there is interest I could post the dockerfile I used to build it.
-
So they sell the extra cage...
...but it doesn't include trays...
...but they sell the trays (or send them free of charge in your and hopefully my case)...
...but you don't get the screws...
...and they don't sell the screws separately (as far as I could see)...
So you can buy the cage and trays and still be unable to mount the drives
I bet the trays didn't include the rubber grommets either did they?
I have emailed to ask if they can include some screws when sending my trays out, but in case they don't. Does anybody have any idea what type of screws they are? Is there a "proper" name for them? So I can look for an alternative source.
-
And they should include the screws - especially as they're non-standard!
-
It definitely didn't say that it didn't come with the trays - not when I followed your link to it anyway.
I suspect it's been changed because both you and I have been in touch and questioned them about it. I have had an email back to tell me that they are sending me some trays as well, hopefully this week.
Quick question - did the trays they sent include the screws for mounting the drives into them?
-
The part was HDD-Tray white (DEF-R4-HDD-TRAY).
I contacted FD tech support via [email protected], and the store itself via the contact form on the website.
Thanks, I've pinged them an email via the store website. I suspect the address I emailed earlier is one that isn't monitored.
-
It seems FD have shipped my drive cage without having read my email asking about the trays. At least there's been no communication to say they've looked at it.
Have to wait and see what turns up now!
-
Out of interest which trays did you order from the spare parts shop?
A search for "tray" brings back several, many of which look the same but are different prices.
Also, which contact email are you using to communicate with them? I just replied to the order confirmation email that I had when ordering the lower cage.
-
I've just taken delivery of a Define XL R2, and I have the extra lower drive cage ordered as well. Disappointed to hear it doesn't come with trays for the drives - from the pic on the website I assumed it did.
Looking again at the spare parts site the trays are pretty cheap, but the delivery to the UK is quite high. I've emailed to ask if my order can be amended to include trays, but in case it can't - are there any other trays that would be compatible? Or is there another (UK based) supplier?
[Plugin] CA Application Auto Update
in Plugin Support
Posted
Just wanted to come and confirm that the new docker stop/start script functionality worked great.
Thanks for adding that.