Posts made by eyecreate

I decided to take some effort upon myself to see if I could package PhotoPrism. I've got a version I've uploaded to Cloudron gitlab that seems good enough to use right now. Some notes:

• The software expects either MariaDB or Sqlite. I tried hooking up to MySql, but there were syntax issues. The current config uses sqlite, but can be changed to PGSQL once they implement that into PhotoPrism.
• PhotoPrism needed a newer go than was in the base cloudron image, so I found it easiest to remove the old go version and inplace put the newer version. This can be removed once base image is updated.
• To make things easier, I did use the precompiled tensorflow from PhotoPrism instead of compiling myself. The version I included requires AVX2 (https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2)
• There might be a better way to handle the env vars than I did, but it works for now.

Hopefully this can be useful to someone wanting this software now or to help make something more official.

https://git.cloudron.io/eyecreate/photoprism

@girish I checked, and there is nothing set there, so it's what the ISP is providing.

@girish Glad you found a source and workaround. I wonder if the ISP or I have a custom DNS for the network causing that issue.

After changing the update schedule, updates are still failing without manual repair/retry.

@girish I have changed the update schedule and will get back with you if I notice nothing has changed.

For a few months, I've had issue with all my apps failing to auto-update. I usually get a message like this:

Docker Error: (HTTP code 404) no such container - No such image: cloudron/com.gitlab.cloudronapp:20220504-210413-802d48119

If I go to the repair tab, I can manually trigger it to succeed on each step of update and configure, but it seems to be unable to succeed itself.

Any idea on why this is happening?

I'm interested in using this. What is currently preventing this from being on the app store?

I don't have any ipv6 only clients, but I really would like to support the sites on my cloudron being accessed over ipv6 seamlessly.

It seems that switching the backup format from rsync to tgz has allowed the backup to complete again.

@girish This happened on 6.1 and I updated to 6.2 to see if it changed anything.(it didn't)

What I see doesn't initially seem to be related to that issue, but that is based on me not finding anything like that so far in the backup logs.

What is the set value for timing out a backup process?
Could it be running out of memory?
What would cause the backup process to not move on to another item?

I've attached below edited logs from the backup process starting with last found upload messages and ending with last lines of log.

2021-03-16T08:05:53.288Z box:backups Uploaded postgresqldump

2021-03-16T08:06:05.182Z box:shell backup-snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb (stdout): 2021-03-16T08:06:05.181Z box:backupupload process: rss: 377643008 heapTotal: 38162432 heapUsed: 31268320 external: 201905702
2021-03-16T08:06:05.182Z box:backupupload v8 heap : used 31272552 total: 38162432 max: 2197815296

2021-03-16T08:06:10.390Z box:shell backup-snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb (stdout): 2021-03-16T08:06:10.390Z box:storage/s3 Uploaded snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb/data/<user>/uploads/e1af8eccb773d34b10671a3bc5ae8462/0000000010240000-0000000014948188 with partSize 33554432: {"ETag":"\"47baf95e2236fd790d11da409611c1f6\"","Location":"http://<ip>:9000/<bucket>/snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb/data/<user>/uploads/e1af8eccb773d34b10671a3bc5ae8462/0000000010240000-0000000014948188","key":"snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb/data/<user>/uploads/e1af8eccb773d34b10671a3bc5ae8462/0000000010240000-0000000014948188","Key":"snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb/data/<user>/uploads/e1af8eccb773d34b10671a3bc5ae8462/0000000010240000-0000000014948188","Bucket":"<bucket>"}

2021-03-16T08:06:10.391Z box:shell backup-snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb (stdout): 2021-03-16T08:06:10.390Z box:backups Uploaded data/<user>/uploads/e1af8eccb773d34b10671a3bc5ae8462/0000000010240000-0000000014948188

2021-03-16T08:06:35.183Z box:shell backup-snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb (stdout): 2021-03-16T08:06:35.182Z box:backupupload process: rss: 377774080 heapTotal: 38162432 heapUsed: 31339352 external: 201906008
2021-03-16T08:06:35.182Z box:backupupload v8 heap : used 31339576 total: 38162432 max: 2197815296

end

2021-03-17T01:41:06.599Z box:shell backup-snapshot/app_d32f7472-a8f5-4909-b190-af5e3457aecb (stdout): 2021-03-17T01:41:06.599Z box:backupupload process: rss: 378445824 heapTotal: 38162432 heapUsed: 32285704 external: 201905090
2021-03-17T01:41:06.599Z box:backupupload v8 heap : used 32285944 total: 38162432 max: 2197815296

@nebulon Adding memory didn't do anything, but taking your direction to erase database ended up working out.

Note that /var/lib/.initialized didn't exist and was in the graphite directory. Also, I had to manually stop and start the container and execute the command right away or docker wouldn't let me do anything because the container was in the process of restarting/starting.

My backups in the past week have been unable to fully complete. The Nextcloud app backup process always gets stuck. Did I just reach a resource limit(ex. it was taking close to too long before and more data added recently put it into timeout territory)? What can I configure to fix this? I don't see any errors in cloudron, but the minio backup server on same network shows this:

Error: read tcp <ip>:9000-><ip>:35152: read: connection reset by peer
       4: github.com/minio/minio@/cmd/api-errors.go:1880:cmd.toAPIErrorCode()
       3: github.com/minio/minio@/cmd/api-errors.go:1905:cmd.toAPIError()
       2: github.com/minio/minio@/cmd/object-handlers.go:2246:cmd.objectAPIHandlers.PutObjectPartHandler()
       1: net/http/server.go:2036:http.HandlerFunc.ServeHTTP()

On my cloudron instance, I can't see any disk stats because graphite is stuck starting. There seems to be a migration issue or something.

Mar 14 17:34:59 Apply all migrations: account, admin, auth, contenttypes, dashboard, events, sessions, tagging, tags, url_shortener
Mar 14 17:34:59 Running migrations:
Mar 14 17:34:59 Traceback (most recent call last):
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 82, in _execute
Mar 14 17:34:59 return self.cursor.execute(sql)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 381, in execute
Mar 14 17:34:59 return Database.Cursor.execute(self, query)
Mar 14 17:34:59 sqlite3.OperationalError: table "account_mygraph" already exists
Mar 14 17:34:59 The above exception was the direct cause of the following exception:
Mar 14 17:34:59 Traceback (most recent call last):
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/bin/django-admin.py", line 5, in <module>
Mar 14 17:34:59 management.execute_from_command_line()
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
Mar 14 17:34:59 utility.execute()
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 375, in execute
Mar 14 17:34:59 self.fetch_command(subcommand).run_from_argv(self.argv)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 323, in run_from_argv
Mar 14 17:34:59 self.execute(*args, **cmd_options)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 364, in execute
Mar 14 17:34:59 output = self.handle(*args, **options)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 83, in wrapped
Mar 14 17:34:59 res = handle_func(*args, **kwargs)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/core/management/commands/migrate.py", line 232, in handle
Mar 14 17:34:59 post_migrate_state = executor.migrate(
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 117, in migrate
Mar 14 17:34:59 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
Mar 14 17:34:59 state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 245, in apply_migration
Mar 14 17:34:59 state = migration.apply(state, schema_editor)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/migrations/migration.py", line 124, in apply
Mar 14 17:34:59 operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/migrations/operations/models.py", line 92, in database_forwards
Mar 14 17:34:59 schema_editor.create_model(model)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/base/schema.py", line 307, in create_model
Mar 14 17:34:59 self.execute(sql, params or None)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/base/schema.py", line 137, in execute
Mar 14 17:34:59 cursor.execute(sql, params)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute
Mar 14 17:34:59 return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers
Mar 14 17:34:59 return executor(sql, params, many, context)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute
Mar 14 17:34:59 return self.cursor.execute(sql, params)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__
Mar 14 17:34:59 raise dj_exc_value.with_traceback(traceback) from exc_value
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 82, in _execute
Mar 14 17:34:59 return self.cursor.execute(sql)
Mar 14 17:34:59 File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 381, in execute
Mar 14 17:34:59 return Database.Cursor.execute(self, query)
Mar 14 17:34:59 django.db.utils.OperationalError: table "account_mygraph" already exists
Mar 14 17:34:59 Applying account.0001_initial...
Mar 14 17:35:52 Graphite already initialized
Mar 14 17:35:52 Operations to perform:
Mar 14 17:35:52 Apply all migrations: account, admin, auth, contenttypes, dashboard, events, sessions, tagging, tags, url_shortener
Mar 14 17:35:52 Running migrations:
Mar 14 17:35:52 Traceback (most recent call last):
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 82, in _execute
Mar 14 17:35:52 return self.cursor.execute(sql)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 381, in execute
Mar 14 17:35:52 return Database.Cursor.execute(self, query)
Mar 14 17:35:52 sqlite3.OperationalError: table "account_mygraph" already exists
Mar 14 17:35:52 The above exception was the direct cause of the following exception:
Mar 14 17:35:52 Traceback (most recent call last):
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/bin/django-admin.py", line 5, in <module>
Mar 14 17:35:52 management.execute_from_command_line()
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
Mar 14 17:35:52 utility.execute()
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 375, in execute
Mar 14 17:35:52 self.fetch_command(subcommand).run_from_argv(self.argv)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 323, in run_from_argv
Mar 14 17:35:52 self.execute(*args, **cmd_options)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 364, in execute
Mar 14 17:35:52 output = self.handle(*args, **options)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 83, in wrapped
Mar 14 17:35:52 res = handle_func(*args, **kwargs)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/core/management/commands/migrate.py", line 232, in handle
Mar 14 17:35:52 post_migrate_state = executor.migrate(
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 117, in migrate
Mar 14 17:35:52 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
Mar 14 17:35:52 state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 245, in apply_migration
Mar 14 17:35:52 state = migration.apply(state, schema_editor)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/migrations/migration.py", line 124, in apply
Mar 14 17:35:52 operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/migrations/operations/models.py", line 92, in database_forwards
Mar 14 17:35:52 schema_editor.create_model(model)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/base/schema.py", line 307, in create_model
Mar 14 17:35:52 self.execute(sql, params or None)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/base/schema.py", line 137, in execute
Mar 14 17:35:52 cursor.execute(sql, params)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute
Mar 14 17:35:52 return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers
Mar 14 17:35:52 return executor(sql, params, many, context)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute
Mar 14 17:35:52 return self.cursor.execute(sql, params)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__
Mar 14 17:35:52 raise dj_exc_value.with_traceback(traceback) from exc_value
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 82, in _execute
Mar 14 17:35:52 return self.cursor.execute(sql)
Mar 14 17:35:52 File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 381, in execute
Mar 14 17:35:52 return Database.Cursor.execute(self, query)
Mar 14 17:35:52 django.db.utils.OperationalError: table "account_mygraph" already exists
Mar 14 17:35:52 Applying account.0001_initial...

Is there a way I can correct this in the filesystem or is a patch needed?

Now with Docker this year mentioning no long term storage of docker images for free accounts, this will be even more valuable to have in gitlab.

@murgero haven't tested extensively, but cloudron supports sftp access for all containers now.

I've made a quick cloudron build here as a merge of River and Emby repos.
https://git.cloudron.io/eyecreate/jellyfin-app