Re: [systemd-devel] User systemd unit files

2014-10-24 Thread Lennart Poettering
On Thu, 11.09.14 07:07, Chris Morgan (chmor...@gmail.com) wrote:

 Hmm. I figured that the environment was used when the systemd user
 instance was started.
 
 I tried systemctl --user set-environment and it shows up if I use
 show-environment but even if I use SYSTEMD_UNIT_PATH (I was typing on
 mobile and mistakenly typed USER instead of UNIT), and reloaded the
 daemon it doesn't appear to be taking effect, the test unit file I
 created isn't located.

SYSTEMD_UNIT_PATH should still work. You have to specify it in the
user@.service template unit file, then reload the daemon and restart
that service. Otherwise it will not take effect. Make sure to then
check if it is properly set by looking at /proc/$PID/environ for the
systemd user instance.

That all said, for testing purposes systemd-nspawn is probably the
much better idea. I mean, we wrote it only for the purpose of
testing...

Lennart

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


Re: [systemd-devel] User systemd unit files

2014-10-22 Thread Chris Morgan
On Wed, Oct 22, 2014 at 12:20 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 11.09.14 07:07, Chris Morgan (chmor...@gmail.com) wrote:

 Hmm. I figured that the environment was used when the systemd user
 instance was started.

 I tried systemctl --user set-environment and it shows up if I use
 show-environment but even if I use SYSTEMD_UNIT_PATH (I was typing on
 mobile and mistakenly typed USER instead of UNIT), and reloaded the
 daemon it doesn't appear to be taking effect, the test unit file I
 created isn't located.

 SYSTEMD_UNIT_PATH should still work. You have to specify it in the
 user@.service template unit file, then reload the daemon and restart
 that service. Otherwise it will not take effect. Make sure to then
 check if it is properly set by looking at /proc/$PID/environ for the
 systemd user instance.

 That all said, for testing purposes systemd-nspawn is probably the
 much better idea. I mean, we wrote it only for the purpose of
 testing...

 Lennart

 --
 Lennart Poettering, Red Hat


I ended up getting pretty much everything working.

Right now we are using the same service files on desktop as on
embedded (albeit they are being partially generated by cmake's
configure_file() macro)

To recap, on the desktop we:
- Generate service files from blah.service.in files during the build,
this lets us put in hardcoded paths etc for things that need them.
- Run a script that uses 'systemctl link' to link to the users systemd folder
- Run another script to start the services

On embedded side we:
- Generate the service files...
- Run the normal 'systemctl enable xxx'
- Let the system start the services up at boot time.


The only wrinkle I've run into is that the version of systemd on f20
is old and doesn't appear to support things like 'systemctl start
company*', so we have to iterate through a manually built list of
service names. I'm hoping f21 resolves this.

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


Re: [systemd-devel] User systemd unit files

2014-09-14 Thread Andrei Borzenkov
В Thu, 11 Sep 2014 07:07:16 -0400
Chris Morgan chmor...@gmail.com пишет:

 On Thu, Sep 11, 2014 at 5:03 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
  Chris Morgan wrote on 11/09/14 02:32:
 
  On Sep 10, 2014 5:46 PM, Zbigniew Jędrzejewski-Szmek
  zbys...@in.waw.pl mailto:zbys...@in.waw.pl wrote:
 
  On Tue, Sep 09, 2014 at 07:39:17PM -0400, Chris Morgan wrote:
 Specifically, running `systemd --user` directly is not supported
 anymore. The user mode still works, but only for one user
  instance
 per UID, launched through user@uid.service (recent releases
  start
 this automatically upon logging in).
Try 'systemctl --user'. If this start you can put units
it ~/.config/systemd/user/ or a similar path (check
  systemd.unit(5) out).
   
Zbyszek
  
   I tried --user but I get some errors that I pasted above. It looks
   like it is no longer supported but I'm not sure.
 
  If you're getting the same message as above, you are still typing
  systemd instead of systemctl.
 
  Zbyszek
 
  Ahh. The man page seemed to indicate that one should run systemd with
  --user first.
 
  I was able to run unit files via systemctl --user but the
  SYSTEMD_USER_PATH environment variable doesn't seem to be working, even
  though it is mentioned in the man page.
 
  Where are you setting this path? If systemd --user is already running
  (which happens automatically with newer systemd's) then you have to make
  sure *it* knows about the env var, not just the client side calls in.
 
  This *might* work, but I don't know for sure as I've not fiddled with
  this stuff.
 
  systemctl --user set-environment SYSTEMD_USER_PATH=$HOME/somegitrepo/units/
  systemctl --user daemon-reload
 
 
  Col
 
  --
 
  Colin Guthrie
  gmane(at)colin.guthr.ie
  http://colin.guthr.ie/
 
  Day Job:
Tribalogic Limited http://www.tribalogic.net/
  Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
 
 
 Hmm. I figured that the environment was used when the systemd user
 instance was started.
 
 I tried systemctl --user set-environment and it shows up if I use
 show-environment but even if I use SYSTEMD_UNIT_PATH (I was typing on
 mobile and mistakenly typed USER instead of UNIT), and reloaded the
 daemon it doesn't appear to be taking effect, the test unit file I
 created isn't located.
 

No, SYSTEMD_UNIT_PATH must be in environment of systemd; systemctl
set-environment sets different variables (which are not used for unit
lookup).

What you could do is to create *system* drop in file like

/etc/systemd/systemd/user@.service.d/environment.conf

with content similar to

[Service]
Environment=%h/somegitrepo/units

This should do it.

 I'm thinking I can use the 'systemctl link' command to link the
 scripts into the user folder. Basically after a build something like
 startup_and_start.sh could link each unit file and then call 'start'
 on them to start them up, simulating what would happen during system
 startup on the embedded side.
 
 Would need to build each unit file from a template as the full path
 would be needed but that shouldn't be tough.
 
 I appreciate the help from everyone here. It does look like
 SYSTEMD_UNIT_PATH was removed from newer versions of systemd and only
 XDG_xxxXXX is available, but that variable isn't mentioned at all in
 the man pages of my version of systemd, 208. Some of the confusion is
 between what systemd provides (systemd --user) and what, due to distro
 integration I should be using (systemctl --user), and I'm new to
 systemd.
 
 Chris
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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


Re: [systemd-devel] User systemd unit files

2014-09-11 Thread Colin Guthrie
Chris Morgan wrote on 11/09/14 02:32:
 
 On Sep 10, 2014 5:46 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl mailto:zbys...@in.waw.pl wrote:

 On Tue, Sep 09, 2014 at 07:39:17PM -0400, Chris Morgan wrote:
Specifically, running `systemd --user` directly is not supported
anymore. The user mode still works, but only for one user
 instance
per UID, launched through user@uid.service (recent releases
 start
this automatically upon logging in).
   Try 'systemctl --user'. If this start you can put units
   it ~/.config/systemd/user/ or a similar path (check
 systemd.unit(5) out).
  
   Zbyszek
 
  I tried --user but I get some errors that I pasted above. It looks
  like it is no longer supported but I'm not sure.

 If you're getting the same message as above, you are still typing
 systemd instead of systemctl.

 Zbyszek
 
 Ahh. The man page seemed to indicate that one should run systemd with
 --user first.
 
 I was able to run unit files via systemctl --user but the
 SYSTEMD_USER_PATH environment variable doesn't seem to be working, even
 though it is mentioned in the man page. 

Where are you setting this path? If systemd --user is already running
(which happens automatically with newer systemd's) then you have to make
sure *it* knows about the env var, not just the client side calls in.

This *might* work, but I don't know for sure as I've not fiddled with
this stuff.

systemctl --user set-environment SYSTEMD_USER_PATH=$HOME/somegitrepo/units/
systemctl --user daemon-reload


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] User systemd unit files

2014-09-11 Thread Chris Morgan
On Thu, Sep 11, 2014 at 5:03 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 Chris Morgan wrote on 11/09/14 02:32:

 On Sep 10, 2014 5:46 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl mailto:zbys...@in.waw.pl wrote:

 On Tue, Sep 09, 2014 at 07:39:17PM -0400, Chris Morgan wrote:
Specifically, running `systemd --user` directly is not supported
anymore. The user mode still works, but only for one user
 instance
per UID, launched through user@uid.service (recent releases
 start
this automatically upon logging in).
   Try 'systemctl --user'. If this start you can put units
   it ~/.config/systemd/user/ or a similar path (check
 systemd.unit(5) out).
  
   Zbyszek
 
  I tried --user but I get some errors that I pasted above. It looks
  like it is no longer supported but I'm not sure.

 If you're getting the same message as above, you are still typing
 systemd instead of systemctl.

 Zbyszek

 Ahh. The man page seemed to indicate that one should run systemd with
 --user first.

 I was able to run unit files via systemctl --user but the
 SYSTEMD_USER_PATH environment variable doesn't seem to be working, even
 though it is mentioned in the man page.

 Where are you setting this path? If systemd --user is already running
 (which happens automatically with newer systemd's) then you have to make
 sure *it* knows about the env var, not just the client side calls in.

 This *might* work, but I don't know for sure as I've not fiddled with
 this stuff.

 systemctl --user set-environment SYSTEMD_USER_PATH=$HOME/somegitrepo/units/
 systemctl --user daemon-reload


 Col

 --

 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/

 Day Job:
   Tribalogic Limited http://www.tribalogic.net/
 Open Source:
   Mageia Contributor http://www.mageia.org/
   PulseAudio Hacker http://www.pulseaudio.org/
   Trac Hacker http://trac.edgewall.org/


Hmm. I figured that the environment was used when the systemd user
instance was started.

I tried systemctl --user set-environment and it shows up if I use
show-environment but even if I use SYSTEMD_UNIT_PATH (I was typing on
mobile and mistakenly typed USER instead of UNIT), and reloaded the
daemon it doesn't appear to be taking effect, the test unit file I
created isn't located.

I'm thinking I can use the 'systemctl link' command to link the
scripts into the user folder. Basically after a build something like
startup_and_start.sh could link each unit file and then call 'start'
on them to start them up, simulating what would happen during system
startup on the embedded side.

Would need to build each unit file from a template as the full path
would be needed but that shouldn't be tough.

I appreciate the help from everyone here. It does look like
SYSTEMD_UNIT_PATH was removed from newer versions of systemd and only
XDG_xxxXXX is available, but that variable isn't mentioned at all in
the man pages of my version of systemd, 208. Some of the confusion is
between what systemd provides (systemd --user) and what, due to distro
integration I should be using (systemctl --user), and I'm new to
systemd.

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


Re: [systemd-devel] User systemd unit files

2014-09-10 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 09, 2014 at 07:39:17PM -0400, Chris Morgan wrote:
   Specifically, running `systemd --user` directly is not supported
   anymore. The user mode still works, but only for one user instance
   per UID, launched through user@uid.service (recent releases start
   this automatically upon logging in).
  Try 'systemctl --user'. If this start you can put units
  it ~/.config/systemd/user/ or a similar path (check systemd.unit(5) out).
 
  Zbyszek
 
 I tried --user but I get some errors that I pasted above. It looks
 like it is no longer supported but I'm not sure.

If you're getting the same message as above, you are still typing
systemd instead of systemctl.

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


Re: [systemd-devel] User systemd unit files

2014-09-10 Thread Chris Morgan
On Sep 10, 2014 5:46 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
wrote:

 On Tue, Sep 09, 2014 at 07:39:17PM -0400, Chris Morgan wrote:
Specifically, running `systemd --user` directly is not supported
anymore. The user mode still works, but only for one user
instance
per UID, launched through user@uid.service (recent releases
start
this automatically upon logging in).
   Try 'systemctl --user'. If this start you can put units
   it ~/.config/systemd/user/ or a similar path (check systemd.unit(5)
out).
  
   Zbyszek
 
  I tried --user but I get some errors that I pasted above. It looks
  like it is no longer supported but I'm not sure.

 If you're getting the same message as above, you are still typing
 systemd instead of systemctl.

 Zbyszek

Ahh. The man page seemed to indicate that one should run systemd with
--user first.

I was able to run unit files via systemctl --user but the SYSTEMD_USER_PATH
environment variable doesn't seem to be working, even though it is
mentioned in the man page. If I place them in ~/.config/systemd/units they
are recognized. I'm going to try a symlink from there to where I was hoping
to point via SYSTEMD_USER_PATH. Should I be setting XDG_CONFIG_HOME? I was
looking to put the files at ~/somegitrepo/units/

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


Re: [systemd-devel] User systemd unit files

2014-09-09 Thread Chris Morgan
On Mon, Sep 8, 2014 at 3:45 PM, Chris Morgan chmor...@gmail.com wrote:
 On Mon, Sep 8, 2014 at 3:30 PM, Mantas Mikulėnas graw...@gmail.com wrote:
 On Mon, Sep 8, 2014 at 9:27 PM, Chris Morgan chmor...@gmail.com wrote:
 Hello.

 We have a build environment that we use to build our software for
 desktop Linux and we are currently using Yocto to build for an
 embedded target.

 I'm looking for a way for developers to use the systemd unit files for
 our services out of their user owned build directory during
 development so we can use the same files during development that we
 would use during production.

 I came across 'systemd --user' but I'm not having much luck starting
 this up as my own user as it looked like $SYSTEMD_UNIT_PATH was
 exactly what I was looking to set.

 Fedora 20 cli output:

 $ /usr/lib/systemd/systemd --user
 Failed to create root cgroup hierarchy: Permission denied
 Failed to allocate manager object: Permission denied

 And some discussion on libreoffice pages seems to be indicating that
 'systemd --user' isn't supported any more.

 Specifically, running `systemd --user` directly is not supported
 anymore. The user mode still works, but only for one user instance
 per UID, launched through user@uid.service (recent releases start
 this automatically upon logging in).

 --
 Mantas Mikulėnas graw...@gmail.com


 Would support for the single user instance support what we are looking
 to do with our build setup?

 I'm open to mostly any approach but I'd prefer to use the unit files
 directly rather than a second script just for starting things up on
 the desktop environment. Plus it would let us test things like
 automatic service restart, logging etc.

 Chris


I'm not sure if I'm being clear with my question, if it would help to
explain more I would appreciate some questions that could help clarify
the usage case I'm trying to achieve.

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


Re: [systemd-devel] User systemd unit files

2014-09-09 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 09, 2014 at 10:15:06AM -0400, Chris Morgan wrote:
 On Mon, Sep 8, 2014 at 3:45 PM, Chris Morgan chmor...@gmail.com wrote:
  On Mon, Sep 8, 2014 at 3:30 PM, Mantas Mikulėnas graw...@gmail.com wrote:
  On Mon, Sep 8, 2014 at 9:27 PM, Chris Morgan chmor...@gmail.com wrote:
  Hello.
 
  We have a build environment that we use to build our software for
  desktop Linux and we are currently using Yocto to build for an
  embedded target.
 
  I'm looking for a way for developers to use the systemd unit files for
  our services out of their user owned build directory during
  development so we can use the same files during development that we
  would use during production.
I doubt that systemd services from the final system would be useful
for in the user session. Usually they include things like User=
and other settings which require privilege to set up, and are not supported
in the units for the user session.

If you were more specific in what your are trying to run, it'd be
be easier.

Zbyszek

  I came across 'systemd --user' but I'm not having much luck starting
  this up as my own user as it looked like $SYSTEMD_UNIT_PATH was
  exactly what I was looking to set.
 
  Fedora 20 cli output:
 
  $ /usr/lib/systemd/systemd --user
  Failed to create root cgroup hierarchy: Permission denied
  Failed to allocate manager object: Permission denied
 
  And some discussion on libreoffice pages seems to be indicating that
  'systemd --user' isn't supported any more.
 
  Specifically, running `systemd --user` directly is not supported
  anymore. The user mode still works, but only for one user instance
  per UID, launched through user@uid.service (recent releases start
  this automatically upon logging in).
Try 'systemctl --user'. If this start you can put units
it ~/.config/systemd/user/ or a similar path (check systemd.unit(5) out).

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


Re: [systemd-devel] User systemd unit files

2014-09-09 Thread Chris Morgan
On Tue, Sep 9, 2014 at 7:09 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Sep 09, 2014 at 10:15:06AM -0400, Chris Morgan wrote:
 On Mon, Sep 8, 2014 at 3:45 PM, Chris Morgan chmor...@gmail.com wrote:
  On Mon, Sep 8, 2014 at 3:30 PM, Mantas Mikulėnas graw...@gmail.com wrote:
  On Mon, Sep 8, 2014 at 9:27 PM, Chris Morgan chmor...@gmail.com wrote:
  Hello.
 
  We have a build environment that we use to build our software for
  desktop Linux and we are currently using Yocto to build for an
  embedded target.
 
  I'm looking for a way for developers to use the systemd unit files for
  our services out of their user owned build directory during
  development so we can use the same files during development that we
  would use during production.
 I doubt that systemd services from the final system would be useful
 for in the user session. Usually they include things like User=
 and other settings which require privilege to set up, and are not supported
 in the units for the user session.

 If you were more specific in what your are trying to run, it'd be
 be easier.

 Zbyszek


Sure. Linux environment, developing and testing on desktop, deploying
to Linux embedded system. There are several service-like applications
that we are using systemd to start/restart on the embedded side. I
wanted to see if we could use these unit files out of the developers
directory to start up the local builds of the service applications
etc. On the desktop side we build a fake root filesystem when we
compile the libraries and applications, like
/home/someuser/project/build/rootfs/ that has a bin/, share/ etc.

I've been looking at things like systemd-nspawn, calling passwd to
change my password on a f20 container inside of my f20 vm fails for
some reason, maybe because audit is enabled? Also started looking at
whether something like docker would make sense. I'm a bit new to
containers so I'm not even sure if this is a feasible alternative
approach.



  I came across 'systemd --user' but I'm not having much luck starting
  this up as my own user as it looked like $SYSTEMD_UNIT_PATH was
  exactly what I was looking to set.
 
  Fedora 20 cli output:
 
  $ /usr/lib/systemd/systemd --user
  Failed to create root cgroup hierarchy: Permission denied
  Failed to allocate manager object: Permission denied
 
  And some discussion on libreoffice pages seems to be indicating that
  'systemd --user' isn't supported any more.
 
  Specifically, running `systemd --user` directly is not supported
  anymore. The user mode still works, but only for one user instance
  per UID, launched through user@uid.service (recent releases start
  this automatically upon logging in).
 Try 'systemctl --user'. If this start you can put units
 it ~/.config/systemd/user/ or a similar path (check systemd.unit(5) out).

 Zbyszek


I tried --user but I get some errors that I pasted above. It looks
like it is no longer supported but I'm not sure.

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


Re: [systemd-devel] User systemd unit files

2014-09-08 Thread Mantas Mikulėnas
On Mon, Sep 8, 2014 at 9:27 PM, Chris Morgan chmor...@gmail.com wrote:
 Hello.

 We have a build environment that we use to build our software for
 desktop Linux and we are currently using Yocto to build for an
 embedded target.

 I'm looking for a way for developers to use the systemd unit files for
 our services out of their user owned build directory during
 development so we can use the same files during development that we
 would use during production.

 I came across 'systemd --user' but I'm not having much luck starting
 this up as my own user as it looked like $SYSTEMD_UNIT_PATH was
 exactly what I was looking to set.

 Fedora 20 cli output:

 $ /usr/lib/systemd/systemd --user
 Failed to create root cgroup hierarchy: Permission denied
 Failed to allocate manager object: Permission denied

 And some discussion on libreoffice pages seems to be indicating that
 'systemd --user' isn't supported any more.

Specifically, running `systemd --user` directly is not supported
anymore. The user mode still works, but only for one user instance
per UID, launched through user@uid.service (recent releases start
this automatically upon logging in).

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] User systemd unit files

2014-09-08 Thread Chris Morgan
On Mon, Sep 8, 2014 at 3:30 PM, Mantas Mikulėnas graw...@gmail.com wrote:
 On Mon, Sep 8, 2014 at 9:27 PM, Chris Morgan chmor...@gmail.com wrote:
 Hello.

 We have a build environment that we use to build our software for
 desktop Linux and we are currently using Yocto to build for an
 embedded target.

 I'm looking for a way for developers to use the systemd unit files for
 our services out of their user owned build directory during
 development so we can use the same files during development that we
 would use during production.

 I came across 'systemd --user' but I'm not having much luck starting
 this up as my own user as it looked like $SYSTEMD_UNIT_PATH was
 exactly what I was looking to set.

 Fedora 20 cli output:

 $ /usr/lib/systemd/systemd --user
 Failed to create root cgroup hierarchy: Permission denied
 Failed to allocate manager object: Permission denied

 And some discussion on libreoffice pages seems to be indicating that
 'systemd --user' isn't supported any more.

 Specifically, running `systemd --user` directly is not supported
 anymore. The user mode still works, but only for one user instance
 per UID, launched through user@uid.service (recent releases start
 this automatically upon logging in).

 --
 Mantas Mikulėnas graw...@gmail.com


Would support for the single user instance support what we are looking
to do with our build setup?

I'm open to mostly any approach but I'd prefer to use the unit files
directly rather than a second script just for starting things up on
the desktop environment. Plus it would let us test things like
automatic service restart, logging etc.

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