编辑：

Question

编辑：

更改了问题标题 - 在关于Postgres的不完整启动包之前，Craig发现它不是数据库问题

我有django应用程序和安装脚本。其中脚本确保安装了postgresql并执行manage.py syncdb。

最近我注意到syncdb的一些问题 - 它挂起Creating table xxxxxx.... 我中止了整个任务并继续，数据库似乎工作（甚至南工作），但我没有被要求创建root帐户。所以它似乎创建表然后挂起的东西，或者没有开始的东西。我决定一劳永逸地解决它，并在postgresql日志中找到上面提到的comunicate：

LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  incomplete startup packet

我重新安装了postgresql（即运行ubuntu 13.10），但它没有解决问题。然后我认为它可能是与创建表的应用程序相关的东西，但是取出这个应用证明它是无关的。那么如果没有postgresql安装而不是django app会是什么呢？

也许我搞错了postgresql的安装？我做了：

apt-get install postgresql postgresql-contrib

然后用：

创建集群

pg_createcluster 9.1 main

那就是它。

自从我上次安装postgresql以来已经有一段时间了，所以也许我错过了一些明显的东西，虽然我不知道是什么。
我读了一些关于这个问题的文章，它应该与未经编译的握手有关，或类似于同一机器上的db和app ar。

我在ubuntu 13.10上使用django 1.5和postgresql 9.1（如上所述）

非常感谢任何指针 TIA

SELECT * FROM pg_stat_activity;

的输出

 datid | datname  | procpid | usesysid | usename  | application_name | client_addr | client_hostname | client_port |         backend_start         |          xact_start           |          query_start          | waiting |          current_query          
-------+----------+---------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------------------
 23255 | imris    |   18330 |    23254 | imris    |                  |             |                 |          -1 | 2014-08-20 15:43:19.38489+02  |                               | 2014-08-20 15:43:20.379704+02 | f       | <IDLE>
 11953 | postgres |   18342 |       10 | postgres | psql             |             |                 |          -1 | 2014-08-20 15:43:25.240481+02 | 2014-08-20 15:43:30.365372+02 | 2014-08-20 15:43:30.365372+02 | f       | SELECT * FROM pg_stat_activity;
(2 rows)

Answer 1

嗯，虽然我认为我会发布一个解决方案（也许有人会遇到类似的问题），但有点尴尬。

事实上，syncdb和所有内容一切顺利。
事情是我从我的安装脚本（bash）中使用它，我从中显示了我自己关于安装过程的输出。为了保持一致性，我将使用过的命令的大部分输出重定向到/ dev / null。

在syncdb的情况下，我决定仅重定向stderr：python manage.py syncdb 2> /dev/null
因为它发生了阻止＆＃39;创建超级用户＆＃39;显示提示，因此进程正在等待用户输入（如果是第一个，则为是或否）。

虽然有一些有趣的捕获，当我发现原因时，我开始尝试其他可能性并得到有趣的结果：

重定向标准输出：python manage.py syncdb > /dev/null
- 没有显示任何内容（折旧警告除外，因为它应该通过stderr而非常好）
- 未显示超级用户提示
- 盲目输入前三个提示的答案（有5个：你想创建su，登录，发送电子邮件，传递，重复传递）密码提示正常显示
重定向 stderr ：python manage.py syncdb 2> /dev/null（如上所述）
- 正常显示
- 超级用户提示未显示（sic！）
- 盲目输入前3个答案提示密码提示正常显示（sic！）

这很有意思，因为它表明密码提示在某种程度上不受重定向的影响，如果有任何重定向，其余的提示都不会显示！（无论是stdout还是stderr）

对于其他测试，我重定向所有：python manage.py syncdb &> /dev/null并且我根本没有显示，但仍然在摸索前三个提示后出现密码提示。

虽然我发现bash重定向如何与此输出一起工作，但我的问题已经解决了。 AFAIK create_superuser使用名为getpass的东西，它与流混淆，所以我想它已经足够清楚了。
尽管如此，我还是要了解消除前三个提示的机制。如果有人知道任何事情，我会很高兴看到它。

Django manage.py syncdb unfinishing

编辑：

1 个答案: