Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"When drive get connected" apparently not working. How can I debug it? #605

Closed
rdarioc opened this issue Jul 27, 2016 · 12 comments
Closed
Milestone

Comments

@rdarioc
Copy link

rdarioc commented Jul 27, 2016

I am running Lubuntu 14.04 with the latest release of BIT.

My backup USB hard-drive is always connected. I shut down the PC at night and turn it on in the morning.

BIT is not starting to do its daily back-up. Where should I look to find out why it is not working?

Thank you in advance for your kind reply.

Rosario

@Germar
Copy link
Member

Germar commented Jul 27, 2016

The schedule When drive get connected only start a new snapshot when a drive gets connected 😉
So if your external drive is always connected it won't work with this schedule. Please choose Repeatedly (anacron) schedule instead.

@Germar Germar closed this as completed Jul 27, 2016
@rdarioc
Copy link
Author

rdarioc commented Jul 27, 2016

Well, I understand the semantic, but the issue is the following:

  1. I tried to do as you said on another PC running Ubuntu 16.04 and, as
    soon as I plugged in the backup usb drive, I got a notification from Unity
    saying that BIT was not able to find the snapshot directory;
  2. I therefore ran BIT GUI and simply clicking on make snapshot now, it
    worked without further intervention.
  3. So, again, is there any log i can look at to be more helpful in
    debugging this issue?

From another point of view, I don't feel comfortable in replacing "when
drive get connected" with "Repeatedly (anacron)" because, here is the
question, what happens if the drive is not connected? The mount point is
still there, is it possible that BIT will try to backup on the local hard
drive or will it fail with a similar diagnostic as per above step #1 ?

Thank you in advance for your support, please let me know how can I be of
further support in finding out what goes wrong on my side.

Best

Rosario

On 27 July 2016 at 15:16, Germar Reitze notifications@github.com wrote:

The schedule When drive get connected only start a new snapshot when a
drive gets connected 😉
So if your external drive is always connected it won't work with this
schedule. Please choose 'Repeatedly (anacron)` schedule instead.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#605 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEWgRpjsYNx8f0e9ISOGp03leWWOXwt0ks5qZ1ovgaJpZM4JV5KN
.

R.D. Contarino rdcontarino@gmail.com
skype: rdarioc

@Germar
Copy link
Member

Germar commented Jul 27, 2016

If BIT is not able to find the snapshot directory it will retry for 30sec to find it. With When drive get connected schedule it can happen that BIT is faster than the automatic mount of the drive is. Or, if this happens all the time, you have to make sure that the drive is mounted automatically when it gets connected. KDE for example doesn't mount them automatically by default.

Logs are written into /var/log/syslog. If you run backintime-qt4 --debug from Terminal and open/close Settings BIT will automatically add --debug to the schedules, too. So you'll get more infos in syslog.

If the drive is not connected BIT won't find the snapshot folder and so it will retry for 30sec and fail to create a new snapshot. With Repeatedly schedule it will retry after 15min (or 1h if you set the delay to weeks or month).

@Germar Germar reopened this Jul 27, 2016
@rdarioc
Copy link
Author

rdarioc commented Jul 28, 2016

Thank you very much for your detailed explanation. I will further
investigate and let you know if the problem persist.

Have a great day
Rosario

On 27 July 2016 at 22:38, Germar Reitze notifications@github.com wrote:

If BIT is not able to find the snapshot directory it will retry for 30sec
to find it. With When drive get connected schedule it can happen that BIT
is faster than the automatic mount of the drive is. Or, if this happens all
the time, you have to make sure that the drive is mounted automatically
when it gets connected. KDE for example doesn't mount them automatically by
default.

Logs are written into /var/log/syslog. If you run backintime-qt4 --debug
from Terminal and open/close Settings BIT will automatically add --debug
to the schedules, too. So you'll get more infos in syslog.

If the drive is not connected BIT won't find the snapshot folder and so it
will retry for 30sec and fail to create a new snapshot. With Repeatedly
schedule it will retry after 15min (or 1h if you set the delay to weeks or
month).


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#605 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEWgRpdDgpjUo2bF_XPVVPfnKtxZS253ks5qZ8HXgaJpZM4JV5KN
.

R.D. Contarino rdcontarino@gmail.com
skype: rdarioc

@karlicoss
Copy link

@rdarioc any chance your drive's label contains a space character in it? Was the cause in my case #606

@rdarioc
Copy link
Author

rdarioc commented Jul 28, 2016

@dima

Thank you for reaching out, I appreciate it.

No, my disk's label doesn't contain any space or special character (just
BackUp). Though I haven't had time to test what Germar was suggesting early
on this morning. As soon as I will be able to run a complete test I'll
update you all on the results.

Thank you again

On 28 July 2016 at 16:29, Dima Gerasimov notifications@github.com wrote:

@rdarioc https://github.com/rdarioc any chance your drive's label
contains a space character in it? Was the cause in my case #606
#606


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#605 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEWgRkfnUyDJo8GE-pJEZmZRALF5IFwPks5qaLzhgaJpZM4JV5KN
.

R.D. Contarino rdcontarino@gmail.com
skype: rdarioc

@rdarioc
Copy link
Author

rdarioc commented Jul 29, 2016

@dima

Well, Ubuntu 16.04 doesn't automatically mount the USB device, even though
it makes it available to the window manager (Unity?). 14.04, on the
contrary, does it. Ironically, 14.04 is on my desktop, so most of the time
the USB hdd is always connected.

At the same time BIT is notified apparently of a new device but of course
when it looks for the snapshot directory it fails and notify the user with
the appropriate message saying that it will try again (once?) in 30sec.

It may be a security feature of Ubuntu, I don't know.

I have briefly investigated how to auto-mount a device and apparently,
simply executing devmon daemon does the job.

The thing is that starting devmon as daemon at boot is again a lottery
because Ubuntu has changed the way it handles its boot services on every
major release.

So, since we are talking about backing-up a notebook which doesn't have all
day long an USB hdd attached, I think I will stick to the following
procedure:

BIT configured as never automatically run a snapshot
Whenever I remember, I plug in the USB hdd
Since I remembered to plug in the USB hdd, I can also remember to mount its
file system by clicking on the relevant icon through the window manager,
start BIT manually and click on create a snapshot now button.

If anybody knows how to automount an USB hdd on ubunutu 16.04 in an elegant
way that info will be welcome otherwise, from BIT perspective, this is
definitely closed.

Thank you all for your support.

On 28 July 2016 at 17:02, Rosario Contarino rdcontarino@gmail.com wrote:

@dima

Thank you for reaching out, I appreciate it.

No, my disk's label doesn't contain any space or special character (just
BackUp). Though I haven't had time to test what Germar was suggesting early
on this morning. As soon as I will be able to run a complete test I'll
update you all on the results.

Thank you again

On 28 July 2016 at 16:29, Dima Gerasimov notifications@github.com wrote:

@rdarioc https://github.com/rdarioc any chance your drive's label
contains a space character in it? Was the cause in my case #606
#606


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#605 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEWgRkfnUyDJo8GE-pJEZmZRALF5IFwPks5qaLzhgaJpZM4JV5KN
.

R.D. Contarino rdcontarino@gmail.com
skype: rdarioc

R.D. Contarino rdcontarino@gmail.com
skype: rdarioc

@Germar
Copy link
Member

Germar commented Jul 29, 2016

Ubuntu 16.04 should mount USB drives automatically, too. At least it does that on all of my machines.

Please remove the Udev rule /etc/udev/rules.d/99-backintime-<USER>.rule manually and try again if your device is auto-mounted in Ubuntu (BIT won't start for sure). It happened before (with old versions) that an incorrect rule blocked Ubuntu to mount the device.

@karlicoss
Copy link

karlicoss commented Aug 9, 2016

@rdarioc I actually started running in the same problem :(
Not sure if how udev works, but it looks like it messes with the automount sequence and prevents it from even happening. So basically, the HDD is unavailable for the first 30 seconds backintime waits for the drive to appear, after 30 seconds backintime gives up, and the drive appears in the file manager.

@Germar
Copy link
Member

Germar commented Aug 9, 2016

Well, that sounds like BIT doesn't disconnect itself from udev correctly. Which BIT version do you use? I had this bug before and fixed it in 1.1.0 by sending BIT into background if started with --backup-job.
Could you please update to current stable version from ppa:bit-team/stable?

Fixed in c3522ff. Sorry for not remembering this earlier.

@karlicoss
Copy link

@Germar it's actually 1.1.12a, so it's probably something else.

@Germar
Copy link
Member

Germar commented Aug 12, 2016

Okay, I was able to reproduce this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants