6:42 a.m.
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
6:48 a.m.
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
--
Remind me to ignore comments which aren't germane to the thread.
6:52 a.m.
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.
7 a.m.
On Jun 29, 2021, at 07:43, Patrick O'Callaghan <pocallaghan(a)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
8:28 a.m.
在 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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
--
Qiyu Yan GPG keyid: 0x4FC914F065F2DF12 About:
https://fedoraproject.org/wiki/User:Yanqiyu
11:05 a.m.
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
1:12 p.m.
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
1:14 p.m.
On Tue, 2021-06-29 at 08:00 -0400, Jonathan Billings wrote:
On Jun 29, 2021, at 07:43, Patrick O'Callaghan
<pocallaghan(a)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
1:37 p.m.
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
4:22 p.m.
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
7:10 p.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
8:13 p.m.
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.
3:19 a.m.
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
3:21 a.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
5:41 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
6:35 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
6:37 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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?
--
Remind me to ignore comments which aren't germane to the thread.
6:41 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
--
Remind me to ignore comments which aren't germane to the thread.
6:57 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
--
Remind me to ignore comments which aren't germane to the thread.
8:14 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
--
Jonathan Billings <billings(a)negate.org>
8:39 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
8:40 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
8:41 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
8:45 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
--
Remind me to ignore comments which aren't germane to the thread.
8:46 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
--
Remind me to ignore comments which aren't germane to the thread.
8:48 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
--
Jonathan Billings <billings(a)negate.org>
8:55 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
9:01 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
9:16 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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(a)$USER.service for a particular user, but that's not what you're
looking for.
--
Jonathan Billings <billings(a)negate.org>
9:35 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
--
Remind me to ignore comments which aren't germane to the thread.
12:52 p.m.
New subject: Creating a user-level systemd unit - SOLVED
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
1:14 p.m.
New subject: Creating a user-level systemd unit - SOLVED
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.
3:39 p.m.
New subject: Creating a user-level systemd unit - SOLVED
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
--
Remind me to ignore comments which aren't germane to the thread.
4:24 p.m.
New subject: Creating a user-level systemd unit - SOLVED
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(a)$USER.service for a particular user, but that's not what
you're
looking for.
Right.
poc
4:56 p.m.
New subject: Creating a user-level systemd unit - SOLVED
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
7:53 p.m.
New subject: Creating a user-level systemd unit - SOLVED
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. :-)
--
Remind me to ignore comments which aren't germane to the thread.
4:47 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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
10:34 a.m.
New subject: Creating a user-level systemd unit - SOLVED
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 ...
--
francis
11:14 a.m.
New subject: Creating a user-level systemd unit - SOLVED
On Sun, 2021-07-04 at 17:34 +0200, Francis.Montagnac(a)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
1025
days inactive
1030
days old
39 comments
8 participants
participants (8)
-
C Linus Hicks -
Ed Greshko -
Francis.Montagnac＠inria.fr -
Joe Zeff -
Jonathan Billings -
Patrick O'Callaghan -
Qiyu Yan -
Samuel Sieb