backupninja issueshttps://0xacab.org/liberate/backupninja/-/issues2021-12-22T10:22:42Zhttps://0xacab.org/liberate/backupninja/-/issues/11338PostgreSQL handler doesn't work on host installed on Debian 11 (Bullseye)2021-12-22T10:22:42ZGuillaume SubironPostgreSQL handler doesn't work on host installed on Debian 11 (Bullseye)On Debian 11 (Bullseye), postgres user is installed with nologin as shell
```
# grep postgres /etc/passwd
postgres:x:108:65534::/home/postgres:/usr/sbin/nologin
```
Which causes an error when the hander list databases :
```
# su - pos...On Debian 11 (Bullseye), postgres user is installed with nologin as shell
```
# grep postgres /etc/passwd
postgres:x:108:65534::/home/postgres:/usr/sbin/nologin
```
Which causes an error when the hander list databases :
```
# su - postgres -c 'psql -AtU postgres -c \"SELECT datname FROM pg_database WHERE NOT datistemplate\"'
This account is currently not available.
```
And, even worse, the handler continues and tries to dump databases "This", "Account", "is", "currently", etc.
```
# ls /var/backups/postgres/
account.pg_dump.gz currently.pg_dump.gz is.pg_dump.gz This.pg_dump.gz
available..pg_dump.gz globals.sql.gz not.pg_dump.gz
```
`chsh postgres -s /bin/bash` fixes the problem, but backupninja should work out of the box. I don't know yet what would be the best solution. Using `sudo -u` instead of `su -` works, but backupninja should not depends on sudo…https://0xacab.org/liberate/backupninja/-/issues/11290Database handlers produce su-related errors in logs2021-01-13T19:25:23ZJerome CharaouiDatabase handlers produce su-related errors in logsThis was initially reported in DEBBUG-879664 against the pgsql handler on the Debian BTS, but I'm also seeing the same problem with the mysql one.
Basically, when backing up multiple smallish databases, `su` is called many times in quic...This was initially reported in DEBBUG-879664 against the pgsql handler on the Debian BTS, but I'm also seeing the same problem with the mysql one.
Basically, when backing up multiple smallish databases, `su` is called many times in quick succession, leading to messages like this appearing in system logs:
```
2017-10-23T01:00:15.795982+02:00 fer systemd[1]: user@500.service: Start request repeated too quickly.
2017-10-23T01:00:15.796132+02:00 fer systemd[1]: Failed to start User Manager for UID 500.
2017-10-23T01:00:15.796271+02:00 fer systemd[1]: user@500.service: Unit entered failed state.
2017-10-23T01:00:15.796409+02:00 fer systemd[1]: user@500.service: Failed with result 'start-limit-hit'.
2017-10-23T01:00:15.796702+02:00 fer su[11455]: pam_systemd(su:session): Failed to create session: Start job for unit user@500.service failed with 'failed'
2017-10-23T01:00:21.594947+02:00 fer systemd[1]: user@500.service: Start request repeated too quickly.
2017-10-23T01:00:21.595070+02:00 fer systemd[1]: Failed to start User Manager for UID 500.
2017-10-23T01:00:21.595212+02:00 fer systemd[1]: user@500.service: Failed with result 'start-limit-hit'.
2017-10-23T01:00:21.596172+02:00 fer su[11486]: pam_systemd(su:session): Failed to create session: Start job for unit user@500.service failed with 'failed'
```https://0xacab.org/liberate/backupninja/-/issues/11270Request for support for the host variable in postgresql2018-06-29T17:59:18Zguidoguido@dis.tur.bioRequest for support for the host variable in postgresqlHi,
For 0xacab's backups we need to pass the host variable to `pg_dumpall`. Made some changes to the handler [here](https://0xacab.org/riseuplabs/backupninja/merge_requests/4/diffs). Would that change be welcome? Thanks in advance.Hi,
For 0xacab's backups we need to pass the host variable to `pg_dumpall`. Made some changes to the handler [here](https://0xacab.org/riseuplabs/backupninja/merge_requests/4/diffs). Would that change be welcome? Thanks in advance.https://0xacab.org/liberate/backupninja/-/issues/3800PostgreSQL should include DB creation as an option2020-08-14T05:52:06ZGhost UserPostgreSQL should include DB creation as an optionpg_dump has a useful command:
<pre>
-C, --create
Begin the output with a command to create the database itself and
reconnect to the created database. (With a script of this form, it
doesn't matter ...pg_dump has a useful command:
<pre>
-C, --create
Begin the output with a command to create the database itself and
reconnect to the created database. (With a script of this form, it
doesn't matter which database you connect to before running the
script.)
</pre>
Would it be possible for backupninja to include an additional option to create the database upon restore?
Kind regards,
Kellogs
*(from redmine: created on 2012-02-12)*Guillaume SubironGuillaume Subiron