Jump to content

Leondre

Members
 View Profile  See their activity

  • Posts

    28

  • Joined

  • Last visited

 Content Type 

Posts posted by Leondre

    Dynamix - V6 Plugins

    in Plugin Support

    Posted · Edited by Leondre

    The dynamix ssd trim plugin causes the following to show up in the syslog when it runs. Two intel 545s (512gb) ssds are connected to a 9305-16i. 

    Feb  6 00:00:30 kernel: mpt3sas_cm0: log_info(0x31120b10): originator(PL), code(0x12), sub_code(0x0b10)
Feb  6 00:00:31 kernel: mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03)
Feb  6 00:00:31 kernel: sd 1:0:13:0: [sdo] tag#4557 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00 cmd_age=0s
Feb  6 00:00:31 kernel: sd 1:0:13:0: [sdo] tag#4557 CDB: opcode=0x85 85 06 2c 00 da 00 00 00 00 00 4f 00 c2 00 b0 00
Feb  6 00:00:31 kernel: mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03)
Feb  6 00:00:31 kernel: mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03)
Feb  6 00:00:32 kernel: sd 1:0:13:0: Power-on or device reset occurred
Feb  6 00:00:32 kernel: mpt3sas_cm0: log_info(0x31120b10): originator(PL), code(0x12), sub_code(0x0b10)
Feb  6 00:00:32 kernel: mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03)
Feb  6 00:00:32 kernel: sd 1:0:0:0: [sdb] tag#4603 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00 cmd_age=0s
Feb  6 00:00:32 kernel: sd 1:0:0:0: [sdb] tag#4603 CDB: opcode=0x85 85 06 2c 00 da 00 00 00 00 00 4f 00 c2 00 b0 00
Feb  6 00:00:33 kernel: mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03)
Feb  6 00:00:33 kernel: sd 1:0:0:0: Power-on or device reset occurred

    Executing 'fstrim -v /mnt/cache' or 'fstrim -a -v' manually or via userscripts works without any problems, so I guess I'll just do it that way.

    [Support] jj9987 - PostgreSQL

    in Docker Containers

    Posted

    On 10/1/2021 at 3:27 AM, AmokK said:

     

    Thank you for your answer, I understand now why it can't work automatically, as it is a major postgres update.

    I will stick to the 13.4 version for the moment, as the database upgrade procedure seems a little bit complicated, but I will study it thoroughly and try it later :) 

     

     

    I too use psql for nextcloud, and while I'm no db expert.. let alone psql, I just went through the process after fiddling with it for a while, only made complicated by docker really.

     

    Just spin up 2 psql containers with separate appdata dirs, original being port 5432, new one 5433.

    Mount a shared backup directory between them.

    SSH into the OG psql, run 'pg_dumpall -U postgres > /backupdir/all.sql'

    SSH into the NEW psql, recreate any users you had before (not entirely sure this needs to be done but I did), then run 'psql -U postgres -f /backupdir/all.sql'

    Kill the old container, change the new container port to whatever the old one was, 5432 in this case.

    Done

     

    I'm sure someone will tell me why this is a horrible way to do it, but hey it worked.

    • Like 2

    [Support] binhex - Jackett

    in Docker Containers

    Posted · Edited by Leondre

    Getting this error after the last update. Have tried removing and readding the container

     

    2019-03-21 18:12:14.674344 [info] System information Linux c57ea3329427 4.18.20-unRAID #1 SMP Fri Nov 23 11:38:16 PST 2018 x86_64 GNU/Linux
    2019-03-21 18:12:14.697325 [info] PUID defined as '99'
    2019-03-21 18:12:14.722696 [info] PGID defined as '100'
    2019-03-21 18:12:14.797432 [info] UMASK defined as '000'
    2019-03-21 18:12:14.822565 [info] Permissions already set for volume mappings
    2019-03-21 18:12:14.845976 [info] Starting Supervisor...
    2019-03-21 18:12:14,974 INFO Included extra file "/etc/supervisor/conf.d/jackett.conf" during parsing
    2019-03-21 18:12:14,974 INFO Set uid to user 0 succeeded
    2019-03-21 18:12:14,976 INFO supervisord started with pid 8
    2019-03-21 18:12:15,977 INFO spawned: 'jackett' with pid 43
    2019-03-21 18:12:15,978 INFO reaped unknown pid 9
    2019-03-21 18:12:15,989 DEBG 'jackett' stderr output:
    Cannot open assembly '/usr/lib/jackett/JackettConsole.exe': No such file or directory.

    2019-03-21 18:12:15,995 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22496759541632 for <Subprocess at 22496759936496 with name jackett in state STARTING> (stdout)>
    2019-03-21 18:12:15,995 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22496759539760 for <Subprocess at 22496759936496 with name jackett in state STARTING> (stderr)>
    2019-03-21 18:12:15,995 INFO exited: jackett (exit status 2; not expected)
    2019-03-21 18:12:15,995 DEBG received SIGCLD indicating a child quit
    2019-03-21 18:12:16,996 INFO spawned: 'jackett' with pid 47
    2019-03-21 18:12:17,007 DEBG 'jackett' stderr output:
    Cannot open assembly '/usr/lib/jackett/JackettConsole.exe': No such file or directory.

    [Support] binhex - DelugeVPN

    in Docker Containers

    Posted · Edited by Leondre 

    2017-03-08 12:00:32,759 DEBG 'deluge-web-script' stderr output:
[ERROR ] 12:00:32 pluginmanagerbase:146 Unable to instantiate plugin!

2017-03-08 12:00:32,761 DEBG 'deluge-web-script' stderr output:
[ERROR ] 12:00:32 pluginmanagerbase:147 Can't extract file(s) to egg cache

The following error occurred while trying to extract file(s) to the Python egg
cache:

[Errno 13] Permission denied: '/home/nobody/.cache/Python-Eggs/Label-0.2-py2.7.egg-tmp'

The Python egg cache directory is currently set to:

/home/nobody/.cache/Python-Eggs

Perhaps your account does not have write access to this directory? You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory.

    Since the last update I've been noticing this showing up in the logs. Do I need to do anything about this? As far as I can tell it seems to be working. I did try changing the directory but regardless of where it is something doesn't seem to have permissions.

    [support] limetech's docker repository

    in Docker Containers

    Posted

    When using the plex docker it often takes up to a minute for any show to start playing if it uses subtitles (also occurs during seeking). It seems like there is a massive delay before anything will start transcoding. I installed plex on a windows 10 vm and it only takes maybe 5 seconds at most for anything to start playing.

     

    Any ideas how I can solve this? I would prefer to use the docker. I'm not very linux savvy so please bear with me.

    tower-diagnostics-20160616-1912.zip

×
×
  • Create New...