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

[Jeff Solomon]

That is good to hear and I look forward to seeing it enabled in el8!

On Mon, Nov 20, 2017 at 7:43 AM, Lukas Nykryn  wrote:

> That comment explains why --user was removed when centos7 was released.
> Although now we know that it will remain as it is in upstream, we don't
> plan to revert the removal in el7, since we are afraid of potential
> regressions that it might cause. I personally saw couple of logs where
> users had some automation that was creating tens of new ssh sessions every
> minute and if we would start systemd instance for every single one of them
> it would have negative effect on performance, which is not something we can
> do in late minor releases.
>
> Lukas
>
> On 17 November 2017 at 18:29, Lennart Poettering 
> wrote:
>
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lukas Nykryn]

That comment explains why --user was removed when centos7 was released.
Although now we know that it will remain as it is in upstream, we don't
plan to revert the removal in el7, since we are afraid of potential
regressions that it might cause. I personally saw couple of logs where
users had some automation that was creating tens of new ssh sessions every
minute and if we would start systemd instance for every single one of them
it would have negative effect on performance, which is not something we can
do in late minor releases.

Lukas

On 17 November 2017 at 18:29, Lennart Poettering 
wrote:

> 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 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?

[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?

[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?

[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?

[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?

[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

[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

[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] systemctl --user on RHEL -- is this a bad idea

[Michael Chapman]

On Thu, 9 Nov 2017, Jeff Solomon wrote:

Hi Michael,

Good to know. Do you count on lingering or on starting the user service on 
first login?


Well, both work, but the main reason I've made this change is so that I 
can enable lingering on users and run persistent user-specific services.

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

Re: [systemd-devel] systemctl --user on RHEL -- is this a bad idea

[Jeff Solomon]

Hi Michael,

Good to know. Do you count on lingering or on starting the user service on 
first login?

> On Nov 7, 2017, at 11:01 PM, Michael Chapman  wrote:
> 
>> On Wed, 8 Nov 2017, Jeff Solomon wrote:
>> Hi,
>> 
>> I would like to use a user service (systemctl --user) with systemd on RHEL7
>> where it has been deliberately removed.
>> 
>> I've communicated with the RH dev who made this change who reported that I
>> could restore the /lib/systemd/system/user@.service file and mostly
>> everything would work.
> 
> I've been dropping 0004-remove-user-.service.patch from RHEL's systemd 
> packages since RHEL 7.2, when Red Hat bumped systemd up from v208 to v219. I 
> haven't encountered any problems with this change.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl --user on RHEL -- is this a bad idea

[Michael Chapman]

On Wed, 8 Nov 2017, Jeff Solomon wrote:

Hi,

I would like to use a user service (systemctl --user) with systemd on RHEL7
where it has been deliberately removed.

I've communicated with the RH dev who made this change who reported that I
could restore the /lib/systemd/system/user@.service file and mostly
everything would work.


I've been dropping 0004-remove-user-.service.patch from RHEL's systemd 
packages since RHEL 7.2, when Red Hat bumped systemd up from v208 to v219. 
I haven't encountered any problems with this change.

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

[systemd-devel] systemctl --user on RHEL -- is this a bad idea

[Jeff Solomon]

Hi,

I would like to use a user service (systemctl --user) with systemd on RHEL7
where it has been deliberately removed.

I've communicated with the RH dev who made this change who reported that I
could restore the /lib/systemd/system/user@.service file and mostly
everything would work.

I don't care about having the user service exist only when the user is
logged in, as I will enable lingering on the service and I want it to be
running from boot to shutdown.

I've found that I can run:

systemctl start user@foo

to start the foo user's service and that works, but on other systems
(Ubuntu) where user services are officially supported, the user service is
automatically started when I run:

  loginctl enable-linger foo

whereas on RHEL, running this command does not start the service.

I can imagine writing a tiny additional service on RHEL that will start the
user service using:

ExecStart=/usr/bin/systemctl start user@foo

but I'd rather make lingering officially work on RHEL to the extent that
that is possible.

Two questions:

1) Any idea how to make lingering work such that the user service is
started automatically on reboot

2) Is it a really dumb idea to try to make this work on RHEL7?

Thanks!

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

Re: [systemd-devel] systemctl --user fails because no D-BUS.

[Reindl Harald]

Am 24.03.2016 um 20:26 schrieb Tomasz Torcz:

On Thu, Mar 24, 2016 at 08:01:23PM +0200, Mantas Mikulėnas wrote:

On Thu, Mar 24, 2016 at 6:21 PM, Flavio Leitner  wrote:


Hi,

I am trying to create services and timers per user but on a recent
CentOS minimal installation it doesn't work out of the box:

$ ssh 
server$ systemctl --user daemon-reload
Failed to get D-Bus connection: No such file or directory



First check `systemctl status user@$UID.service` to make sure you actually
*have* a `systemd --user` instance, as some distros have ripped it out
entirely.


  ”Some distros” include CentOS:
https://git.centos.org/blob/!!!rpms!systemd.git/4e2e74ff857d63b164391a16e8a42c78e8a935be/SOURCES!0004-remove-user-.service.patch


likely because of the logspam only relevant for systemd developers but 
making sysadmins blind by burry inetersting stuff which was rejected to fix





signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl --user fails because no D-BUS.

[Tomasz Torcz]

On Thu, Mar 24, 2016 at 08:01:23PM +0200, Mantas Mikulėnas wrote:
> On Thu, Mar 24, 2016 at 6:21 PM, Flavio Leitner  wrote:
> 
> >
> > Hi,
> >
> > I am trying to create services and timers per user but on a recent
> > CentOS minimal installation it doesn't work out of the box:
> >
> > $ ssh 
> > server$ systemctl --user daemon-reload
> > Failed to get D-Bus connection: No such file or directory
> >
> 
> First check `systemctl status user@$UID.service` to make sure you actually
> *have* a `systemd --user` instance, as some distros have ripped it out
> entirely.

 ”Some distros” include CentOS:
https://git.centos.org/blob/!!!rpms!systemd.git/4e2e74ff857d63b164391a16e8a42c78e8a935be/SOURCES!0004-remove-user-.service.patch


-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia

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

Re: [systemd-devel] systemctl --user fails because no D-BUS.

[Flavio Leitner]

On Thu, 24 Mar 2016 20:01:23 +0200
Mantas Mikulėnas  wrote:

> On Thu, Mar 24, 2016 at 6:21 PM, Flavio Leitner  wrote:
> 
> >
> > Hi,
> >
> > I am trying to create services and timers per user but on a recent
> > CentOS minimal installation it doesn't work out of the box:
> >
> > $ ssh 
> > server$ systemctl --user daemon-reload
> > Failed to get D-Bus connection: No such file or directory
> >  
> 
> First check `systemctl status user@$UID.service` to make sure you actually
> *have* a `systemd --user` instance, as some distros have ripped it out
> entirely.

$ id
uid=1000(centos)

$ systemctl status user@1000.service
● user@1000.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

No service, checking the RPM:
# rpm -ql systemd | grep 'user@.service' 

# rpm -q systemd
systemd-219-19.el7_2.4.x86_64

Fedora has that apparently:
$ rpm -ql systemd | grep 'user@.service' 
/usr/lib/systemd/system/user@.service


> Some other systems don't configure pam_systemd for ssh, so check `loginctl`
> to see if systemd-logind was told about your login (that's what triggers
> the automatic start of user@.service).

That seems fine: 
# loginctl list-users | grep 1000
  1000 centos  

> Also check if $XDG_RUNTIME_DIR exists (normally it should point at
> /run/user/$UID), and if $XDG_RUNTIME_DIR/systemd/private exists (should be
> a Unix socket).

Also seems to be fine:
$ export | grep XDG_RUNTIME_DIR
declare -x XDG_RUNTIME_DIR="/run/user/1000"

> > I found some websites talking about creating a session with dbus-launch
> > command, but that is packaged by dbus-x11, so it didn't make too much
> > sense for me as I am not using anything related to x11.
> >  
> 
> `systemd --user` does not use a session bus anyway, as it runs outside any
> sessions. It will try to start a "user bus" if the system's dbus is
> configured to support it (as in Debian's "dbus-user-session"). It will also
> listen on a private socket in $XDG_RUNTIME_DIR/systemd/, whether a user bus
> is available or not.

That is very helpful and makes sense with my debugging so far.
 
> (Neither the user bus nor XDG have anything to do with "x11 vs non-x11".)

Yup, but I got confused by the error message and the package's name :-)

I've looked at the systemd rpm's changelog and found this:
- everything: remove traces of --user (#1071363)

It seems one can't delete an user because a process (systemd-$user) is
left behind.

Thanks a lot!
-- 
fbl

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

Re: [systemd-devel] systemctl --user fails because no D-BUS.

[Mantas Mikulėnas]

On Thu, Mar 24, 2016 at 6:21 PM, Flavio Leitner  wrote:

>
> Hi,
>
> I am trying to create services and timers per user but on a recent
> CentOS minimal installation it doesn't work out of the box:
>
> $ ssh 
> server$ systemctl --user daemon-reload
> Failed to get D-Bus connection: No such file or directory
>

First check `systemctl status user@$UID.service` to make sure you actually
*have* a `systemd --user` instance, as some distros have ripped it out
entirely.

Some other systems don't configure pam_systemd for ssh, so check `loginctl`
to see if systemd-logind was told about your login (that's what triggers
the automatic start of user@.service).

Also check if $XDG_RUNTIME_DIR exists (normally it should point at
/run/user/$UID), and if $XDG_RUNTIME_DIR/systemd/private exists (should be
a Unix socket).


> I found some websites talking about creating a session with dbus-launch
> command, but that is packaged by dbus-x11, so it didn't make too much
> sense for me as I am not using anything related to x11.
>

`systemd --user` does not use a session bus anyway, as it runs outside any
sessions. It will try to start a "user bus" if the system's dbus is
configured to support it (as in Debian's "dbus-user-session"). It will also
listen on a private socket in $XDG_RUNTIME_DIR/systemd/, whether a user bus
is available or not.

(Neither the user bus nor XDG have anything to do with "x11 vs non-x11".)

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

[systemd-devel] systemctl --user fails because no D-BUS.

[Flavio Leitner]

Hi,

I am trying to create services and timers per user but on a recent
CentOS minimal installation it doesn't work out of the box:

$ ssh 
server$ systemctl --user daemon-reload
Failed to get D-Bus connection: No such file or directory

I found some websites talking about creating a session with dbus-launch
command, but that is packaged by dbus-x11, so it didn't make too much
sense for me as I am not using anything related to x11.

Looking at dbus-daemon man-page it says the daemon is started each time
a logs in, but I couldn't find what should do that for text only logins.

What am I missing?

Thanks,
-- 
fbl

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

Re: [systemd-devel] systemctl user start Xorg

[arnaud gaboury]

 Perhaps
 /etc/X11/Xwrapper.config
 needs_root_rights = auto
 allowed_users = anybody

I placed the Xwrapper.config, but the xorg.service still fails

My unit files :

$XDG_CONFIG_HOME/systemd/user/xorg.service

[Unit]
Description=Xorg server at display :0
Requires=xorg.socket
After=xorg.socket

[Service]
ExecStart=/usr/bin/Xorg.bin -nolisten tcp :0 vt1

[Install]
WantedBy=wm.target



$XDG_CONFIG_HOME/systemd/user/xorg.socket

[Unit]
Description=Xorg Server Socket

[Socket]
ListenStream=/tmp/.X11-unix/X0

[Install]
WantedBy=sockets.target


$ systemctl --user status xorg
● xorg.service - Xorg server at display :0
   Loaded: loaded (/home/gabx/.config/systemd/user/xorg.service; enabled)
   Active: failed (Result: start-limit) since Mon 2014-11-03 17:40:09
CET; 2min 0s ago
  Process: 825 ExecStart=/usr/bin/Xorg.bin -nolisten tcp :0 vt1
(code=exited, status=1/FAILURE)
 Main PID: 825 (code=exited, status=1/FAILURE)

Nov 03 17:40:09 hortensia Xorg.bin[825]: (EE)
Nov 03 17:40:09 hortensia Xorg.bin[825]: Please consult the The X.Org
Foundation support
Nov 03 17:40:09 hortensia Xorg.bin[825]: at http://wiki.x.org
Nov 03 17:40:09 hortensia Xorg.bin[825]: for help.
Nov 03 17:40:09 hortensia systemd[759]: xorg.service: main process
exited, code=exited, status=1/FAILURE
Nov 03 17:40:09 hortensia systemd[759]: Failed to start Xorg server at
display :0.
Nov 03 17:40:09 hortensia systemd[759]: Unit xorg.service entered failed state.
Nov 03 17:40:09 hortensia systemd[759]: Starting Xorg server at display :0...
Nov 03 17:40:09 hortensia systemd[759]: xorg.service start request
repeated too quickly, refusing to start.
Nov 03 17:40:09 hortensia systemd[759]: Failed to start Xorg server at
display :0.


Xorg.0.log
---
...
[ 5.471] (++) using VT number 1

[ 5.471] (WW) xf86OpenConsole: setpgid failed: Operation not permitted
[ 5.471] (WW) xf86OpenConsole: setsid failed: Operation not permitted
[ 5.471] (EE)
Fatal server error:
[ 5.471] (EE) xf86OpenConsole: Cannot open virtual console 1
(Permission denied)
[ 5.471] (EE)


Thank you for any suggestions
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemctl user start Xorg

[arnaud gaboury]

Archlinux 3.16.3
systemd 216-3
startx at login prompt. No DM


I am slowly trying to use systemctl --user facilities.
Until now, I am able to start few basic user services. Now it is time
to start Xorg as a user service, but I can't manage to do it. As
documentation is currently very sparse, I must admit I am a little
lost when it comes to write the unit files. I can't even know if it is
feasible.

I have tried all kinds of things in my xorg.service file. Below are
two ways among others.
---
[Unit]
Description=Xorg server at display :0
Requires=xorg.socket
After=xorg.socket

[Service]
# ExecStart=/usr/bin/Xorg.bin -nolisten tcp vt$XDG_VTNR
 ExecStart=/usr/bin/xinit -- :0 -nolisten tcp vt$XDG_VTNR
--

Results are usually failed status. Here are some logs:
---
● xorg.service - Xorg server at display :0
   Loaded: loaded (/home/gabx/.config/systemd/user/xorg.service; static)
   Active: failed (Result: exit-code) since Thu 2014-10-30 10:22:34 CET; 39s ago
  Process: 11792 ExecStart=/usr/bin/Xorg.bin -nolisten tcp vt$XDG_VTNR
(code=exited, status=1/FAILURE)
 Main PID: 11792 (code=exited, status=1/FAILURE)

Oct 30 10:22:34 hortensia systemd[850]: Started Xorg server at display :0.
Oct 30 10:22:34 hortensia Xorg.bin[11792]: use: X [:display] [option]
Oct 30 10:22:34 hortensia Xorg.bin[11792]: -a #
default pointer acceleration (factor)
Oct 30 10:22:34 hortensia Xorg.bin[11792]: -ac
disable access control restrictions
Oct 30 10:22:34 hortensia systemd[850]: xorg.service: main process
exited, code=exited, status=1/FAILURE
Oct 30 10:22:34 hortensia systemd[850]: Unit xorg.service entered failed state.
---
● xorg.service - Xorg server at display :0
   Loaded: loaded (/home/gabx/.config/systemd/user/xorg.service; static)
   Active: failed (Result: exit-code) since Thu 2014-10-30 10:42:17
CET; 1min 8s ago
  Process: 12191 ExecStart=/usr/bin/xinit -- :0 -nolisten tcp
vt$XDG_VTNR (code=exited, status=1/FAILURE)
 Main PID: 12191 (code=exited, status=1/FAILURE)

Oct 30 10:42:02 hortensia systemd[850]: Started Xorg server at display :0.
Oct 30 10:42:02 hortensia xinit[12191]: /usr/bin/Xorg.wrap: Only
console users are allowed to run the X server
Oct 30 10:42:17 hortensia systemd[850]: xorg.service: main process
exited, code=exited, status=1/FAILURE
Oct 30 10:42:17 hortensia systemd[850]: Unit xorg.service entered failed state.
---

I even tried to set $XDG_VTNR variable this way:
$ systemctl --user set-environment XDG_VTNR=1



Some info about my system:

gabx@hortensia ➤➤ ~ % systemctl --user status
● hortensia
State: running
 Jobs: 0 queued
   Failed: 0 units
Since: Thu 2014-10-30 11:09:46 CET; 18min ago
   CGroup: /user.slice/user-1000.slice/user@1000.service
   ├─852 /usr/lib/systemd/systemd --user
   ├─853 (sd-pam)
   ├─dbus.service
   │ └─2238 /usr/bin/dbus-daemon --session --address=systemd:
--nofork --systemd-activation
   ├─tmux.service
   │ ├─900 /usr/bin/tmux new-session -d -n irc irssi  zsh
   │ ├─901 zsh -c irssi  zsh
   │ └─906 irssi
   ├─urxvtd.service
   │ └─1394 /usr/bin/urxvtd -o -q -f
   ├─gpg-agent.service
   │ └─898 /usr/bin/gpg-agent --homedir
/home/gabx/.config/gnupg --daemon --write-env-file
/home/gabx/.config/gnupg/gpg-agent.info
   └/home/g─ssh-agent.service
 └─892 /usr/bin/ssh-agent -d -a /run/user/1000/ssh_auth_sock
-
gabx@hortensia ➤➤ ~ % systemctl --user show-environment
DISPLAY=:0
HOME=/home/gabx
LANG=en_US.UTF-8
LC_COLLATE=C
LOGNAME=gabx
MAIL=/var/spool/mail/gabx
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
SHELL=/usr/bin/zsh
USER=gabx
XDG_RUNTIME_DIR=/run/user/1000
--
gabx@hortensia ➤➤ ~ % systemd-cgls
├─1 /usr/lib/systemd/systemd
├─system.slice
│ ├─dbus.service
│ │ └─608 /usr/bin/dbus-daemon --system --address=systemd: --nofork
--nopidfile --systemd-activation
│ ├─lvm2-lvmetad.service
│ │ └─365 /usr/bin/lvmetad -f
│ ├─systemd-machined.service
│ │ └─843 /usr/lib/systemd/systemd-machined
│ ├─mysqld.service
│ │ └─519 /usr/bin/mysqld --pid-file=/run/mysqld/mysqld.pid
│ ├─adb.service
│ │ └─583 adb -P 5037 fork-server server
│ ├─systemd-journald.service
│ │ └─200 /usr/lib/systemd/systemd-journald
│ ├─system-devmon.slice
│ │ └─devmon@gabx.service
│ │   ├─ 549 /bin/bash /usr/bin/devmon
│ │   └─1098 /usr/sbin/udevil --monitor
│ ├─udisks2.service
│ │ └─2202 /usr/lib/udisks2/udisksd --no-debug
│ ├─systemd-timesyncd.service
│ │ └─463 /usr/lib/systemd/systemd-timesyncd
│ ├─systemd-logind.service
│ │ └─590 /usr/lib/systemd/systemd-logind
│ ├─systemd-networkd.service
│ │ └─675 /usr/lib/systemd/systemd-networkd
│ ├─systemd-udevd.service

Re: [systemd-devel] systemctl user start Xorg

[poma]

On 30.10.2014 12:20, arnaud gaboury wrote:
...
 Oct 30 10:42:02 hortensia systemd[850]: Started Xorg server at display :0.
 Oct 30 10:42:02 hortensia xinit[12191]: /usr/bin/Xorg.wrap: Only
 console users are allowed to run the X server
 Oct 30 10:42:17 hortensia systemd[850]: xorg.service: main process
 exited, code=exited, status=1/FAILURE
 Oct 30 10:42:17 hortensia systemd[850]: Unit xorg.service entered failed 
 state.
...


Perhaps 
/etc/X11/Xwrapper.config
needs_root_rights = auto
allowed_users = anybody

man 1 Xorg.wrap


poma


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

[systemd-devel] systemctl --user

[Damien Robert]

From Lennart Poettering, the Fri 03 Aug 2012 at 21:49:11 (+0200):
  However, this is not the case when running a systemd --user, then systemctl
  --user foo.service will not print the corresponding journal logs, even if
  there are some. So here is to a feature request :)
 
 This definitely makes snese. Added to the TODO list now.

Great!
 
  so something like journalctl _SYSTEMD_CGROUP='the right regular expression'
  could print them, but journalctl does not seem to support regular
  expression yet.
 
 regexes are really hard to index by, so I doubt we will support them.

You are right, it is probably more of the resort of a perl script to parse
the output of journalctl -o verbose. I'll try to write one.
 
 The journal bits in systemctl status are currently completely
 unprepared for --user, we really need to fix that.

Ok. I have to say that even if systemd --user is not yet completely ironed out,
it is really great and it allowed me to dismiss runsvdir that I was using
previously to launch my user services.

I will describe here my setup if other people are interested (or if you see
a better way to do it!), along with some bugs I found and other feature
requests that could be nice.

So when I log in, there are different types of services that I want to
launch:
1) services that I want always running (and if they exit, I want systemd to
   restart them): think offlineimap, mpd, ...
2) services that are linked to my current X session, think things you would
   put in ~/.xprofile or ~/.config/autostart like conky, ... Here I want
   these services to be restarted by systemd, except when I am closing the
   X session. And if I have several X session, I want one such service  by
   X session.
3) Eventually you could imagine services like (1), but that I want to stop
   whenever I have no active sessions anymore. Since I have no use such
   services, I have not implemented that.

So (1) is really easy, this is exactly what systemd is for. I regroup all
such services under session.target. The nice thing is that (2) is quite
easy to do using templates, whereas I could not do that previously with 
runsvdir. So I have a xsession@.target:
  [Unit]
  Description=xsession on display %I
  Wants=session.target
  AllowIsolate=yes
where I put my X session services (not that it automatically pull the
session services). For instance here is my conky@.service:

  [Unit]
  Description=conky on display %I 
  BindsTo=xsession@.target
  ConditionPathExists=%h/.conkyrc
  
  [Service]
  Environment=DISPLAY=%I
  ExecStart=/usr/bin/conky
  Restart=always
  RestartSec=1
  StandardOutput=null
  
  [Install]
  WantedBy=xsession@.target
  Also=xwatch@.service

So when I login, I launch systemctl --user start xsession@$DISPLAY.target
by putting this code in my ~/.xprofile:

  if [ -x /bin/systemd ]; then
xhost + SI:localuser:`id -u -n`
if [ systemctl --user --no-pager 2/dev/null ]; then
   systemctl --no-block --user  start xsession@${DISPLAY}.target
else
exec systemd --user --unit=xsession@${DISPLAY}.target 
fi
  fi

Some explanations: before running systemctl --user, I want to make sure
that systemd --user is running, or if not launch it. That's what the 
  if [ systemctl --user --no-pager 2/dev/null ]; 
is for.

A note about the xhost line: if I log on a X session with a new $DISPLAY,
since systemd is running from my first session, it may happen that the new
X session has not the same XDG_SESSION_COOKIE, and there will be
authorization problems when programs try to connect to the new X display.
The xhost line allow all programs with my uid to connect to the new X
session (it is there by default with gdm, but not when I log using startx
from a console).

Now the only thing left to do is to launch systemctl --user stop
xsession@$DISPLAY.target when I leave the current X session.
Because of the   BindsTo=xsession@.target, it will close the conky running
inside it. That is what the xwatch@.service is for:

  [Unit]
  Description=Watch for X on display %I
  BindsTo=xsession@.target
  
  [Service]
  Environment=DISPLAY=%I
  ExecStart=/home/username/script/services/xwatch %I
  
  [Install]
  WantedBy=xsession@.target

where xwatch is

  #!/bin/sh
  xprop -spy -root XFree86_VT
  echo systemctl --user stop xsession@$1.target
  systemctl --user stop xsession@$1.target

xprop is just the program I have chosen to communicate with the X socket (I
want a program that is not likely to crash, and this way I even know on
which VT the X session was launched in my logs). When the X session closes,
the xprop program terminates, and xwatch runs systemctl --user stop
xsession@$1.target.

For (3), I have no need for it, but we could imagine a service timer that parse 
the results of ck-list-session, and stop the services when I have no seat
left.

Now for the bugs:
1) The specifiers (%something) work only when starting a service, not
loading it. For instance:
  ConditionPathExists=%h/.conkyrc
gives an error:
  Path in