cybrnook
-
Posts
613 -
Joined
-
Days Won
2
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by cybrnook
-
-
5 hours ago, Mattaton said:
Sounds good. As long as the backup is running, I'm good. It's just an issue to puzzle over. 🙂
Thanks for all the help, everyone!
Just want to throw out that I have tested with and without "root" mode, and when I schedule my cron I have tested with and without "console" mode. Both options are working for me with the .profile workaround.
I just tested at 4:25 PM EST (which is 16:25 in LuckyBackup) and it worked fine, nonroot and not in console mode:
Make sure you're not doing something silly when making the schedule like forgetting that lucky is a 24 hour clock and not a 12 hour clock. So, 5:00 PM for example is 17:00.
-
Then at this point I'd say let's wait and see what @ich777 comes back with. From my side it seems to be working, and it worked for you yesterday, so I am unsure at this point if there is something else that we are missing.
-
8 minutes ago, Mattaton said:
User: super user - crontab content #lnitial Cron luckybackup entries 0 5 * * * /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ daily-5am.profile > Iroot/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1 /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ 15 11 * * * /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ daily-5am.profile > /root/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1 end of luckybackup entries
This does not look right? Why "I"root and not /root
Iroot/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1
-
4 minutes ago, Mattaton said:
I did so and it did not run. I don't understand why since the test yesterday ran fine.
I have nuked all schedules and recreated. Cron now looks like this with the test schedule for a couple minutes ago:
User: super user - crontab content #lnitial Cron luckybackup entries 0 5 * * * /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ daily-5am.profile > Iroot/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1 /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ 15 11 * * * /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ daily-5am.profile > /root/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1 end of luckybackup entries
That looks correct, doesn't it? Should run at 5am and 11:15am according to that, right?
I think it looks fine. I just did a simple test of running all my backup jobs here in EST and it worked fine for me. @ 11:22 EST my cron'd backup job kicked off without issue.
-
6 minutes ago, Mattaton said:
11am just came and went and the schedule didn't fire the job. So, it's not the 6-hour offset issue.
I removed the schedule. did the cronIT, checked that the entry was now blank. Then I set the schedule up again with console mode enabled as it was before. cronIT and the text for the schedule looks the same. Let's hope it works this time!
Create another job in there to run in just a couple minutes, see if that works. Would verify if we're close to something or not.
-
@Mattaton when you ran the 5 minute test yesterday, where it worked, was that a newly schedule job? I am wondering if you need to perhaps remove and recreate the cron entries now that you made the TZ change?
-
2 hours ago, Mattaton said:
Update on the timezone scheduling...
I have the cron for my main profile (daily-5am) set to run at 5am, which it did NOT.
I checked the timezone and it still checks out as EST. So, we'll see if it runs at 11am and the 6-hour delay issue remains.
0 5 * * * /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ daily-5am.profile > /root/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1
Before yesterday, I had this cron job set to 0 0 * * * and it would run at 6am (6 hours later). With the timezone fix, I would think this should have run at 5am when set to 0 5 * * *. You guys see anything I'm doing wrong?
@Mattaton let's continue in the support thread.
-
19 minutes ago, ich777 said:
This should not matter since it‘s a environment variable and it is available for all users, I‘ll look into that tomorrow, it‘s getting late over here.
Schlaf gut 🙂 (Sleep well)
-
25 minutes ago, ich777 said:
Have you yet tried to create a Variable in the Docker template itself with the Key: TZ and as Value: America/New_York
This should basically do the same system wide.
That didn't work (just to calrify, the "root" user in the container is fine, it's the "luckybackup" user that is running as CET. That seems the be the main app user within the container, where cron is being used.):
-
1 minute ago, Mattaton said:
Just ran a test and it seems to be working!
Thanks for the help with this! And I would think anything in the luckybackup folder is persistent, correct?
Yes, I think so. That's where @ich777 has been pointing all users to go for persistent changes (like keys). This should be no different.
-
1
-
-
1 minute ago, Mattaton said:
Created the .profile as you described and it returned the time in EST, albeit in a different format and in 24-hour syntax.
root@d841cef0c6d7:/# date Tue 09 Jan 2024 03:28:03 PM EST root@d841cef0c6d7:/# su - luckybackup luckybackup@d841cef0c6d7:~$ date Tue Jan 9 15:28:12 EST 2024
Good! Can you setup a simple backup job to run, say in 5 min and see if it kicks off correctly?
-
1
-
-
1 minute ago, Mattaton said:
So, I can just add in a TZ var to the ENV setup and that will do it, or do I need to do the .profile avenue that @cybrnook described?
@Mattaton Try and and see if it works
Log into docker console (you will be root), and execute:
su - luckybackup touch .profile echo "export TZ=America/New_York" > .profileThen restart your container and check the "date" commands again. Then maybe test a simple scheulded backup and see if it kicks off when you want it to.
-
1
-
-
5 minutes ago, ich777 said:
Can you describe a bit further what you are trying to achieve?
You can pass over TZ as a variable to the container (which it should do by default), I tested this back with 6.10 I think and it was working fine with the correct timezone.
Depends on where you put those files, they should all go into /luckybackup in the container and not in /root (if you are running luckyBackup as root).
I have not experienced this myself as I'm not running scheduled backups, but user @Mattaton is running his system in EST timezone. When he runs a scheulded backup it's exactly 6 hours difference from when he thought it would run. In poking around I can see the "root" user in the container runs as system time zone, but when I switch to "luckybackup" that user runs is CET which is exactly 6 hours time difference. I assume if luckybackup also runs as EST instead of CST then that would fix the problem.
I found a basic fix of just creating a .profile file in luckybackup home dir and exporting TZ=America/New_York. That seems to work in my basic testing. You think that should be good enough?
Without this, this is what I see:
-
Gotta ask the master brain, @ich777, you think there is anyway to have the luckybackup user match the timezone of root, persistently? I was peeking around for a .profile file or .bashrc or something for the luckbackup user, but there is nothing in the home dir. I know docker can be destructive to changes made inside during updates and reboots.
-
1
-
-
3 minutes ago, Mattaton said:
Gotcha. I thought that may have been a problem, but with the "-" it asks for a password and I don't have a luckybackup user set up, so no password.
Is the luckybackup user just there no matter what, even with the root option set to true? If so, is there a default password?
make sure to pay attention to the spaces I have. So if you're in the container as "root" execute su(space)-(space)luckybackup and see what happens. I assume you probably did something like su- luckybackup or su -luckybackup? Needs to be su - luckybackup
-
9 minutes ago, Mattaton said:
So, since I'm running as root, do we assume that the cron job is being run by luckybackup user even though the container is set for root permissions to the file system?
Well, I guess that's not the case for me, if I run date as root and luckybackup, I still get the same EST output:
root@0e7a9b86e938:/# date
Tue 09 Jan 2024 02:39:12 PM EST
root@0e7a9b86e938:/# su luckybackup
luckybackup@0e7a9b86e938:/$ date
Tue 09 Jan 2024 02:40:27 PM ESTand if you execute "su - luckybackup" from the root user? with the "-". You have to be careful how you switch to different users. Depending on how you do it, you either bring the current user env along for the ride, or have the sytem switch to the new users env. sudo su -, su -, su all can have different outcomes.
-
On my systems I can see that "root" runs as local timezone of the container, but "luckybackup" runs as CET, which is a difference of 6 hours 🙂 So maybe just account for the 6 hour time difference when you make your cron entry. Or, we look for a way to change the timezone persistently for luckybackup user?
-
11 minutes ago, Mattaton said:
Maybe I'm doing something wrong, but when I go to the terminal for the container and run "time," I just get 0m0.000s. Ran it several times, always says the same thing. Is that supposed to show a clock time?
I am running as root user. ENV var set to true.
If I run the date command within the container, I get the correct date and time returned.
I was just coming here to say "date" I meant date...... to show the time zone. Had a brain fart.
-
On 1/4/2024 at 7:36 AM, Mattaton said:
I'm in the eastern US, EST timezone. As far as I know, my server time is set correctly, but the cron job in LB is running 6 hours after I have it set for.
I had it set for 5am, and it ran at 11am. I now have it set for midnight and it's running at 6am.
Cron jobs via User Sripts plugin run at correct times.
Not a huge deal since I can just adjust as needed, but any idea why it's off?
Just guessing right now (backup server is offline right now), but you'd probably want to do your timezone checking also from within the docker container itself, not necessarily your Unraid server, as the schedule would be from within the container, not your server. And, not sure if you're using the "root" option in the container, but maybe the luckybackup user in the container has a different timezone than root? You could just switch to each user and run the command "date" to see what each user is using.
-
Just wanted to give a shout out to @ich777 for maintaining this docker, it was JUST what I needed now that I am decommissioning a Synology in exchange for another unRAID box. Was able to get my old data copied over from the Synology to the new backup unRAID system, and then create some stored jobs to keep my main unRAID system in sync again with the already existing data. All in all it went pretty smooth.
Also, thanks to @SpencerJ for calling this out and to @spxlabs for the writeup. I used it when wrapping my head around creating remote sources / paths.
-
3
-
1
-
-
I was able to work around my issue by doing 2 x things, not sure which one was it. But first I tried in Firefox, which had no sessions cookies already, so was a fresh login. When I went to Replace Key, I had to log into my unraid account and give a fresh 2 factor code. After logging in here, I was able to see both ID's and everything went smooth from there.
-
1
-
-
Also having the same issue,
opening a support ticket now.EDIT: Marked ticket as resolved
-
8 hours ago, JorgeB said:
Yes, that can happen when there are multiple GPUs, you can also blacklist the AST driver so that it's not loaded by Unraid:
https://docs.unraid.net/unraid-os/release-notes/6.10.0#linux-kernel
Yep, this also did the trick (blacklisting ast). Let me boot into unraid while still using the onboard VGA, no external GPU required.
-
1
-
-
I've been fighting this same issue for a few days now, pulling out what little bit of hair I have left. But in my case I was able to work around it. In my case, I am doing a new Unraid build, getting ready for the 6.13 BETA to start as I want to do a massive all flash array on ZFS with bifurcated cards and ssds, so I'm building a new Threadripper based system with a 5955WX and currently an AsRock Rack WRX80D8-2T board (though I have tested a few boards with the same issue lately).
Come to find out, all the boards I have been testing with have an onboard BMC/IPMI interface with the AST2500 built in VGA. I had to plug in a standalone VGA as my VGA to HDMI adapter was seemingly not working and I needed to see what post was telling me. While display was correctly routing through my GTX 1030 until unraid started loading the drivers for the BMC. Soon after it seemed to "freeze" at "AES CTR mode by8 optimization enabled". What I am thinking may be happening is unraid loads the drivers for the onboard BMC and then routes output to that, leaving the session I am watching stale, as if the system froze. I ended up disabling onboard VGA in the bios, and what do you know, booting without issue.
Just wanted to chime in for someone else having a similar issue.
I'm unRaid old, how about a AARP badge?
in Forum Feedback
Posted · Edited by cybrnook
Still got some classics from when I first started 🙂