Reply
Thread Tools
Posts: 188 | Thanked: 90 times | Joined on Sep 2006
#1
As you may have found, without allowing background data, apps like the calendar will not sync as per the schedule.

But, allowing background connections all the time will drain the battery (at least more than necessary)... Especially, since you may just want to sync at home in the morning, and would (like my wife) not think of turning of the background connection - leading to it trying to find a known connection all day.

So, I figured out how to schedule the sync - in my case it's just CalDAV (gmail calendar).

I use cron (from this meego thread: http://forum.meego.com/showthread.ph...highlight=cron and this site: https://gitorious.org/cron-for-harmattan/cron ) and gconftool-2 to get the N9 to switch to "background connections allowed" temporarily, then set the CalDAV in "Accounts" to sync within that window.

Here's the script, which I put in /home/user/bin/synccal.sh:
Code:
#!/bin/sh
cd /home/user/bin

INITIALLY=off

if [ `gconftool-2 -g /system/osso/connectivity/network_type/restricted_mode` == "false" ]
  then
    INITIALLY=already_on
  else
    gconftool-2 -t bool -s /system/osso/connectivity/network_type/restricted_mode false
    sleep 10
fi

#date >>  /home/user/bin/synccal.log

# sync caldav calendar
#dbus-send --session --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.startSync string:'228076262'

whoami >> /home/user/bin/synccal.log
date >>  /home/user/bin/synccal.log

if [ $INITIALLY == "off" ]
  then
    sleep 300
    gconftool-2 -t bool -s /system/osso/connectivity/network_type/restricted_mode true
fi
At the start, if the background connection is not allowed, I put the sleep to 10 secs, which seems enough to make the connection to my wifi. Later I keep it for 300 secs, to have a good window to sync in.

And then as root, I setup cron:
Code:
/opt/cron/bin/crontab -e
10 6 * * * devel-su user -c 'sh /home/user/bin/synccal.sh'
Warning for the uninitiated! crontab -e requires you to input using vi commands... google: man vi
to get started on that one; all you need to know in terms of vi commands is
i
<esc>
:w
:wq
:q!

Note that with the above lines, the device will have an internet connection at 6:10am plus about 10 secs, until 6:15:10.
I setup CalDAV to sync at 6:11, and the past few mornings, that worked fine.

And now for the weird thing....
if you look at my script, you'll see some commented out stuff, dbus command to actually sync the caldav calendar, plus some other debugging/logging stuff.

The dbus sync command:
manually sync your calendar
check /home/user/.sync/profiles/sync/log to see which number got synced, then use that number in the dbus sync command.
Works fine, as user, if you have a network connection.
As root, use the command as in the crontab, on the command line.
Works fine too, whoami nicely indicates that the owner of the process is clearly 'user'.

BUT! As cron job, this doesn't work...
I can't figure out why not - it actually does log the date and whoami output to the log file... but doesn't run the dbus command...

Any hints?
 

The Following 3 Users Say Thank You to aRTee For This Useful Post:
Posts: 64 | Thanked: 42 times | Joined on Jun 2009
#2
Not related to your question, but (the original) cron uses the editor defined in the EDITOR environment variable. So you should be able to change it by first executing e.g.:

export EDITOR=/usr/bin/nano

Regarding your question: have you tried setting up a cron job for "user" (e.g. crontab -e -u user as root; or add user to /etc/cron.allow or /usr/lib/cron/cron.allow (if in doubt, grep allow /path/to/cron) then run develsh as user then crontab -e)?

Last edited by zszabo; 2012-02-04 at 03:00.
 

The Following 3 Users Say Thank You to zszabo For This Useful Post:
Posts: 188 | Thanked: 90 times | Joined on Sep 2006
#3
thanks for the hints - I will give it a try to setup a cron job as user.
As whoami from the root cron job shows user, I don't think it will change much, but as surprising as some things work, who knows.

Regarding editor, I don't think I have nano installed, I'm fine with vi, but thanks a lot for the tip, I'm sure many will find it very useful.
 
Moderator | Posts: 5,320 | Thanked: 4,464 times | Joined on Oct 2009
#4
Someone lodged bug/enhancement request about background connections.
IIRC they cited how Symbian works as an e.g. of how it really should work...
Can't recall what Nokia devs said, I think they ultimately said WONTFIX for some lame reason.
It's a shame we have to devise workarounds like this, just because they don't think their **** stinks.


I've added this thread to the N9/x0 universal guide, in the workarounds sub-section:
Autosync apps w/o leaving background connections on (using cron job + gconftool-2)
http://talk.maemo.org/showthread.php?t=82089

Last edited by jalyst; 2012-02-04 at 10:18.
 
Posts: 188 | Thanked: 90 times | Joined on Sep 2006
#5
Hi jalyst, I vaguely recall something to the same effect...

I see how the current system works, and can live with it, but I agree it doesn't make all that much sense.

One should be able to connect on purpose, directly, and allow background connections whenever there is something that wants to go on the internet.
And ideally, one should be able to tune/specify which apps can go on the net...
__________________
If I said something useful, please hit the 'Thanks!' link related to that post.
 

The Following User Says Thank You to aRTee For This Useful Post:
Posts: 104 | Thanked: 58 times | Joined on Dec 2011
#6
Me is also really annoyed by this stupid connection behavior. Background Connection for me makes sense if I want to be always on and immediately receive some push-notifications, chat or constantly show my current position, etc.
But being always on to trigger some scheduled data fetching events (like emails from time to time) is absolutely ********.
We should file another bug request and vote all for it! (Will do that tomorrow if noone did before..need to leave now)
 
Moderator | Posts: 5,320 | Thanked: 4,464 times | Joined on Oct 2009
#7
Don't file another, just dig up the one or two that are already filed.
They're definitely there... There's been threads at TMO about it too.
We need everyone subscribed to and voting in the same report.

Last edited by jalyst; 2012-02-04 at 20:15.
 
Posts: 24 | Thanked: 27 times | Joined on Nov 2010 @ Berkeley, CA
#8
Originally Posted by jalyst View Post
Don't file another, just dig up the one or two that are already filed.
They're definitely there... There's been threads at TMO about it too.
We need everyone subscribed to and voting in the same report.
I think this was one of them.

https://harmattan-bugs.nokia.com/show_bug.cgi?id=463
 

The Following User Says Thank You to jhwan For This Useful Post:
Posts: 188 | Thanked: 90 times | Joined on Sep 2006
#9
If you think about it, the wording on the N9 interface is really contrary to what the device does...

Allow background internet connections will make the device connect to the wifi (if available) or cellular data (why at a time there is no request...?).
And connect to the internet will present the selection of choices (wifi networks and cellular).

I would think - imagining I'd never used an N9 before, that
- connect
would mean to create a connection to any known network, and keep it alive
- allow bg connection
would mean to create a connection on demand for any app requesting it, without user interaction (so without "app X wants to go on the internet, allow / deny?" dialog)
and then there might be a need for the option
- setup connection
which would then allow to select a wifi network that has never been used before.


BTW I checked and already voted for that bug...
__________________
If I said something useful, please hit the 'Thanks!' link related to that post.
 

The Following User Says Thank You to aRTee For This Useful Post:
Posts: 64 | Thanked: 42 times | Joined on Jun 2009
#10
One additional hint I should mention that probably won't solve your problem but can cause odd/unexpected results: sometimes commands may depend on environment variables being set a particular way; but, contrary to what one might expect, cron may inherit a very different set (a changed PATH being the most obvious example). To mitigate this, variables can be set by placing variable declarations of the form ENVAR = VALUE (optionally enclosed with ') on separate lines.

Also, I noticed the man page on crontab mentions something about selinux security contexts potentially leading to unexpected results. This may explain the odd behavior under Aegis: http://unixhelp.ed.ac.uk/CGI/man-cgi?crontab+5
 

The Following User Says Thank You to zszabo For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 23:50.