I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
$ cat startinsync.service [Unit] Description=insync-headless service After=default.target
[Service] ExecStart=/bin/sh /usr/bin/insync-headless start KillSignal=SIGINT
[Install] WantedBy=default.target
The docs say that the place to put the unit file is given by:
$ pkg-config systemd --variable=systemduserunitdir /usr/lib/systemd/user
So I copied the file there:
$ ls -l /usr/lib/systemd/user/startinsync.service -rw-r--r--. 1 root root 177 Jun 29 12:31 /usr/lib/systemd/user/startinsync.service
and tried to enable it:
$ sudo systemctl enable startinsync Failed to enable unit: Unit file startinsync.service does not exist.
I'm out of ideas.
poc
On 29/06/2021 19:42, Patrick O'Callaghan wrote:
I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
$ cat startinsync.service [Unit] Description=insync-headless service After=default.target [Service] ExecStart=/bin/sh /usr/bin/insync-headless start KillSignal=SIGINT [Install] WantedBy=default.targetThe docs say that the place to put the unit file is given by:
$ pkg-config systemd --variable=systemduserunitdir /usr/lib/systemd/userSo I copied the file there:
$ ls -l /usr/lib/systemd/user/startinsync.service -rw-r--r--. 1 root root 177 Jun 29 12:31 /usr/lib/systemd/user/startinsync.serviceand tried to enable it:
$ sudo systemctl enable startinsync Failed to enable unit: Unit file startinsync.service does not exist.I'm out of ideas.
Did you do
systemctl daemon-reload
On Tue, 2021-06-29 at 19:48 +0800, Ed Greshko wrote:
On 29/06/2021 19:42, Patrick O'Callaghan wrote:
I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
$ cat startinsync.service [Unit] Description=insync-headless service After=default.target [Service] ExecStart=/bin/sh /usr/bin/insync-headless start KillSignal=SIGINT [Install] WantedBy=default.target
The docs say that the place to put the unit file is given by:
$ pkg-config systemd --variable=systemduserunitdir /usr/lib/systemd/user So I copied the file there:
$ ls -l /usr/lib/systemd/user/startinsync.service -rw-r--r--. 1 root root 177 Jun 29 12:31 /usr/lib/systemd/user/startinsync.service and tried to enable it:
$ sudo systemctl enable startinsync Failed to enable unit: Unit file startinsync.service does not exist. I'm out of ideas.
Did you do
systemctl daemon-reload
Yes.
poc
On 6/29/21 4:42 AM, Patrick O'Callaghan wrote:
The docs say that the place to put the unit file is given by:
$ pkg-config systemd --variable=systemduserunitdir /usr/lib/systemd/user
The better place for units that you create or modify is under /etc/systemd, so /etc/systemd/user for this one.
On Tue, 2021-06-29 at 04:52 -0700, Samuel Sieb wrote:
On 6/29/21 4:42 AM, Patrick O'Callaghan wrote:
The docs say that the place to put the unit file is given by:
$ pkg-config systemd --variable=systemduserunitdir /usr/lib/systemd/user
The better place for units that you create or modify is under /etc/systemd, so /etc/systemd/user for this one.
So the systemd docs are wrong?
poc
On Jun 29, 2021, at 07:43, Patrick O'Callaghan pocallaghan@gmail.com wrote:
and tried to enable it:
$ sudo systemctl enable startinsync Failed to enable unit: Unit file startinsync.service does not exist.
It is a user systemd unit. To enable it as a user (run this as your user, not as root):
systemctl —user enable startinsync.service
(This will populated directories and symlinks in your home directory)
If you want it enabled for all users, run:
sudo systemctl —user —global enable startinsync.service
This will create the symlinks in /etc/systemd/user/ to enable for all users logging in. It runs as root because it needs to edit files in /etc.
-- Jonathan Billings
On Tue, 2021-06-29 at 08:00 -0400, Jonathan Billings wrote:
On Jun 29, 2021, at 07:43, Patrick O'Callaghan pocallaghan@gmail.com wrote:
and tried to enable it:
$ sudo systemctl enable startinsync Failed to enable unit: Unit file startinsync.service does not exist.
It is a user systemd unit. To enable it as a user (run this as your user, not as root):
systemctl —user enable startinsync.service
(This will populated directories and symlinks in your home directory)
If you want it enabled for all users, run:
sudo systemctl —user —global enable startinsync.service
This will create the symlinks in /etc/systemd/user/ to enable for all users logging in. It runs as root because it needs to edit files in /etc.
Thanks, that seems to have worked.
poc
在 2021-06-29星期二的 12:42 +0100，Patrick O'Callaghan写道：
I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
How is that not working? Is it due to systemd-xdg-autostart-generator? KDE on Wayland seems to be using systemd-xdg-autostart-generator by default and causing some problems...
$ cat startinsync.service [Unit] Description=insync-headless service After=default.target [Service] ExecStart=/bin/sh /usr/bin/insync-headless start
Just an advice, If you have shebang ahead, you don't need /bin/sh.
ExecStart=/path/to/script.sh is enough, but make sure the script have +x set.
KillSignal=SIGINT [Install] WantedBy=default.target
The docs say that the place to put the unit file is given by:
$ pkg-config systemd --variable=systemduserunitdir /usr/lib/systemd/user
No, this place is usually for units installed by package manager.
Per-user unit files can be placed to * ~/.config/systemd/user/ : for you only * /etc/systemd/user/ : for everyone on this system You can check for the detail by `man SYSTEMD.UNIT 5`
So I copied the file there:
$ ls -l /usr/lib/systemd/user/startinsync.service -rw-r--r--. 1 root root 177 Jun 29 12:31 /usr/lib/systemd/user/startinsync.service
Execute `systemctl --user daemon-reload` to tell systemd instance that files on disk have changed.
and tried to enable it:
$ sudo systemctl enable startinsync Failed to enable unit: Unit file startinsync.service does not exist.
That is for system units, to manage user units, use: * systemd --user enable startinsync to enable for you only * systemd --global enable startinsync to enable for everyone on this system
I'm out of ideas.
Asking here is a great idea :)
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproje ct.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, 2021-06-29 at 21:28 +0800, Qiyu Yan wrote:
在 2021-06-29星期二的 12:42 +0100，Patrick O'Callaghan写道：
I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
How is that not working? Is it due to systemd-xdg-autostart- generator?
I need to call a command with an argument, but KDE Autostart only allows you to specify the name of an executable with no arguments. Even putting it in a Shell script doesn't work because although the script is called it immediately terminates, even though the exact same command when executed from the command line puts itself in the background, which is what it's supposed to do.
This is the entire script:
$ ls -l bin/start-insync -rwxrwxr-x. 1 poc poc 33 Jun 13 23:00 bin/start-insync $ cat bin/start-insync #!/bin/sh
insync-headless start
KDE on Wayland seems to be using systemd-xdg-autostart-generator by default and causing some problems...
This is Xorg. I don't use Wayland, due to issues with session saving.
[...]
$ sudo systemctl enable startinsync Failed to enable unit: Unit file startinsync.service does not exist.
That is for system units, to manage user units, use: * systemd --user enable startinsync to enable for you only * systemd --global enable startinsync to enable for everyone on this system
Thanks, that seems to work, at least as far as running the script goes.
poc
On Tue, 2021-06-29 at 13:00 -0600, Joe Zeff wrote:
On 6/29/21 12:37 PM, Patrick O'Callaghan wrote:
This is the entire script:
$ ls -l bin/start-insync -rwxrwxr-x. 1 poc poc 33 Jun 13 23:00 bin/start-insync $ cat bin/start-insync #!/bin/sh
insync-headless start
Have you tried including the path to insync-headless in the script?
It's installed in /usr/bin so I assume that's not necessary.
poc
On 30/06/2021 05:22, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 13:00 -0600, Joe Zeff wrote:
On 6/29/21 12:37 PM, Patrick O'Callaghan wrote:
This is the entire script:
$ ls -l bin/start-insync -rwxrwxr-x. 1 poc poc 33 Jun 13 23:00 bin/start-insync $ cat bin/start-insync #!/bin/sh
insync-headless start
Have you tried including the path to insync-headless in the script?
It's installed in /usr/bin so I assume that's not necessary.
Ideally, wouldn't you want to put it in /usr/local/bin? Standard practice and all.
On Wed, 2021-06-30 at 08:10 +0800, Ed Greshko wrote:
On 30/06/2021 05:22, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 13:00 -0600, Joe Zeff wrote:
On 6/29/21 12:37 PM, Patrick O'Callaghan wrote:
This is the entire script:
$ ls -l bin/start-insync -rwxrwxr-x. 1 poc poc 33 Jun 13 23:00 bin/start-insync $ cat bin/start-insync #!/bin/sh
insync-headless start
Have you tried including the path to insync-headless in the script?
It's installed in /usr/bin so I assume that's not necessary.
Ideally, wouldn't you want to put it in /usr/local/bin? Standard practice and all.
I didn't put it there. It's installed by an RPM. Insync is a cloud drive synchronization tool: https://www.insynchq.com/
poc
On 30/06/2021 16:19, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 08:10 +0800, Ed Greshko wrote:
On 30/06/2021 05:22, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 13:00 -0600, Joe Zeff wrote:
On 6/29/21 12:37 PM, Patrick O'Callaghan wrote:
This is the entire script:
$ ls -l bin/start-insync -rwxrwxr-x. 1 poc poc 33 Jun 13 23:00 bin/start-insync $ cat bin/start-insync #!/bin/sh
insync-headless start
Have you tried including the path to insync-headless in the script?
It's installed in /usr/bin so I assume that's not necessary.
Ideally, wouldn't you want to put it in /usr/local/bin? Standard practice and all.
I didn't put it there. It's installed by an RPM. Insync is a cloud drive synchronization tool: https://www.insynchq.com/
OK. Good to know. And learn something new every day.
On Tue, 2021-06-29 at 22:22 +0100, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 13:00 -0600, Joe Zeff wrote:
On 6/29/21 12:37 PM, Patrick O'Callaghan wrote:
This is the entire script:
$ ls -l bin/start-insync -rwxrwxr-x. 1 poc poc 33 Jun 13 23:00 bin/start-insync $ cat bin/start-insync #!/bin/sh
insync-headless start
Have you tried including the path to insync-headless in the script?
It's installed in /usr/bin so I assume that's not necessary.
Perhaps you should test that assumption.
On Tue, 2021-06-29 at 19:37 +0100, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 21:28 +0800, Qiyu Yan wrote:
在 2021-06-29星期二的 12:42 +0100，Patrick O'Callaghan写道：
I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
How is that not working? Is it due to systemd-xdg-autostart- generator?
I need to call a command with an argument, but KDE Autostart only allows you to specify the name of an executable with no arguments. Even putting it in a Shell script doesn't work because although the script is called it immediately terminates, even though the exact same command when executed from the command line puts itself in the background, which is what it's supposed to do.
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least *a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
poc
On Wed, 2021-06-30 at 11:41 +0100, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 19:37 +0100, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 21:28 +0800, Qiyu Yan wrote:
在 2021-06-29星期二的 12:42 +0100，Patrick O'Callaghan写道：
I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
How is that not working? Is it due to systemd-xdg-autostart- generator?
I need to call a command with an argument, but KDE Autostart only allows you to specify the name of an executable with no arguments. Even putting it in a Shell script doesn't work because although the script is called it immediately terminates, even though the exact same command when executed from the command line puts itself in the background, which is what it's supposed to do.
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least *a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
But of course there's always something else. After logging out, the service is killed, which is fine, but it doesn't start again with a new login. I assumed that user units would do this automatically, but it seems they don't.
poc
On 30/06/2021 19:35, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 11:41 +0100, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 19:37 +0100, Patrick O'Callaghan wrote:
On Tue, 2021-06-29 at 21:28 +0800, Qiyu Yan wrote:
在 2021-06-29星期二的 12:42 +0100，Patrick O'Callaghan写道：
I'm trying to get a specific service to start on login, and the usual method (KDE Autostart) isn't working so I'm trying to do it with a systemd unit:
How is that not working? Is it due to systemd-xdg-autostart- generator?
I need to call a command with an argument, but KDE Autostart only allows you to specify the name of an executable with no arguments. Even putting it in a Shell script doesn't work because although the script is called it immediately terminates, even though the exact same command when executed from the command line puts itself in the background, which is what it's supposed to do.
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least *a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
But of course there's always something else. After logging out, the service is killed, which is fine, but it doesn't start again with a new login. I assumed that user units would do this automatically, but it seems they don't.
Maybe ignore my previous question.
I've been playing with this as well. I found that with KDE I could get a service file to start at login by using
After=plasma-core.target in the [Unit] section and WantedBy=plasma-core.target in the [Install] section
I don't know if there is a general way to do it for all desktops.
On 30/06/2021 19:41, Ed Greshko wrote:
Maybe ignore my previous question.
I've been playing with this as well. I found that with KDE I could get a service file to start at login by using
After=plasma-core.target in the [Unit] section and WantedBy=plasma-core.target in the [Install] section
I don't know if there is a general way to do it for all desktops.
Oh, forgot to mention.......
I put my service file in ~/.config/systemd/user. Then I have to disable/enable the service for the change to take effect. Then I see....
[egreshko@f34k2 ~]$ ll .config/systemd/user/ total 4 -rw-r--r--. 1 egreshko egreshko 186 Jun 30 19:31 metest.service drwxr-xr-x. 1 egreshko egreshko 28 Jun 30 19:31 plasma-core.target.wants
after the service has been enabled.
On Wed, Jun 30, 2021 at 07:57:37PM +0800, Ed Greshko wrote:
I put my service file in ~/.config/systemd/user. Then I have to disable/enable the service for the change to take effect. Then I see....
[egreshko@f34k2 ~]$ ll .config/systemd/user/ total 4 -rw-r--r--. 1 egreshko egreshko 186 Jun 30 19:31 metest.service drwxr-xr-x. 1 egreshko egreshko 28 Jun 30 19:31 plasma-core.target.wants
after the service has been enabled.
And in the .config/systemd/user/plasma-core.target.wants/ directory, there should be a symlink to the service you enabled. That's how systemd units are "enabled", they're just symlinks in target requirement (".wants") directories.
On Wed, 2021-06-30 at 09:14 -0400, Jonathan Billings wrote:
On Wed, Jun 30, 2021 at 07:57:37PM +0800, Ed Greshko wrote:
I put my service file in ~/.config/systemd/user. Then I have to disable/enable the service for the change to take effect. Then I see....
[egreshko@f34k2 ~]$ ll .config/systemd/user/ total 4 -rw-r--r--. 1 egreshko egreshko 186 Jun 30 19:31 metest.service drwxr-xr-x. 1 egreshko egreshko 28 Jun 30 19:31 plasma- core.target.wants
after the service has been enabled.
And in the .config/systemd/user/plasma-core.target.wants/ directory, there should be a symlink to the service you enabled. That's how systemd units are "enabled", they're just symlinks in target requirement (".wants") directories.
I think that's set up by "systemctl enable --user ...".
poc
On 30/06/2021 21:41, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 09:14 -0400, Jonathan Billings wrote:
On Wed, Jun 30, 2021 at 07:57:37PM +0800, Ed Greshko wrote:
I put my service file in ~/.config/systemd/user. Then I have to disable/enable the service for the change to take effect. Then I see....
[egreshko@f34k2 ~]$ ll .config/systemd/user/ total 4 -rw-r--r--. 1 egreshko egreshko 186 Jun 30 19:31 metest.service drwxr-xr-x. 1 egreshko egreshko 28 Jun 30 19:31 plasma- core.target.wants
after the service has been enabled.
And in the .config/systemd/user/plasma-core.target.wants/ directory, there should be a symlink to the service you enabled. That's how systemd units are "enabled", they're just symlinks in target requirement (".wants") directories.
I think that's set up by "systemctl enable --user ...".
Yes, it was.
On Wed, 2021-06-30 at 19:57 +0800, Ed Greshko wrote:
On 30/06/2021 19:41, Ed Greshko wrote:
Maybe ignore my previous question.
I've been playing with this as well. I found that with KDE I could get a service file to start at login by using
After=plasma-core.target in the [Unit] section and WantedBy=plasma-core.target in the [Install] section
I don't know if there is a general way to do it for all desktops.
Right. I was looking for the appropriate target but didn't spot that one.
Oh, forgot to mention.......
I put my service file in ~/.config/systemd/user. Then I have to disable/enable the service for the change to take effect. Then I see....
OK.
poc
On Wed, Jun 30, 2021 at 02:40:27PM +0100, Patrick O'Callaghan wrote:
After=plasma-core.target in the [Unit] section and WantedBy=plasma-core.target in the [Install] section
I don't know if there is a general way to do it for all desktops.
Right. I was looking for the appropriate target but didn't spot that one.
If you want a generic one for all users, regardless of desktop environment, you can use 'default.target'. That'll even effect SSH logins and logins on the text VT.
On Wed, 2021-06-30 at 19:41 +0800, Ed Greshko wrote:
But of course there's always something else. After logging out, the service is killed, which is fine, but it doesn't start again with a new login. I assumed that user units would do this automatically, but it seems they don't.
Maybe ignore my previous question.
I've been playing with this as well. I found that with KDE I could get a service file to start at login by using
After=plasma-core.target in the [Unit] section and WantedBy=plasma-core.target in the [Install] section
I don't know if there is a general way to do it for all desktops.
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.
The current service file looks like this:
$ systemctl --user cat startinsync.service # /home/poc/.config/systemd/user/startinsync.service [Unit] Description=insync-headless service After=plasma-core.target
[Service] Type=forking ExecStart=/bin/sh /usr/bin/insync-headless start
[Install] WantedBy=plasma-core.target
poc
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.
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
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.
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
On Wed, 2021-06-30 at 22:24 +0100, Patrick O'Callaghan wrote:
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.
After writing the above, a light dawned. Given that insync-headless is marketed for servers, its natural mode of operation is going to be independent of who is logged in. In turns out that the (undocumented) configuration options include one called 'run_on_startup', which by default is set to False. I changed it to True, disabled my systemd service, and rebooted.
Lo and behold, insync-headless is now running on boot. What the config option does is install a crontab entry under the user's /var/spool/cron directory:
$ crontab -l
@reboot insync-headless start >/dev/null 2>&1
This runs independently of login sessions (multiple users might have multiple such entries). That appears to be the solution. I stress again that this is *undocumented*.
Apologies for the noise and thanks to all who attempted to help.
poc
On 01/07/2021 05:56, Patrick O'Callaghan wrote:
Apologies for the noise and thanks to all who attempted to help.
Oh, that's OK.
Got me to start experimenting with writing user units and learning a bit about how they work.
So, some good came of the noise. From my perspective anyway. :-)
On Thu, 2021-07-01 at 08:53 +0800, Ed Greshko wrote:
On 01/07/2021 05:56, Patrick O'Callaghan wrote:
Apologies for the noise and thanks to all who attempted to help.
Oh, that's OK.
Got me to start experimenting with writing user units and learning a bit about how they work.
So, some good came of the noise. From my perspective anyway. :-)
Ditto. I have some other uses for this.
poc
Hi.
On Thu, 01 Jul 2021 10:47:45 +0100 Patrick O'Callaghan wrote:
On Thu, 2021-07-01 at 08:53 +0800, Ed Greshko wrote:
Got me to start experimenting with writing user units and learning a bit about how they work.
So, some good came of the noise.�� From my perspective anyway.�� :-)
Ditto. I have some other uses for this.
Me too, for example to start a regular backup with a .timer user unit.
It is also possible to have such units start at boot, by executing (once and as root):
loginctl enable-linger LOGIN ...
On Sun, 2021-07-04 at 17:34 +0200, Francis.Montagnac@inria.fr wrote:
Hi.
On Thu, 01 Jul 2021 10:47:45 +0100 Patrick O'Callaghan wrote:
On Thu, 2021-07-01 at 08:53 +0800, Ed Greshko wrote:
Got me to start experimenting with writing user units and learning a bit about how they work.
So, some good came of the noise. From my perspective anyway. :- )
Ditto. I have some other uses for this.
Me too, for example to start a regular backup with a .timer user unit.
It is also possible to have such units start at boot, by executing (once and as root):
loginctl enable-linger LOGIN ...
Currently I use "@reboot some-command" in the root crontab, but I'll take a look at that.
poc
On 30/06/2021 18:41, Patrick O'Callaghan wrote:
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least*a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
Your user service, does it start at boot time or does it start when the user logs in?
On Wed, 2021-06-30 at 19:37 +0800, Ed Greshko wrote:
On 30/06/2021 18:41, Patrick O'Callaghan wrote:
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least*a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
Your user service, does it start at boot time or does it start when the user logs in?
It's "WantedBy" default.target, whatever that means.
poc
On 30/06/2021 21:39, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 19:37 +0800, Ed Greshko wrote:
On 30/06/2021 18:41, Patrick O'Callaghan wrote:
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least*a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
Your user service, does it start at boot time or does it start when the user logs in?
It's "WantedBy" default.target, whatever that means.
With that my service was starting at boot. Not what I was after.
On Wed, 2021-06-30 at 21:45 +0800, Ed Greshko wrote:
On 30/06/2021 21:39, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 19:37 +0800, Ed Greshko wrote:
On 30/06/2021 18:41, Patrick O'Callaghan wrote:
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least*a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
Your user service, does it start at boot time or does it start when the user logs in?
It's "WantedBy" default.target, whatever that means.
With that my service was starting at boot. Not what I was after.
Right. It doesn't really matter in my case as I'm the only users, but of course it's not ideal.
poc
On 30/06/2021 21:55, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 21:45 +0800, Ed Greshko wrote:
On 30/06/2021 21:39, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 19:37 +0800, Ed Greshko wrote:
On 30/06/2021 18:41, Patrick O'Callaghan wrote:
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least*a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
Your user service, does it start at boot time or does it start when the user logs in?
It's "WantedBy" default.target, whatever that means.
With that my service was starting at boot. Not what I was after.
Right. It doesn't really matter in my case as I'm the only users, but of course it's not ideal.
I suppose it is aslo dependent on the type of service being run. The service in my case is only of value when the user is logged in to KDE. So there is no sense in having the service run at boot time. I also have "KillUserProcesses=yes" set in logind.conf so when I logout my processes are all killed.
On Wed, 2021-06-30 at 22:35 +0800, Ed Greshko wrote:
On 30/06/2021 21:55, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 21:45 +0800, Ed Greshko wrote:
On 30/06/2021 21:39, Patrick O'Callaghan wrote:
On Wed, 2021-06-30 at 19:37 +0800, Ed Greshko wrote:
On 30/06/2021 18:41, Patrick O'Callaghan wrote:
After re-reading systemd.service(1) I added the line:
Type=forking
to the service file, and now the script is not being terminated, which is what I wanted.
IOW, this seems to be the solution, or at least*a* solution. There may be an alternate solution using KDE Autostart, but for now I'm satisfied.
Your user service, does it start at boot time or does it start when the user logs in?
It's "WantedBy" default.target, whatever that means.
With that my service was starting at boot. Not what I was after.
Right. It doesn't really matter in my case as I'm the only users, but of course it's not ideal.
I suppose it is aslo dependent on the type of service being run. The service in my case is only of value when the user is logged in to KDE. So there is no sense in having the service run at boot time. I also have "KillUserProcesses=yes" set in logind.conf so when I logout my processes are all killed.
Sure. On F33 I did have KillUserProcesses=yes set, but I neglected to make that change on F34. It might make a difference.
poc
On 6/30/21 11:52 AM, Patrick O'Callaghan wrote:
Sure. On F33 I did have KillUserProcesses=yes set, but I neglected to make that change on F34. It might make a difference.
If those settings are kept in your home directory, they should survive a clean install as long as you keep your home intact, or restore it from backup.
On 01/07/2021 02:14, Joe Zeff wrote:
On 6/30/21 11:52 AM, Patrick O'Callaghan wrote:
Sure. On F33 I did have KillUserProcesses=yes set, but I neglected to make that change on F34. It might make a difference.
If those settings are kept in your home directory, they should survive a clean install as long as you keep your home intact, or restore it from backup.
They are not.
The settings is in /etc/systemd/logind.conf
-
C Linus Hicks -
Ed Greshko -
Francis.Montagnac＠inria.fr -
Joe Zeff -
Jonathan Billings -
Patrick O'Callaghan -
Qiyu Yan -
Samuel Sieb