PostgreSQL Database directory appears to contain a database; Skipping initialization
2024-10-23 18:52:32.951 CST [8] LOG: starting PostgreSQL 15.8 (Debian 15.8-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2024-10-23 18:52:32.952 CST [8] LOG: listening on IPv4 address “0.0.0.0”, port 5432
2024-10-23 18:52:32.952 CST [8] LOG: listening on IPv6 address “::”, port 5432
2024-10-23 18:52:32.955 CST [8] LOG: listening on Unix socket “/var/run/postgresql/.s.PGSQL.5432”
2024-10-23 18:52:32.961 CST [31] LOG: database system was interrupted; last known up at 2024-10-23 18:42:56 CST
2024-10-23 18:52:33.071 CST [31] LOG: database system was not properly shut down; automatic recovery in progress
2024-10-23 18:52:33.073 CST [31] LOG: redo starts at 0/2B0FC18
2024-10-23 18:52:33.073 CST [31] LOG: invalid record length at 0/2B0FD00: wanted 24, got 0
2024-10-23 18:52:33.073 CST [31] LOG: redo done at 0/2B0FCC8 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2024-10-23 18:52:33.079 CST [29] LOG: checkpoint starting: end-of-recovery immediate wait
2024-10-23 18:52:33.087 CST [29] LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.003 s, sync=0.002 s, total=0.010 s; sync files=3, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2024-10-23 18:52:33.091 CST [8] LOG: database system is ready to accept connections
127.0.0.1:5432 - accepting connections
Building prefix dict from the default dictionary …
DEBUG:jieba:Building prefix dict from the default dictionary …
Dumping model to file cache /tmp/jieba.cache
DEBUG:jieba:Dumping model to file cache /tmp/jieba.cache
Loading model cost 0.644 seconds.
DEBUG:jieba:Loading model cost 0.644 seconds.
Prefix dict has been built successfully.
DEBUG:jieba:Prefix dict has been built successfully.
Operations to perform:
Apply all migrations: application, contenttypes, dataset, django_apscheduler, django_celery_beat, embedding, function_lib, setting, users
Running migrations:
No migrations to apply.
Your models in app(s): ‘application’, ‘function_lib’ have changes that are not yet reflected in a migration, and so won’t be applied.
Run ‘manage.py makemigrations’ to make new migrations, and then re-run ‘manage.py migrate’ to apply them.
- Start Celery as Distributed Task Queue: Celery
- Start Gunicorn WSGI HTTP Server
- Start Gunicorn Local Model WSGI HTTP Server
2024-10-23 18:52:52 Check service status: celery_default → running at 42
2024-10-23 18:52:53 Check service status: gunicorn → running at 43
2024-10-23 18:52:54 Check service status: local_model → running at 44
2024-10-23 18:53:26 Check service status: celery_default → running at 42
2024-10-23 18:54:44 Check service status: gunicorn → running at 43
2024-10-23 18:54:51 Check service status: local_model → running at 44
2024-10-23 18:55:47 Check service status: celery_default → running at 42
2024-10-23 18:56:29 Check service status: gunicorn → running at 43
2024-10-23 18:56:36 Check service status: local_model → running at 44
2024-10-23 18:57:10 Check service status: celery_default → running at 42
2024-10-23 18:57:12 Check service status: gunicorn → running at 43
2024-10-23 18:57:16 Check service status: local_model → running at 44
2024-10-23 18:57:49 Check service status: celery_default → running at 42
2024-10-23 18:58:26 Check service status: gunicorn → running at 43
2024-10-23 18:58:27 Check service status: local_model → running at 44
2024-10-23 18:57:42.952 CST [29] LOG: checkpoint starting: time
2024-10-23 18:58:26.961 CST [29] LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=18.977 s, sync=1.025 s, total=52.008 s; sync files=2, longest=0.988 s, average=0.498 s; distance=6 kB, estimate=6 kB
