EDIT:

changed question title - before it was about incomplete startup package in Postgres but Craig found out it is not db issue

i have django app and setup script for it. Among others script ensures that postgresql is installed and perform manage.py syncdb.

Recently i noticed some issues with syncdb - it hangs at Creating table xxxxxx.... I aborted whole task and went on and database seemed to work (even South worked), i wasn't asked to create root account though. So it seems as it creates tables and then hangs on something, or doesnt start something. I resolved to solve it once and for all and in postgresql log i found above mentioned comunicate:

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

I reinstalled postgresql (im running ubuntu 13.10) but it didn't solve the problem. Then i thought it might be something related to app for which table was created, but taking this app out proved it was unrelated. So if not postgresql installation and not django app what might it be ?

Maybe i messed something with postgresql installation ? I did:

apt-get install postgresql postgresql-contrib

and then created cluster with:

pg_createcluster 9.1 main

and thats about it.

It's been a while since i last installed postgresql so maybe i missed something obvious though i do not know what.
I read some about this issue, it is supposedly related to uncomplated handshake or something like that, db and app ar on the same machine though.

I use django version 1.5 and postgresql 9.1 on ubuntu 13.10 (as mentioned)

Any pointer will be greatly appreciated.
TIA

Output from 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)

Well, that's kinda embarassing though i figured i will post a solution (maybe someone will have similar problem).

In truth everything went fine with syncdb and all.
The thing is i used it from my setup script (bash) from which i displayed my own output regarding installation process. For consistency i redirected most of the output of used commands to /dev/null.

In case of syncdb i decided to redirect only stderr: python manage.py syncdb 2> /dev/null
As it happens it prevented 'create superuser' prompt from displaying, so process was waiting for user input (yes or no in case of first one here).

There are some interesting catches here though, when i discovered the cause i started to try other possibilities and got interesting results:

• redirecting stdout: python manage.py syncdb > /dev/null
  • nothing displayed (except for depreciation warning which is quite ok since it should go through stderr)
  • superuser prompt not displayed
  • after blind-typing answers for first 3 prompts (there are 5: do you want creating su, login, email, pass, repeat pass) password prompts displayed normally
• redirecting stderr: python manage.py syncdb 2> /dev/null (as stated above)
  • normal display
  • superuser prompt not displayed (sic!)
  • after blind-typing answers for first 3 prompts password prompts displayed normally (sic!)

It is quite interesting since it indicates that password prompt is somehow immune to redirections for one and second, the rest of prompts do not display if there is any redirection at all! (regardless if it was stdout and stderr)

For additional test i redirected all: python manage.py syncdb &> /dev/null and i got no display at all, but still after groping for first three prompts the passwords prompt showed up.

My problem is solved though i find it peculiar how bash redirection works with this output. AFAIK create_superuser uses something called getpass which messes with streams so i guess it is clear enough.
Im strugling to understand mechanism behind dissapearing of first three prompts though. If anyone know anything about it i would be glad to read about it.