Errors after upgrading

postgresql
ucs-4-2
software-monitor
pkgdb

#1

Hi I’ve this error finished upgrading:

Elaborazione dei trigger per python-support (1.0.15.18.201403132013)...
Traceback (most recent call last):
  File "/usr/sbin/univention-pkgdb-scan", line 37, in <module>
    univention.pkgdb.main()
  File "/usr/lib/pymodules/python2.7/univention/pkgdb.py", line 578, in main
    connection = open_database_connection(config_registry, pkgdbu=False)
  File "/usr/lib/pymodules/python2.7/univention/pkgdb.py", line 560, in open_database_connection
    connection = pgdb.connect(database=connectstring)
  File "/usr/lib/python2.7/dist-packages/pgdb.py", line 482, in connect
    dbtty, dbuser, dbpasswd)
pg.InternalError: could not connect to server: Connection refused
        Is the server running on host "ucs-8023.cdlmvenezia.intranet" (172.16.6.55) and accepting
        TCP/IP connections on port 5432?

Can I fix?


#2

Hi Andrea,

The upgrade itself should be fine, don’t worry.

univention-pkgdb-scan is executed after or right at the end of the upgrade to scan and submit the current package status to “ucs-8023.cdlmvenezia.intranet (172.16.6.55)”. This is because the App “Software installation monitor” (the internal name is pkgdb) is or was installed on this server. However, the PostgreSQL database that powers the “Software installation monitor” is not reachable. That’s the error.

So please check:

  • is the App “Software installation monitor” still installed on that server?
    • if not, but you want it to, re-install it
    • if not, and you want to leave it that way, you will need to remove the DNS SRV entry that starts with "_pkgdb"
    • if yes, then check if the service is actually running: service postgresql status

#3

Hi,
Yes I’ve Software installation monitor installed

● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: active (exited) since mer 2017-10-25 20:43:49 CEST; 1 weeks 0 days ago
Main PID: 2949 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/postgresql.service

ott 25 20:43:49 ucs-8023 systemd[1]: Started PostgreSQL RDBMS.


#4

Hi Andreaussi,

from the output, it tells that the PostgreSQL service is running. But it seems there is a connection problem.

  1. Enable the service so that it comes automatically on when the Server restarts
root@ucsMaster1:~# systemctl enable postgresql
Synchronizing state for postgresql.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d postgresql defaults
Executing /usr/sbin/update-rc.d postgresql enable
root@ucsMaster1:~# 
  1. Secondly check if the ports are open or it it is listening on the right port:
root@ucsMaster1:~# netstat -plnt | grep postgres
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      23636/postgres  
tcp6       0      0 :::5432                 :::*                    LISTEN      23636/postgres  
root@ucsMaster1:~# 

If it is not listening, then Stop and restart the service.

root@ucsMaster1:~# systemctl stop postgresql
root@ucsMaster1:~# systemctl start postgresql
root@ucsMaster1:~# systemctl status postgresql

Step 1 and 2 should be performed on the Server where postgresql is installed. If it is installed on a different system, then proceed to step 3

To solve the connection Problem,

  1. Check if the Server is reachable with Ping, and if the Hostname is resolvable

    root@ucsBackup1:~# ping -c2 ucsMaster1.testing.intranet
    PING ucsMaster1.testing.intranet (10.200.6.2) 56(84) bytes of data.
    64 bytes from ucsMaster1.testing.intranet (10.200.6.2): icmp_seq=1 ttl=64 time=0.641 ms
    64 bytes from ucsMaster1.testing.intranet (10.200.6.2): icmp_seq=2 ttl=64 time=0.744 ms
    
    --- ucsMaster1.testing.intranet ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1010ms
    rtt min/avg/max/mdev = 0.641/0.692/0.744/0.057 ms
    root@ucsBackup1:~# 
    
    root@ucsBackup1:~# nslookup ucsMaster1.testing.intranet
    Server:		10.200.6.3
    Address:	10.200.6.3#53
    
    Name:	ucsMaster1.testing.intranet
    Address: 10.200.6.2
    

You can also tale a look into the log file.

less /var/log/postgresql/postgresql-9.4-main.log

Regards

Anna Takang


#5

Hi, this is output:

systemctl enable postgresql
Synchronizing state for postgresql.service with sysvinit using update-rc.d…
Executing /usr/sbin/update-rc.d postgresql defaults
insserv: warning: script ‘K01univention-system-setup-boot’ missing LSB tags and overrides
insserv: warning: script ‘K01tftpd-hpa’ missing LSB tags and overrides
insserv: warning: script ‘tftpd-hpa’ missing LSB tags and overrides
insserv: warning: script ‘univention-system-setup-boot’ missing LSB tags and overrides
insserv: warning: script ‘univention-system-setup-boot-prepare’ missing LSB tags and overrides
Executing /usr/sbin/update-rc.d postgresql enable
insserv: warning: script ‘K01univention-system-setup-boot’ missing LSB tags and overrides
insserv: warning: script ‘K01tftpd-hpa’ missing LSB tags and overrides
insserv: warning: script ‘tftpd-hpa’ missing LSB tags and overrides
insserv: warning: script ‘univention-system-setup-boot’ missing LSB tags and overrides
insserv: warning: script ‘univention-system-setup-boot-prepare’ missing LSB tags and overrides
root@ucs-8023:~# netstat -plnt | grep postgres
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 18437/postgres
tcp 0 0 127.0.0.1:5434 0.0.0.0:* LISTEN 18452/postgres
tcp6 0 0 :::5432 :::* LISTEN 18437/postgres
tcp6 0 0 ::1:5434 :::* LISTEN 18452/postgres
root@ucs-8023:~# ping -c2 ucs-8023.domain.intranet
PING ucs-8023.domain.intranet (172.16.6.55) 56(84) bytes of data.
64 bytes from ucs-8023.domain.intranet (172.16.6.55): icmp_seq=1 ttl=64 time=0.051 ms
64 bytes from ucs-8023.domain.intranet (172.16.6.55): icmp_seq=2 ttl=64 time=0.037 ms

— ucs-8023.cdlmvenezia.intranet ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1026ms
rtt min/avg/max/mdev = 0.037/0.044/0.051/0.007 ms
root@ucs-8023:~# nslookup ucs-8023.domain.intranet
Server: 172.16.6.55
Address: 172.16.6.55#53

Name: ucs-8023.domain.intranet
Address: 172.16.6.55


#6

Hi andreaussi,

the results look good. The Postgresql service is up and running. You did not post the outcome of

less /var/log/postgresql/postgresql-9.4-main.log

Regards

Anna Takang


#7

2017-11-21 11:20:46 CET [1934-2] LOG: verranno utilizzate statistiche vecchie invece di quelle correnti perché il processo di raccolta statistiche non risponde
2017-11-23 07:52:38 CET [1869-2] LOG: richiesta di arresto fast ricevuta
2017-11-23 07:52:38 CET [1869-3] LOG: interruzione di tutte le transazioni attive
2017-11-23 07:52:38 CET [1934-3] LOG: arresto dell’esecutore di autovacuum
2017-11-23 07:52:38 CET [1931-1] LOG: arresto in corso
2017-11-23 07:52:39 CET [1931-2] LOG: il database è stato arrestato
2017-11-23 08:54:46 CET [2016-1] [sconosciuto]@[sconosciuto] LOG: pacchetto di avvio incompleto
2017-11-23 08:54:46 CET [2015-1] LOG: il database è stato arrestato alle 2017-11-23 07:52:39 CET
2017-11-23 08:54:47 CET [2017-1] postgres@postgres FATALE: il database si sta avviando
2017-11-23 08:54:48 CET [2029-1] postgres@postgres FATALE: il database si sta avviando
2017-11-23 08:54:48 CET [2034-1] postgres@postgres FATALE: il database si sta avviando
2017-11-23 08:54:48 CET [2015-2] LOG: le protezioni di wraparound dei membri MultiXact ora sono abilitate
2017-11-23 08:54:48 CET [1947-1] LOG: il database è pronto ad accettare connessioni
2017-11-23 08:54:48 CET [2134-1] LOG: esecutore di autovacuum avviato


#8

Good Morning andreaussi,

the message is not in English. Please can you translate it to English and send to us?

Regards
Anna Takang


#9

Hi, i’ve look that I’ve 2 postgresql version: 9.1 and 9.4
on postgresql-9.1-main.log:
2017-11-27 09:59:02 CET LOG: pam_authenticate failed: Autentication failed
2017-11-27 09:59:02 CET FATALE: PAM failed user "ucs-7758$

postgresql-9.4-main.log it’s empty now


#10

Good Afternoon andreaussi

this error message occurs when the machine’s password is changed i.e either the contents of the /etc/machine.secret file is changed, or a new password is entered in the UMC. The postgresql cannot identify the machine, as a result authentication failure.

The best way to solve this problem is to copy the current machine secret in the /etc/machine.secret file of your machine, and paste it in the UMC module Computers.

cat /etc/machine.secret

Select the computer in question, in your case, ucs-7758, under Advanced settings -> Account paste/enter the copied password in the Password field, as shown below

  • Don’t forget to save

Regards
Anna Takang.