BIT (root) no starting at all: Timeout() in self._get_password_from_pw_cache()

Bug #1488411 reported by Benjamin Schmid
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Back In Time
Fix Committed
Undecided
Unassigned

Bug Description

I'm on Linux Mint/Cinnamon. BIT is making me some new headache again. As regular user it won't start on the first run, but on the second start with launched background processes.

But the root launcher has no effect at all:

➜ ~ pkexec backintime-qt4

Back In Time
Version: 1.1.7.8

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
Traceback (most recent call last):
  File "/usr/share/backintime/qt4/app.py", line 1443, in <module>
    main_window = MainWindow( cfg, app_instance, qapp )
  File "/usr/share/backintime/qt4/app.py", line 421, in __init__
    hash_id = mnt.mount()
  File "/usr/share/backintime/common/mount.py", line 83, in mount
    parent = self.parent, **kwargs)
  File "/usr/share/backintime/common/encfstools.py", line 253, in __init__
    self.ssh = sshtools.SSH(*self.args, symlink = False, **self.split_kwargs('ssh'))
  File "/usr/share/backintime/common/encfstools.py", line 303, in split_kwargs
    d['password'] = self.config.get_password(parent = self.parent, profile_id = self.profile_id, mode = self.mode)
  File "/usr/share/backintime/common/config.py", line 594, in get_password
    return self.pw.get_password(parent, profile_id, mode, pw_id, only_from_keyring)
  File "/usr/share/backintime/common/password.py", line 375, in get_password
    password = self._get_password_from_pw_cache(service_name, user_name)
  File "/usr/share/backintime/common/password.py", line 412, in _get_password_from_pw_cache
    self.fifo.write('get_pw:%s/%s' %(service_name, user_name), timeout = 5)
  File "/usr/share/backintime/common/password_ipc.py", line 78, in write
    with open(self.fifo, 'w') as fifo:
  File "/usr/share/backintime/common/tools.py", line 936, in handler
    raise Timeout()
exceptions.Timeout
QObject::startTimer: QTimer can only be used with threads started with QThread
QObject::startTimer: QTimer can only be used with threads started with QThread

Revision history for this message
Germar (germar) wrote :

Sorry, I can't confirm this here in a new installed Mint/Cinnamon 17 VM. Can you please stop/kill all 'backintime.py pw-cache' instances (or reboot) and try again?

Revision history for this message
Benjamin Schmid (benbuntu) wrote :

Thank you for your support. No - reboot nor "sudo pkill -fe backintime ; sudo pkill -fe pw-cache" helps.

This is what strace says before nothing happens and a few seconds later the timeout occurs:

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 4674
stat("/usr/local/sbin/ssh-agent", 0x7ffc0c10bd40) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/ssh-agent", 0x7ffc0c10bd40) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/ssh-agent", 0x7ffc0c10bd40) = -1 ENOENT (No such file or directory)
stat("/usr/bin/ssh-agent", {st_mode=S_IFREG|S_ISGID|0755, st_size=284784, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fd1845daa10) = 4675
wait4(-1,
Back In Time
Version: 1.1.7.8

Maybe it's due to some missing/additional package? I will try to investigate further the difference compared to a fresh installed Cinnamon VM.

Revision history for this message
Germar (germar) wrote :

Just shooting into the blue, but could you please double-check your ssh private key file? If ssh-agent fails with 'No such file or directory' it could be that the path to the private key file is incorrect in BiT.

Revision history for this message
Benjamin Schmid (benbuntu) wrote :

Key is fine and there. It's a password-protected private key under root. I always had to enter my encryption key, but caching of the SSH passphrase worked.

profile1.snapshots.ssh_encfs.password.save=false
profile1.snapshots.ssh_encfs.password.use_cache=true

If i change now profile1.snapshots.ssh_encfs.password.use_cache to false, I'm able to start BiT again.

Revision history for this message
Benjamin Schmid (benbuntu) wrote :

I tried to replicate my situation in a VM. It works flawlessly there. Still trying to spot the difference.

Can you give me a hint: To which process does BiT tryint to talk to via a socket connection and runs into timeout?

Revision history for this message
Germar (germar) wrote :

That's the pw-cache process (backintime pw-cache start). They communicate through a FIFO in ~/.local/share/backintime/password_cache/FIFO

root doesn't have a password-keyring (like seahorse or kwallet). So you can't store passwords for root like it is done for normal users. That's why you've to enter it manually. The password-cache in this case caches the password only for subsequent runs so you don't have to type the password again.

Revision history for this message
Benjamin Schmid (benbuntu) wrote :

Thanks !

➜ demo.git git:(master) ✗ pgrep -fa backintime ; and pgrep -fa pw-cache
➜ demo.git git:(master) ✗ sudo -i
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
root@n179 ~# ll ~/.local/share/backintime/password_cache/
insgesamt 8,0K
prw------- 1 root root 0 Aug 21 11:00 FIFO|
-rw------- 1 root root 10 Aug 21 11:00 info
-rw------- 1 root root 5 Aug 21 11:00 PID
root@n179 ~# mv ~/.local/share/backintime/password_cache ~/.local/share/backintime/password_cache.old
root@n179 ~# exit
➜ demo.git git:(master) ✗ pkexec backintime-qt4

Works like a charm!1! Also caching the passwords on stopping & restarting again works like before!

I do have issues with BiT on a regular basis and do have to kill BiT quite often. Obviously these leftovers caused my issues.

Revision history for this message
Germar (germar) wrote :

Could you please compress the old folder (tar cvzf password_cache.tar.gz ~/.local/share/backintime/password_cache.old) and attach it (or mail it to me on germar DOT reitze HOSTED ON gmail DOT com). There is no sensitive data inside...

I'd like to track down what caused this.

Revision history for this message
Benjamin Schmid (benbuntu) wrote :

Here we go. Honestly I do not spot any difference, too

~/.l/s/b/password_cache.old# ll
insgesamt 8,0K
prw------- 1 root root 0 Aug 21 11:00 FIFO|
-rw------- 1 root root 10 Aug 21 11:00 info
-rw------- 1 root root 5 Aug 21 11:00 PID
~/.l/s/b/password_cache.old# ll ../password_cache
insgesamt 8,0K
prw------- 1 root root 0 Sep 7 11:00 FIFO|
-rw------- 1 root root 10 Sep 7 11:00 info
-rw------- 1 root root 5 Sep 7 11:00 PID

Revision history for this message
Germar (germar) wrote :
Changed in backintime:
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.