On Wed, 2021-06-30 at 10:16 -0400, Jonathan Billings wrote: > On Wed, Jun 30, 2021 at 03:01:56PM +0100, Patrick O'Callaghan wrote: > > Well I did that, but things are no better. The service still > > doesn't > > restart after logging out and in again. In fact it's actually worse > > now > > as it apparently doesn't start even the first time. I even did a > > clean > > boot to check this and see: > > > > $ systemctl --user status startinsync.service > > ○ startinsync.service - insync-headless service > > Loaded: loaded > > (/home/poc/.config/systemd/user/startinsync.service; enabled; > > vendor preset: disabled) > > Active: inactive (dead) since Wed 2021-06-30 14:52:37 BST; > > 5min ago > > Process: 3404 ExecStart=/bin/sh /usr/bin/insync-headless > > start (code=exited, status=0/SUCCESS) > > Main PID: 4069 (code=exited, status=0/SUCCESS) > > CPU: 2.813s > > > > Jun 30 14:52:34 Bree systemd[3220]: Starting insync-headless > > service... > > Jun 30 14:52:37 Bree systemd[3220]: Started insync-headless > > service. > > Jun 30 14:52:37 Bree systemd[3220]: startinsync.service: > > Deactivated successfully. > > Jun 30 14:52:37 Bree systemd[3220]: startinsync.service: > > Consumed 2.813s CPU time. > > So, systemd --user runs as your user, and exists outside of your > login > session. It is launched by systemd when you log in. So, when it ran > the insync-headless.service (under systemd --user), it started, > probably when you first logged in, ran '/usr/bin/insync-headless > start', and then exited after 2.813 seconds of CPUtime. Because it > successfuly started, the systemd --user process didn't restart it, > and > as far as it can tell, it ran fine since it exited with status=0. > > When you logged out, your systemd --user process was still running. > It lives outside of your session. Then, as you logged in again, it > didn't try to launch the service, since it already had launched and > had exited successfully when systemd --user started. > > I suspect it isn't actually running the way you want it to, or it is > exiting unlike you expected. I'm not familiar with the service, but > maybe you can tell it to be extra verbose in what it is doing, or log > things someplace. I'll need to look into that. > It looks like there is an Arch insync package, and the systemd --user > service looks like this: > > # https://aur.archlinux.org/cgit/aur.git/tree/insync.service?h=insync > [Unit] > Description=Insync > After=local-fs.target network.target > > [Service] > Environment=DISPLAY=:0 > Type=oneshot > RemainAfterExit=yes > ExecStart=/usr/bin/insync start > ExecStop=/usr/bin/insync quit > > [Install] > WantedBy=default.target > That's actually a different service. Insync has a GUI-based app called 'insync' for workstations and a separate app called 'insync-headless' intended for servers. The two are essentially independent of each other and have different requirements. For historical reasons I'm using the latter. It could well be that my most sensible route would be to go with the workstation app, as clearly the headless version doesn't seem to be designed for what I want. I've already commented to Insync that having two different systems sounds like bad design - surely the workstation version should just be a GUI front-end to a back-end daemon, but unfortunately that's what you get with closed source. > Arch also has a insync@.service for systemd, where you can set up > insync@$USER.service for a particular user, but that's not what > you're > looking for. Right. poc _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
