muslimsteel

Members
  • Posts

    27
  • Joined

  • Last visited

Posts posted by muslimsteel

  1. Hello, I am trying to get DNSOMatic to update using DDNSUpdater, but for whatever reason, it is giving me ERROR malformed password. I tried turning on debug logging but all that did was add the config file to the logs and then it shuts down. Am I missing something? My password is 20 characters long and only has one special character in it a "$" sign, wondering if that was an issue.

    { "provider": "dnsomatic", "host": "*", "username": "***@gmail.com", "password": "***", "ip_version": "ipv4" }

     

    I posted this originally in Discussions on the GitHub page but have not got a response there so I thought I might try here.

     

    Thanks for the help!

  2. Hello, I was going through a routine process of replacing a disk in the array with a different one of the same size, when I started the array back up after swapping the disk, my parity drive suddenly threw a bunch of errors and went into a disabled state which borked the rebuild. So right now the array is running, but is missing a disk (the one I replaced as it couldn't rebuild) and the parity is still disabled. I have put back in the disk that I had in before in hopes that it might be able to come back to normal sans parity but that did not make a difference. Attached is a system report and SMART test of the parity drive. Where do I go from here? I have the drive from before installed now, can I just some how put it back to the way it was before, just with a parity that is failed? Thanks for the help!

    hulk-diagnostics-20220828-0902.zip hulk-smart-20220828-0855.zip

  3. Thanks just to confirm are you referring to this?

    image.thumb.png.b95a136ec587e849d5f68fc285a83e6f.png

    I saw that and it said Data, RAID1: total=428.00GiB, used=398.12GiB, so with those size indicators, I thought that it was still only using the old drive as that was the size of it. In this scenario though, all three drives in there now have the same data on them (RAID1) correct? Just trying to understand the working of the cache pool better, thanks!

  4. Hello, I was working on replacing my cache drive, but I think I may have done it in an odd way. Before I started I had two 480GB SSDs in there functioning as the Cache pool. I added two 2TB NVMes to the cache pool and let it rebuild/balance. Then later I removed one SSD from the pool. I want to remove the second one as well so I was reading this from the FAQs 

     and I am unsure what cache profile my drives are in. My first instinct after reading that was transfer everything off the cache drive and then remove the second SSD just to be safe, but that would take at least a day or two to transfer everything. So my question is, how can I find out if it is ok to just pull out the second SSD? I attached diagnostics just in case. Thanks!

    hulk-diagnostics-20220729-1556.zip

  5. Hello, I have had kernel panics recently about once or twice a week. Googling suggests it could be memory issue (even though I am running ECC RAM) or could be some other issue with docker networking (but nothing has changed there). So I just wanted to post my logs to get a second opinion before doing more troubleshooting. Attached are two diagnostics pulled after the reboot, and the most recent syslog. I don't think the syslog was captured for the first kernel panic, but the most recent one on 7/9/2022 @16:06 local time should be there. Thanks in advance for the help with this! 

    All_2022-7-10-9_8_40.csv hulk-diagnostics-20220710-0917.zip hulk-diagnostics-20220706-0852.zip

  6. I am a little confused on this, as when I updated the image initially after @binhex did the first update, the only versions of Java that were included on the container were the following:

    sh-5.1# ls
    default  default-runtime  java-11-openjdk  java-17-openjdk  java-8-openjdk

    So I am not understanding why there is a variable for 16 if that is no longer there?

  7. 19 minutes ago, NLS said:

    Something not ok after the update...

     

    I am trying to start my world server and when I click ">" it takes me to Virtual Console, where I see no new entries.
    It just doesn't start it, no errors, no anything.

     

    EDIT:

    In crafty.log I see this:

    2021-09-23 22:17:00,862 - [Crafty] - CRITICAL - app.classes.minecraft_server - Minecraft server Java path does not exist...

    (Server was running fine before the update)

     

    EDIT #2:
    This is the path I have set for java (and again: was working before the update):

    /usr/lib/jvm/java-16-openjdk/bin/java

     

    EDIT #3:

    I reverted the path to a simple "java" (as it was before 1.17).
    This allows the server to start... but not really.
    It is "green" but clients cannot connect to it any more! (the world and clients are 1.17.1)

     

    I ran into this as well @NLS. It seems that they upgraded Java on the container, so now the new path is:
     

    /usr/lib/jvm/java-17-openjdk/bin/java

     

    EDIT:
    I had to change that on all my servers, and then some still wouldn't start, so I rebooted the container and all was well after that.

  8. 15 minutes ago, binhex said:

    your issue is not a bug in the release its due to you misconfiguring crafty, which sadly you cant easily correct. the setting you need to fix is in the sqlite database.

     

    you could try this:-

    1.stop container

    2. install SQLite Expert Personal

    3. point it at the crafty database file

    4. click on 'schedules' then click on menu item 'Object/'Empty Table schedules'

    5. click on file/close database shuld prompt you to save changes, say yes

    6. start crafty and cross fingers!.

    screenshot for ref on my system:-

    image.png.ab8685131cfcedfba6257be202c34385.png

    You rock, thank you that worked like a charm!

  9. 37 minutes ago, binhex said:

    click on  advanced view then 'force update'

    Thanks did that, the error seems a bit different but is still persisting where it won't start up, I am thinking that I may just blow away the DB and start over:

    2021-09-23 13:22:51,930 DEBG 'start-script' stderr output:
    Traceback (most recent call last):
    File "/opt/crafty/crafty.py", line 311, in <module>
    
    2021-09-23 13:22:51,931 DEBG 'start-script' stderr output:
    multi.reload_scheduling()
    File "/opt/crafty/app/classes/multiserv.py", line 93, in reload_scheduling
    self.reload_user_schedules()
    File "/opt/crafty/app/classes/multiserv.py", line 112, in reload_user_schedules
    helper.scheduler(task, svr_obj)
    File "/opt/crafty/app/classes/helpers.py", line 1306, in scheduler
    
    2021-09-23 13:22:51,931 DEBG 'start-script' stderr output:
    schedule.every(task.interval).monday.do(mc_server_obj.backup_server).tag('user')
    
    2021-09-23 13:22:51,932 DEBG 'start-script' stderr output:
    File "/opt/crafty/env/lib/python3.9/site-packages/schedule/__init__.py", line 322, in monday
    
    2021-09-23 13:22:51,932 DEBG 'start-script' stderr output:
    raise IntervalError('Use mondays instead of monday')
    schedule.IntervalError: Use mondays instead of monday
    
    2021-09-23 13:22:51,971 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 23132065632560 for <Subprocess at 23132065480272 with name start-script in state RUNNING> (stdout)>
    2021-09-23 13:22:51,972 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 23132065671296 for <Subprocess at 23132065480272 with name start-script in state RUNNING> (stderr)>
    2021-09-23 13:22:51,972 INFO exited: start-script (exit status 1; not expected)
    2021-09-23 13:22:51,972 DEBG received SIGCHLD indicating a child quit

     

  10. 46 minutes ago, binhex said:

    i worked around the problem for now by importing the gitlab repo and creating a sync myself using github actions, works a treat :-), let crafty dev's know this is an option, so i have built a new image and if you pull you should be up to date with latest changes to branch master.

    I am not seeing an update to the image available, it says up-to-date currently, unless I am missing something.

  11. So it seems after I finally got everything set up and went to create a schedule for backups, it borked the server. I have a feeling the answer is going to be delete the DB and start over, but wanted to confirm if there was another way. This is from the container logs:

    2021-09-18 16:41:50,537 DEBG 'start-script' stderr output:
    Traceback (most recent call last):
    File "/opt/crafty/crafty.py", line 308, in <module>
    
    2021-09-18 16:41:50,538 DEBG 'start-script' stderr output:
    multi.reload_scheduling()
    File "/opt/crafty/app/classes/multiserv.py", line 93, in reload_scheduling
    self.reload_user_schedules()
    File "/opt/crafty/app/classes/multiserv.py", line 112, in reload_user_schedules
    helper.scheduler(task, svr_obj)
    File "/opt/crafty/app/classes/helpers.py", line 1306, in scheduler
    
    2021-09-18 16:41:50,538 DEBG 'start-script' stderr output:
    schedule.every(task.interval).monday.do(mc_server_obj.backup_server).tag('user')
    File "/opt/crafty/env/lib/python3.9/site-packages/schedule/__init__.py", line 302, in monday
    raise IntervalError('Use mondays instead of monday')
    schedule.IntervalError: Use mondays instead of monday
    
    2021-09-18 16:41:50,584 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22962550325200 for <Subprocess at 22962550324528 with name start-script in state RUNNING> (stdout)>
    2021-09-18 16:41:50,584 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 22962550007648 for <Subprocess at 22962550324528 with name start-script in state RUNNING> (stderr)>
    2021-09-18 16:41:50,584 INFO exited: start-script (exit status 1; not expected)
    2021-09-18 16:41:50,585 DEBG received SIGCHLD indicating a child quit

     

    Thanks for looking.

  12. I just had this issue, took a diagnostics file right after it happened. I was working on some files in krusader when suddenly it said the directory did not exist anymore. I went up a level and that one did not exist either. Then I looked at my shares and they were gone. Googled it and came across this post. So I took some diagnostics and then rebooted. Server seems to be ok now, but just seems odd, was wondering if there was anything in the diagnostics that would suggest the problem. Thanks!

    hulk-diagnostics-20200610-2159.zip

  13. I have come across the same issue as above. I originally posted the issue in the Dynamix forum because of the errors that I saw, they looked at my diagnostics and saw the process issue that you are seeing. This is what I originally posted here:

    Quote

    Hello, I hope this is the right place to post this. I have searched and have been unable to find a solution. In the last few days I added a second cache drive, identical to the existing one. I added this to create a cache pool. Since then I noticed occasional weird messages in my email that don't seem to make sense:

    Subject is: 

    cron for user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

    and the body consists of:

    /bin/sh: fork: retry: Resource temporarily unavailable

     

    Typically I get several in a row and then they stop for 12-24 hours. If I leave them it seems to only get worse leading to the server being unresponsive twice now in the last few days. I was able to reboot it from the GUI once, but the second time I had to do a hard boot. I tried uninstalling and reinstalling the SSD Trim plugin but did not seem to make a difference. It came back up without issue and the errors seemed to be cleared, but then about 24 hours later they started happening again. Everything seems to be working ok otherwise, I am not sure what is causing this. One thought I had is that one of the cache drives is on an HBA and the other is connected directly to the motherboard, not sure if that would make a difference. I have attached the diagnostic. Let me know what you guys think, the server has been running great otherwise and I have really been enjoying UNRAID. Thanks for the support! 

    And then one of the guys there replied:

    Quote

    Hmm. your diagnostics show that you have a netdata container that is not properly reaping the finished processes

    
    201      15538  0.2  0.0  33416 22352 ?        SNl  03:01   2:23  |   |       \_ /usr/bin/python /usr/libexec/netdata/plugins.d/python.d.plugin 1
    201        300  0.0  0.0      0     0 ?        ZNs  05:34   0:00  |   |       \_ [timeout] <defunct>
    201        301  0.0  0.0      0     0 ?        ZNs  06:28   0:00  |   |       \_ [timeout] <defunct>
    201        302  0.0  0.0      0     0 ?        ZNs  04:32   0:00  |   |       \_ [timeout] <defunct>
      ... snip ...
    201      32766  0.0  0.0      0     0 ?        ZNs  09:32   0:00  |   |       \_ [timeout] <defunct>
    201      32767  0.0  0.0      0     0 ?        ZNs  08:54   0:00  |   |       \_ [timeout] <defunct>

    So your server is running out of process ids to run new processes. You should check with the support thread for the netdata container you are running

    I have attached my diagnostics if you want to take a look. Going to turn off the netdata container for now and see if I am seeing any more of these issues. Thanks in advance for the support!

    hulk-diagnostics-20200519-2143.zip

  14. Hello, I hope this is the right place to post this. I have searched and have been unable to find a solution. In the last few days I added a second cache drive, identical to the existing one. I added this to create a cache pool. Since then I noticed occasional weird messages in my email that don't seem to make sense:

    Subject is: 

    cron for user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

    and the body consists of:

    /bin/sh: fork: retry: Resource temporarily unavailable

     

    Typically I get several in a row and then they stop for 12-24 hours. If I leave them it seems to only get worse leading to the server being unresponsive twice now in the last few days. I was able to reboot it from the GUI once, but the second time I had to do a hard boot. I tried uninstalling and reinstalling the SSD Trim plugin but did not seem to make a difference. It came back up without issue and the errors seemed to be cleared, but then about 24 hours later they started happening again. Everything seems to be working ok otherwise, I am not sure what is causing this. One thought I had is that one of the cache drives is on an HBA and the other is connected directly to the motherboard, not sure if that would make a difference. I have attached the diagnostic. Let me know what you guys think, the server has been running great otherwise and I have really been enjoying UNRAID. Thanks for the support! 

    hulk-diagnostics-20200519-2143.zip