Fresh install which picks up old settings does not set cronjob correctly

[Mike Fairbank]

If you have a nicely working instance of backintime successfully performing daily backups, and then you reinstall your operating-system (but preserve your home folder), followed by reinstalling backintime, then backintime nicely remembers its old settings.

You can take a snapshot and it works as it did before. It all looks perfect - in fact it (incorrectly) reports that it is still scheduled to do daily backups. But strangely the daily backups do not happen, because the cronjob file was reset after the reinstall but the backintime settings were not reset - so the two do not match.

I'm not sure what the solution to this problem is, other-than having backintime occasionally inspect the crontab file, e.g. whenever the backintime application is started. But I think this is a bug because back-in-time's settings panel is incorrectly stating that a daily backup schedule is set, and this gives a false sense of security.

[Germar (germar)]

crontab doesn't run in userspace. It run as root and the user can only add new schedules with 'crontab' command. The schedules are stored somewhere in /var. That's why the schedules where gone after you reinstalled your system.

BIT always set up crontab schedules as soon as you press OK in Settings dialog. No matter if they had change or not.

We could add a warning on GUI start if crontab doesn't match BIT config and ask to run Settings.

[Mike Fairbank (michael-fairbank)]

I think the best solution might be to add a crontab call during the 'apt-get install backintime' process if that is possible. That way it would only be called once, and it would be called immediately as soon as it is needed (without being dependent on any actions chosen by the user), and without giving the user any potentially confusing dialog windows to respond to?

On 18 Jul 2014 23:09, Germar <email address hidden> wrote:
>
> crontab doesn't run in userspace. It run as root and the user can only
> add new schedules with 'crontab' command. The schedules are stored
> somewhere in /var. That's why the schedules where gone after you
> reinstalled your system.
>
> BIT always set up crontab schedules as soon as you press OK in Settings
> dialog. No matter if they had change or not.
>
> We could add a warning on GUI start if crontab doesn't match BIT config
> and ask to run Settings.
>
> ** Changed in: backintime
>        Status: New => Triaged
>
> ** Changed in: backintime
>    Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1343599
>
> Title:
>   Fresh install which picks up old settings does not set cronjob
>   correctly
>
> Status in Back In Time:
>   Triaged
>
> Bug description:
>   If you have a nicely working instance of backintime successfully
>   performing daily backups, and then you reinstall your operating-system
>   (but preserve your home folder), followed by reinstalling backintime,
>   then backintime nicely remembers its old settings.
>
>   You can take a snapshot and it works as it did before.  It all looks
>   perfect - in fact it (incorrectly) reports that it is still scheduled
>   to do daily backups.   But strangely the daily backups do not happen,
>   because the cronjob file was reset after the reinstall but the
>   backintime settings were not reset - so the two do not match.
>
>   I'm not sure what the solution to this problem is, other-than having
>   backintime occasionally inspect the crontab file, e.g. whenever the
>   backintime application is started.  But I think this is a bug because
>   back-in-time's settings panel is incorrectly stating that a daily
>   backup schedule is set, and this gives a false sense of security.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/backintime/+bug/1343599/+subscriptions

[Germar (germar)]

Nope, that won't work because apt-get is started as root and crontab need to run by the user who is using it.

Also this wouldn't help if the crontab entry is wiped for some other reason.

[Mike Fairbank (michael-fairbank)]

Ok why not do the crontab call whenever the application starts up?

Also, does one part, or all, of backintime run as one of the "startup"
applications whenever the user logs on? If one of these backintime
startup-processes makes the crontab call then that will mean the cron job
is set up without any user intervention.

On 20 July 2014 12:21, Germar <email address hidden> wrote:

> Nope, that won't work because apt-get is started as root and crontab
> need to run by the user who is using it.
>
> Also this wouldn't help if the crontab entry is wiped for some other
> reason.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1343599
>
> Title:
> Fresh install which picks up old settings does not set cronjob
> correctly
>
> Status in Back In Time:
> Triaged
>
> Bug description:
> If you have a nicely working instance of backintime successfully
> performing daily backups, and then you reinstall your operating-system
> (but preserve your home folder), followed by reinstalling backintime,
> then backintime nicely remembers its old settings.
>
> You can take a snapshot and it works as it did before. It all looks
> perfect - in fact it (incorrectly) reports that it is still scheduled
> to do daily backups. But strangely the daily backups do not happen,
> because the cronjob file was reset after the reinstall but the
> backintime settings were not reset - so the two do not match.
>
> I'm not sure what the solution to this problem is, other-than having
> backintime occasionally inspect the crontab file, e.g. whenever the
> backintime application is started. But I think this is a bug because
> back-in-time's settings panel is incorrectly stating that a daily
> backup schedule is set, and this gives a false sense of security.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/backintime/+bug/1343599/+subscriptions
>