Package Details: insync 3.9.11.60043-1

Git Clone URL: https://aur.archlinux.org/insync.git (read-only, click to copy)
Package Base: insync
Description: An unofficial Dropbox, Google Drive, and OneDrive client that runs on Linux, with support for various desktops
Upstream URL: https://www.insynchq.com/downloads
Keywords: drive dropbox google onedrive
Licenses: custom:insync
Submitter: xzy3186
Maintainer: thenaterhood
Last Packager: thenaterhood
Votes: 325
Popularity: 0.95
First Submitted: 2012-09-07 17:45 (UTC)
Last Updated: 2026-07-14 11:56 (UTC)

Latest Comments

« First ‹ Previous 1 .. 37 38 39 40 41 42 43 44 45 46 47 .. 66 Next › Last »

colinkeenan commented on 2013-10-23 03:05 (UTC)

I decided to read the official systemd info at http://www.freedesktop.org and found this page specifically about the network.target not working: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/. I couldn't believe the following information at the end of the first section: "In systemd network.target by default does not have much meaning...By defaulting to the empty meaning we hence provide a speedy boot that is not slowed down by external factors for the majority of cases, but by allowing network.target to be defined by the administrator as he likes any policy is implementable instead." This explains why starting after network.target isn't working for us. We also have to give network.target some meaning. The next section is appropriately titled: "Cut the crap! How do I make network.target work for me?". I'm about to read it and suggest others interested in systemd read it as well.

colinkeenan commented on 2013-10-15 07:26 (UTC)

I've decided to give up on systemd for starting insync. The more reliable way is to just checkmark 'Start Insync when computer starts' in the preferences menu. I may follow up in the forums to work out if there's a better file to use for systemd with insync or if there's a bug, but not right now.

xzy3186 commented on 2013-10-15 01:19 (UTC)

Updated to 1.0.24 @colinkeenan,orschiro Since no conclusion has been made yet, I re-add 'ExecStartPre=/usr/bin/sleep 60' back to the service file temporally to make it work.

orschiro commented on 2013-10-14 19:58 (UTC)

@colinkeenan Have you already asked on the forums for help? I find this quite an interesting issue to investigate. Maybe it is a bug within systemd?

colinkeenan commented on 2013-10-14 19:33 (UTC)

I removed the sleep command again. Seems to do better without the sleep command but it doesn't always start regardless. I don't think it has anything to do with the network not being up. I will just have to start it manually sometimes.

colinkeenan commented on 2013-10-13 23:19 (UTC)

I ended up putting the sleep command back in. I don't see why the requires= and after= lines don't always work.

colinkeenan commented on 2013-10-09 02:26 (UTC)

I decided to see what I could understand about systemd from the wiki and found the dependencies section: https://wiki.archlinux.org/index.php/Systemd#Handling_dependencies That section says to put both 'Requires=...' and 'After=...'. I understand why you didn't put 'Requires=...' in there because 'After=...' is telling it to wait until after the network starts so obviously it requires the network. But, following the wiki, I'm seeing what happens if I add the 'Requires=...' to the 'Unit' section. I have again removed the sleep command. Tomorrow, I'll report if this works better.

orschiro commented on 2013-10-08 05:41 (UTC)

@colinkeenan The `After=local-fs.target network.target` part should actually prevent you from this problem. But now you probably see why I created the NetworkManager dispatcher script. For some users even 60 seconds sleep time might not be enough to establish an internet connection. In these cases the dispatcher script comes in handy as it automatically restarts the service after an internet connection was established.

« First ‹ Previous 1 .. 37 38 39 40 41 42 43 44 45 46 47 .. 66 Next › Last »