Re: [systemd-devel] systemctl --user user can't restart their own service?

2017-11-17 Thread Michael Chapman 

On Sat, 18 Nov 2017, Jeff Solomon wrote:

When I run:

  systemctl --user daemon-reexec

I see that the daemon gets a --deserialize flag in it command line on "top"
but the PID is not any different. I guess I don't need the PID to change if
the process picks up any changes to its unit file.


The systemd process simply reexecutes itself. It doesn't fork, so it 
doesn't get a new PID.



I would want to use this command for exactly the reason you specify
Michael. The user@.service file might change and we want to make use of it
immediately. Also, we're only using lingering, so logging out and in
doesn't apply to us.


This won't pick up changes to the user@.service unit loaded into the 
system-wide systemd instance. There shouldn't be any reason to change 
this unit.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl --user user can't restart their own service?

2017-11-17 Thread Jeff Solomon 
When I run:

   systemctl --user daemon-reexec

I see that the daemon gets a --deserialize flag in it command line on "top"
but the PID is not any different. I guess I don't need the PID to change if
the process picks up any changes to its unit file.

I would want to use this command for exactly the reason you specify
Michael. The user@.service file might change and we want to make use of it
immediately. Also, we're only using lingering, so logging out and in
doesn't apply to us.

On Fri, Nov 17, 2017 at 3:16 PM, Michael Chapman 
wrote:

> On Sat, 18 Nov 2017, Jeff Solomon wrote:
>
>> Hi,
>>
>> Is it by-design that a user can't restart their own user service?
>>
>
> If they aren't a lingering user, they'll get a new systemd instance if
> they completely log out and back in again.
>
> Alternatively, they can restart the running instance with:
>
>   systemctl --user daemon-reexec
>
> This serializes state across the re-execution, so services running in the
> instance are not killed.
>
> There's few reasons a user might want to do this however. The only one I
> can think of is where the admin had updated the systemd package and the
> user wanted to make use of it immediately.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl --user user can't restart their own service?

2017-11-17 Thread Michael Chapman 

On Sat, 18 Nov 2017, Jeff Solomon wrote:

Hi,

Is it by-design that a user can't restart their own user service?


If they aren't a lingering user, they'll get a new systemd instance if 
they completely log out and back in again.


Alternatively, they can restart the running instance with:

  systemctl --user daemon-reexec

This serializes state across the re-execution, so services running in the 
instance are not killed.


There's few reasons a user might want to do this however. The only one I 
can think of is where the admin had updated the systemd package and the 
user wanted to make use of it immediately.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl --user user can't restart their own service?

2017-11-17 Thread Kai Krakow 
Am Fri, 17 Nov 2017 10:00:35 -0800
schrieb Jeff Solomon :

> Hi,
> 
> Is it by-design that a user can't restart their own user service?
> 
> I have worked around this by doing the following:
> 
> Override /lib/systemd/system/user@.service with a new file:
> 
> /etc/systemd/system/user@.service
> 
> I could have left out the  if I wanted the override to apply to
> all users, but in this case, I want it to apply to only a single user.
> 
> In user@.service, I added:
> 
> Restart=always
> 
> to the [Service] section.
> 
> Viola! Now the user can just kill their own service (since they own it
> after all) and systemd will restart it for them.
> 
> Any problem with this workaround Lennart?

Services in systemd/system are NOT user services. It's a system service
running with user privileges. I think the whole point of exactly that
instance is starting the user systemd instance.

Real user services belong into systemd/user folder (provided by the
admin or system, or by the user when below $HOME/.config).

With "systemctl --user" you manage exactly those services.

What's the point of letting the user restart the user@.service anyway?
It would probably kill her/his login session or break other things. You
should restart individual user services instead. You can list them with
"systemctl --user status".

I have the feeling you didn't understand what the user@.service really
is... It's in any case not "the user's own service". It's their systemd
instance. It is to your user login what is init to the OS. You wouldn't
restart init, would you? I probably understand that it'd be equal to
rebooting the system. Thus, in the user instance case, it would restart
the complete session of the user.

You have to understand the difference: You could also create a service
like dropbox@.service. But it's not a user service then. It's a
system service instance running with user privileges. It's in that case
decoupled from the user session and would run without having the user
to login. You can achieve something similar with enabling linger on user
sessions. The difference is: First case runs outside of the user
session context, the latter runs within the context. This has a direct
effect on how the cgroups apply.


-- 
Regards,
Kai

Replies to list-only preferred.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemctl --user user can't restart their own service?

2017-11-17 Thread Jeff Solomon 
Hi,

Is it by-design that a user can't restart their own user service?

I have worked around this by doing the following:

Override /lib/systemd/system/user@.service with a new file:

/etc/systemd/system/user@.service

I could have left out the  if I wanted the override to apply to all
users, but in this case, I want it to apply to only a single user.

In user@.service, I added:

Restart=always

to the [Service] section.

Viola! Now the user can just kill their own service (since they own it
after all) and systemd will restart it for them.

Any problem with this workaround Lennart?

Thanks,

Jeff
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl --user roadmap question

2017-11-17 Thread Lennart Poettering 
On Fr, 17.11.17 09:20, Jeff Solomon (jsolomon8...@gmail.com) wrote:

> Hi,
> 
> RHEL removed support for systemd "user services" because they said:
> 
> "Basically we don't know if systemd --user will stay in systemd as is right
> now.
> So we have decided to disable it completely so we will not hit regression
> in future versions of centos."
> 
> That statement was made 18 months ago.
> 
> Any update from the systemd side? Is "systemctl --user" going to stay the
> way it is? Dramatically change? Or even be removed? Just wondering if there
> has been any decisions made on the roadmap for "systemctl --user".
> 
> I personally find it VERY convenient to allow regular users to run their
> services using the power of systemd.

Yes, it hasn't changed in any incompatible way since quite some time,
and I figure the comment should be ignored.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemctl --user roadmap question

2017-11-17 Thread Jeff Solomon 
Hi,

RHEL removed support for systemd "user services" because they said:

"Basically we don't know if systemd --user will stay in systemd as is right
now.
So we have decided to disable it completely so we will not hit regression
in future versions of centos."

That statement was made 18 months ago.

Any update from the systemd side? Is "systemctl --user" going to stay the
way it is? Dramatically change? Or even be removed? Just wondering if there
has been any decisions made on the roadmap for "systemctl --user".

I personally find it VERY convenient to allow regular users to run their
services using the power of systemd.

Jeff
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] moved from systemd 195 to 225, unable to start custom services.

2017-11-17 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Nov 17, 2017 at 05:11:26PM +0530, Shekhar arya wrote:
> Hi
> 
> I have upgraded my systemd from older version v195 (used in poky 1.6) to
> v225 to resolve some of the memory leak issues. I have resolved all the
> dependencies while compilation and now system boots fine. However, after
> the boot is complete, systemd is not able to start services present in
> /lib/systemd/system folder. These services where perfectly working fine
> with previous version of systemd. Journalctl logs report /var/ and /tmp/
> directories as read-only but in mount I can see them as read-write fs.
> Below is the log which I referred. Am I missing something or does newer
> version of systemd required certain more configurations to run the custom
> services?

Hi,
ancient versions of systemd are not supported upstream, in general.
It sounds like you are using a split-/usr scenario. You might need to
tweak the configuration options to adjust rootprefix.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] moved from systemd 195 to 225, unable to start custom services.

2017-11-17 Thread Shekhar arya 
Hi

I have upgraded my systemd from older version v195 (used in poky 1.6) to
v225 to resolve some of the memory leak issues. I have resolved all the
dependencies while compilation and now system boots fine. However, after
the boot is complete, systemd is not able to start services present in
/lib/systemd/system folder. These services where perfectly working fine
with previous version of systemd. Journalctl logs report /var/ and /tmp/
directories as read-only but in mount I can see them as read-write fs.
Below is the log which I referred. Am I missing something or does newer
version of systemd required certain more configurations to run the custom
services?

# Journalctl –no-pager

Jan 01 00:00:11 localhost systemd-journal[93]: Journal started

Jan 01 00:00:11 localhost systemd-sysctl[94]: Couldn't write 'fq_codel' to
'net/core/default_qdisc', ignoring: No such file or directory

Jan 01 00:00:11 localhost systemd-sysctl[94]: Couldn't write '16' to
'kernel/sysrq', ignoring: No such file or directory

Jan 01 00:00:11 localhost systemd-sysusers[113]: Failed to take lock:
Read-only file system

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: Failed to create directory
or subvolume "/var/volatile/log": No such file or directory

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: Failed to create directory
or subvolume "/var/volatile/tmp": No such file or directory

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: /tmp/volatile does not
exist and cannot be created as the file system is read-only.

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: Failed to create directory
or subvolume "/tmp/volatile/tmp": No such file or directory

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: Failed to create directory
or subvolume "/tmp/volatile/cache": No such file or directory

Jan 01 00:00:12 localhost systemd-tmpfiles[118]:
symlink(../proc/self/mounts, /etc/mtab) failed: Read-only file system

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: chmod(/home) failed:
Read-only file system

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: /srv does not exist and
cannot be created as the file system is read-only.

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: Failed to create file
/var/run/snmpd-env: No such file or directory

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: /var/lib/machines does not
exist and cannot be created as the file system is read-only.

Jan 01 00:00:12 localhost systemd-tmpfiles[118]: /var/lib/systemd/coredump
does not exist and cannot be created as the file system is read-only.




-- 
regards,
 - Shekhar
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [issue while upgrading systemd]

2017-11-17 Thread Shekhar arya 
Hi,

I have moved from older version of systemd (part of poky 1.6) to systemd
225 (poky 1.6). I have resolved all dependencies while compilation.
However,

-- 
regards,
 - Shekhar
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel