Re: [systemd-devel] systemd user instance not working in only one account, XDG_RUNTIME_DIR not being set

[Mantas Mikulėnas]

On Tue, Apr 11, 2023, 03:41 Chandler  wrote:

> systemd has been working great here, system-wide as well as in all user
> instances except one.  I'm not exactly sure what all the steps are in
> the process to get a systemd user instance running.  The directory
> /run/user/$UID was not being created, though.
>
> I made some progress by running `systemctl start
> user@.service` and the /run/user/$UID was created.
>
> `systemctl --user status` returns `Failed to connect to bus: No such
> file or directory`.  XDG_RUNTIME_DIR is not being set, but a command
> like `XDG_RUNTIME_DIR=/run/user/$UID systemctl --user status` runs
> successfully, so I think it's down to this last piece.
>

The same pam_systemd module registers a "session" with logind (which
triggers the creation of runtime directory as well as the startup of
user@.service;
note: *not* user@) and sets XDG_RUNTIME_DIR after the session has
been registered. Check whether your tty or display is shown in the
`loginctl` session list.

Note that logind does not allow registering sessions from within another
session, so tools like `su` won't be able to do that (except for some
situations where they can but you wouldn't want them to) – only a fresh
login gets you a session. So usually step 1 is to not use `su` or `sudo`
here – run `machinectl shell foo@` if you need a shell for a local user.

Re: [systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

Good to know! Thanks for googling for me!

On Mon, Nov 20, 2017 at 10:29 AM, Michael Biebl  wrote:

> 2017-11-20 19:26 GMT+01:00 Michael Biebl :
> > https://anonscm.debian.org/git/pkg-systemd/systemd.git/
> commit/debian/extra/pam.d/systemd-user?id=b3238e9604fa61c7ec45a2d0acc1f8
> b40728cd87
> >
> > This might be relevant to you.
> >
> > See how the pam config contains pam_limits
>
> This was a result of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838191
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Michael Biebl]

2017-11-20 19:26 GMT+01:00 Michael Biebl :
> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/debian/extra/pam.d/systemd-user?id=b3238e9604fa61c7ec45a2d0acc1f8b40728cd87
>
> This might be relevant to you.
>
> See how the pam config contains pam_limits

This was a result of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838191
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Michael Biebl]

https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/debian/extra/pam.d/systemd-user?id=b3238e9604fa61c7ec45a2d0acc1f8b40728cd87

This might be relevant to you.

See how the pam config contains pam_limits

2017-11-20 18:49 GMT+01:00 Lennart Poettering :
> On Mo, 20.11.17 09:47, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
>> I guess the answer is "no." :)
>>
>> This is Ubuntu 16.04. On CentOS7.3, pam_limits is part of systemd-user
>> through system-auth
>>
>> Here is /etc/pam.d/systemd-user from my Ubuntu system:
>>
>> # This file is part of systemd.
>> #
>> # Used by systemd --user instances.
>>
>> @include common-account
>>
>> session  required pam_selinux.so close
>> session  required pam_selinux.so nottys open
>> @include common-session-noninteractive
>> session optional pam_systemd.so
>
> Have you checked the snippets listed in the @include lines? Maybe they
> pull it in?
>
>> So on RHEL systems, it doesn't matter that is works because user instances
>> are officially not included and it just doesn't work on Ubuntu because
>> pam_limits is not used by systemd-user.
>>
>> I find it odd that two major distros differ in this behavior.
>
> PAM is a mess. Setups and syntax vary wildly between distros. It's sad.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

I have checked the snippets. "common-account" only deal with account
settings. "common-session-interactive" does not include a pam_limits entry.

On Mon, Nov 20, 2017 at 9:49 AM, Lennart Poettering 
wrote:

> On Mo, 20.11.17 09:47, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
> > I guess the answer is "no." :)
> >
> > This is Ubuntu 16.04. On CentOS7.3, pam_limits is part of systemd-user
> > through system-auth
> >
> > Here is /etc/pam.d/systemd-user from my Ubuntu system:
> >
> > # This file is part of systemd.
> > #
> > # Used by systemd --user instances.
> >
> > @include common-account
> >
> > session  required pam_selinux.so close
> > session  required pam_selinux.so nottys open
> > @include common-session-noninteractive
> > session optional pam_systemd.so
>
> Have you checked the snippets listed in the @include lines? Maybe they
> pull it in?
>
> > So on RHEL systems, it doesn't matter that is works because user
> instances
> > are officially not included and it just doesn't work on Ubuntu because
> > pam_limits is not used by systemd-user.
> >
> > I find it odd that two major distros differ in this behavior.
>
> PAM is a mess. Setups and syntax vary wildly between distros. It's sad.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

I guess the answer is "no." :)

This is Ubuntu 16.04. On CentOS7.3, pam_limits is part of systemd-user
through system-auth

Here is /etc/pam.d/systemd-user from my Ubuntu system:

# This file is part of systemd.
#
# Used by systemd --user instances.

@include common-account

session  required pam_selinux.so close
session  required pam_selinux.so nottys open
@include common-session-noninteractive
session optional pam_systemd.so

So on RHEL systems, it doesn't matter that is works because user instances
are officially not included and it just doesn't work on Ubuntu because
pam_limits is not used by systemd-user.

I find it odd that two major distros differ in this behavior.


On Mon, Nov 20, 2017 at 9:23 AM, Lennart Poettering 
wrote:

> On Mo, 20.11.17 09:20, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
> > Lennart,
> >
> > Your explanation sounds great but it's just not what I'm seeing.
> >
> > My user@.service has "PAMName=systemd-user" in the [Service] section.
> >
> > I have setup limits for the user in /etc/security/limits.d/foo.conf.
> >
> > I have no other limit overrides in any other systemd file.
> >
> > Whether I reboot or "systemctl restart user@" I see the same thing.
> > That is, the limits set through pam_limits are not respected.
> >
> > I consistently see that if I login as that user, then "ulimit -a" shows
> the
> > values I expect from pam_limits while "cat /proc//limits" for the
> user
> > instance process or its children do not.
>
> Is pam_limits even enabled for the "systemd-user" PAM fragment on your
> distro?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

Lennart,

Your explanation sounds great but it's just not what I'm seeing.

My user@.service has "PAMName=systemd-user" in the [Service] section.

I have setup limits for the user in /etc/security/limits.d/foo.conf.

I have no other limit overrides in any other systemd file.

Whether I reboot or "systemctl restart user@" I see the same thing.
That is, the limits set through pam_limits are not respected.

I consistently see that if I login as that user, then "ulimit -a" shows the
values I expect from pam_limits while "cat /proc//limits" for the user
instance process or its children do not.

On Mon, Nov 20, 2017 at 8:47 AM, Lennart Poettering 
wrote:

> On Mo, 20.11.17 08:32, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
> > I am using lingering and I have issued "systemctl restart user@"
> and
> > then seen the instance restart with a new PID. So I think I am restarting
> > the user instance.
> >
> > When Limit* directives are applied in "user@.service" or in
> > "/etc/systemd/system/user@.service.d/whatever.conf" I see that they are
> > respected in the user instance itself and the child processes it starts.
> >
> > However, I do NOT see settings applied through pam_limits
> > (/etc/security/limits.d etc etc) respected in the user instance although
> > Mantas implied that I should. Is this expected?
>
> When systemd executes a service that has PAM enabled, it will will
> first start the PAM session, which is where pam_limits does its
> thing. It then goes on setting up the execution environment for the
> service, and if resource limits are configured for the unit, they'll
> be put into effect. This means that any settings configured in the
> unit file they take precedence over the pam_limits settings.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Lennart Poettering]

On Mo, 20.11.17 09:20, Jeff Solomon (jsolomon8...@gmail.com) wrote:

> Lennart,
> 
> Your explanation sounds great but it's just not what I'm seeing.
> 
> My user@.service has "PAMName=systemd-user" in the [Service] section.
> 
> I have setup limits for the user in /etc/security/limits.d/foo.conf.
> 
> I have no other limit overrides in any other systemd file.
> 
> Whether I reboot or "systemctl restart user@" I see the same thing.
> That is, the limits set through pam_limits are not respected.
> 
> I consistently see that if I login as that user, then "ulimit -a" shows the
> values I expect from pam_limits while "cat /proc//limits" for the user
> instance process or its children do not.

Is pam_limits even enabled for the "systemd-user" PAM fragment on your
distro?

Lennart

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

Re: [systemd-devel] systemd user instance and raising limits

[Lennart Poettering]

On Mo, 20.11.17 08:32, Jeff Solomon (jsolomon8...@gmail.com) wrote:

> I am using lingering and I have issued "systemctl restart user@" and
> then seen the instance restart with a new PID. So I think I am restarting
> the user instance.
> 
> When Limit* directives are applied in "user@.service" or in
> "/etc/systemd/system/user@.service.d/whatever.conf" I see that they are
> respected in the user instance itself and the child processes it starts.
> 
> However, I do NOT see settings applied through pam_limits
> (/etc/security/limits.d etc etc) respected in the user instance although
> Mantas implied that I should. Is this expected?

When systemd executes a service that has PAM enabled, it will will
first start the PAM session, which is where pam_limits does its
thing. It then goes on setting up the execution environment for the
service, and if resource limits are configured for the unit, they'll
be put into effect. This means that any settings configured in the
unit file they take precedence over the pam_limits settings.

Lennart

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

Re: [systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

I am using lingering and I have issued "systemctl restart user@" and
then seen the instance restart with a new PID. So I think I am restarting
the user instance.

When Limit* directives are applied in "user@.service" or in
"/etc/systemd/system/user@.service.d/whatever.conf" I see that they are
respected in the user instance itself and the child processes it starts.

However, I do NOT see settings applied through pam_limits
(/etc/security/limits.d etc etc) respected in the user instance although
Mantas implied that I should. Is this expected?

On Mon, Nov 20, 2017 at 4:10 AM, Lennart Poettering 
wrote:

> On So, 19.11.17 16:57, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
> > > I didn't think that systemd paid one bit of attention to the settings
> > >> controlled by pam_limits?
> > >>
> > >
> > > The user@ instance runs user-controlled processes, much like cron
> would,
> > > so its service unit has PAM enabled as well.
> > >
> >
> > When I change pam_limits for a user via a file /etc/security/limits.d/,
> and
> > then restart the user instance, neither the user instance itself nor the
> > children of that instance are affected by those settings. OTOH, when I
> > login again as that user, that login session does have those custom
> limits
> > set.
> >
> > Based on your previous comment, I would have expected the user instance
> and
> > its child to show those custom limits. What did am I getting wrong?
>
> Note that user@.service is only restarted if you fully log out
> (i.e. all your sessions) and then login back again. And only when it
> is restarted the new limits will be applied to systemd --user.
>
> if you use lingering, then not even this will work, since after all
> you declare that way that for your user the user@.service instance
> shall stick around for system boot-up till shutdown. In that case,
> please just explicitly issue "systemctl restart user@….service" as
> root, so that the service is restarted.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Lennart Poettering]

On So, 19.11.17 16:57, Jeff Solomon (jsolomon8...@gmail.com) wrote:

> > I didn't think that systemd paid one bit of attention to the settings
> >> controlled by pam_limits?
> >>
> >
> > The user@ instance runs user-controlled processes, much like cron would,
> > so its service unit has PAM enabled as well.
> >
> 
> When I change pam_limits for a user via a file /etc/security/limits.d/, and
> then restart the user instance, neither the user instance itself nor the
> children of that instance are affected by those settings. OTOH, when I
> login again as that user, that login session does have those custom limits
> set.
> 
> Based on your previous comment, I would have expected the user instance and
> its child to show those custom limits. What did am I getting wrong?

Note that user@.service is only restarted if you fully log out
(i.e. all your sessions) and then login back again. And only when it
is restarted the new limits will be applied to systemd --user.

if you use lingering, then not even this will work, since after all
you declare that way that for your user the user@.service instance
shall stick around for system boot-up till shutdown. In that case,
please just explicitly issue "systemctl restart user@….service" as
root, so that the service is restarted.

Lennart

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

Re: [systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

> I didn't think that systemd paid one bit of attention to the settings
>> controlled by pam_limits?
>>
>
> The user@ instance runs user-controlled processes, much like cron would,
> so its service unit has PAM enabled as well.
>

When I change pam_limits for a user via a file /etc/security/limits.d/, and
then restart the user instance, neither the user instance itself nor the
children of that instance are affected by those settings. OTOH, when I
login again as that user, that login session does have those custom limits
set.

Based on your previous comment, I would have expected the user instance and
its child to show those custom limits. What did am I getting wrong?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance and raising limits

[Mantas Mikulėnas]

On Mon, Nov 20, 2017, 02:27 Jeff Solomon  wrote:

> Understood.
>
> I didn't think that systemd paid one bit of attention to the settings
> controlled by pam_limits?
>

The user@ instance runs user-controlled processes, much like cron would, so
its service unit has PAM enabled as well.


> I'm only interested in a user instance that is lingering and operates
> outside of a session.
>

They always run outside of a session, even if the start was triggered by
session creation.

>

> My goal is that the child processes of the user instance will have limits
> that I set. If I understand correctly, if those limits are to be higher
> than the system's hard limits, then the user instance itself must have
> those higher limits set on it, yes?
>

Yes, since it's a regular user process with the same user privileges as
those child processes.
-- 

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

Re: [systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

Understood.

I didn't think that systemd paid one bit of attention to the settings
controlled by pam_limits?

I'm only interested in a user instance that is lingering and operates
outside of a session.

My goal is that the child processes of the user instance will have limits
that I set. If I understand correctly, if those limits are to be higher
than the system's hard limits, then the user instance itself must have
those higher limits set on it, yes?

I appreciate that the user instance doesn't need higher limits itself and
that it is weird that the children of the user instance will have
difference limits than a logged in user, but that's fine.

It seems to me that the only use of the defaults set in
/etc/systemd/user.conf is to further restrict the user instance's children
beyond  whatever restrictions are set by the system itself. I had
mistakenly believed that since /etc/systemd/user.conf was a restricted
file, that setting it would override system settings but it doesn't because
it's read by the user instance after it's already running at the user.

Thanks for the tip regarding /etc/systemd/system/user@
.service.d/whatever.conf.

I did previously know that user@.service would work. For my application,
I'm interested in a single special user only however. I don't want these
customizations to apply to all users.

On Sun, Nov 19, 2017 at 12:22 PM, Mantas Mikulėnas 
wrote:

> On Sun, Nov 19, 2017, 22:01 Jeff Solomon  wrote:
>
>> Hi,
>>
>> Two questions.
>>
>> I want to raise the "number of files" limits for the user instance.
>>
>> First, I set DefaultLimitNOFILE to something higher than the global
>> system default in /etc/systemd/user.conf and I rebooted.
>>
>> Then I confirmed that the setting has taken effect:
>>
>> "systemctl --user show" showed the new DefaultLimitNOFILE and the unit
>> itself showed the higher setting of LimitNOFILE when I ran "systemctl
>> --user show foo".
>>
>> So far everything worked as expected.
>>
>> However, when I checked "cat /proc//limits" on the ExecStart process
>> of foo.service, I don't see the "number of files" limit has changed.
>>
>> What did I do wrong?
>>
>> Second question: if I want to raise the limit just for a single user, how
>> would I go about it?
>>
>> Making a change in user.conf would make it apply in all user instances
>> (assuming I could get it to work).
>>
>> I have found that if I create /etc/systemd/system/user@.service and
>> add LimitNOFILE to the [Service] section of that file, then it will do two
>> things. First, it actually works whereas editing user.conf did not. Second,
>> the change only applies to user  and not all users.
>>
>> I assume I'm not getting how systemd is supposed to work. So please
>> enlighten me.
>>
>> Thanks,
>>
>> Jeff
>>
>
>
> First reason:
>
> Limit* in user@.service is set by init before it starts the user
> instance. Init is privileged and can raise limits above the current hard
> limit. (The same could be done via pam_limit.)
>
> DefaultLimit* in user.conf is set by the user instance itself, which runs
> under your uid and does not have any special privileges. It cannot raise
> the limits beyond the current hard limit, just as the `ulimit` command
> cannot.
>
> Second reason:
>
> The defaults are for units – not for the service manager itself.
>
> So although the defaults are *read* successfully, they will only be
> applied when you start a service.
>
> If you want to raise limits for all users, best to do that via pam_limits.
> (Letting --user services have different limits than directly launched
> programs is likely to result in confusion.)
>
> If you want to override user@.service, you *do not have* to create an
> instance for every uid; you can just have "/etc/systemd/system/user@.service";
> that's how it looks in /usr/lib anyway.
>
> Though a better method is to use drop-in configuration to only extend the
> service with your new options, while still loading the rest from /usr.
> Search the systemd.unit manpage for "drop-in", and put your extensions
> in "/etc/systemd/system/user@.service.d/whatever.conf".
>
>> --
>
> Mantas Mikulėnas 
> Sent from my phone
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance

[Jóhann B. Guðmundsson]

On 05/06/2013 10:14 PM, Kai Krakow wrote:

Jóhann B. Guðmundsson johan...@gmail.com schrieb:


But now I want to (and need to) give some users cron-like abilities. I
discovered that systemd supports user instances - perfect!

Then install cronie...

That's the obvious solution but a little bit counter-productive with respect
to my question...



Systemd is not ready for users cron like behavior.

Not from a usability perspective ( complexity of time units vs cron's 
one liner ) and from the fact that there are cron features which cannot 
be support ( for now ) and of those that will not be supported.


I threw some ideas out there on the table in brno but how we might try 
to solve that ( from an user usability perspective ) but to do so, along 
with supporting few other things in the future like container ( startup 
) templates and the fact that the drop-in snippets in .d/*.conf does not 
scale very well ( due to it's own unit directory implementation ) I'm 
afraid we will need to rethink and reconstruct /etc/systemd/ directory 
structure sooner rather then later since it's slowly becoming too 
complex and ill manageable in the process.


Anyway basically just think of systemd timer units cron like 
implementation like systemd's (x)inetd replacement which only replaces 
it up to 80% - 90%


JBG

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

Re: [systemd-devel] systemd user instance

[Kai Krakow]

Kok, Auke-jan H auke-jan.h@intel.com schrieb:

 [Service]
 User=%I
 PAMName=systemd-shared
 
 ^^ this line is the cause of your problems, as the
 /etc/pam.d/systemd-shared file does not exist.

I thought this is virtually profided by pam_systemd.so? But I may try your 
suggestion.

Regards,
Kai

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

Re: [systemd-devel] systemd user instance

[Kai Krakow]

Jóhann B. Guðmundsson johan...@gmail.com schrieb:

 But now I want to (and need to) give some users cron-like abilities. I
 discovered that systemd supports user instances - perfect!
 Then install cronie...
 That's the obvious solution but a little bit counter-productive with
 respect to my question...
 
 
 Systemd is not ready for users cron like behavior.

Okay... Well, I did not expect a full replacement anyway. But...

 Not from a usability perspective ( complexity of time units vs cron's
 one liner ) and from the fact that there are cron features which cannot
 be support ( for now ) and of those that will not be supported.

True...

 I threw some ideas out there on the table in brno but how we might try
 to solve that ( from an user usability perspective ) but to do so, along
 with supporting few other things in the future like container ( startup
 ) templates and the fact that the drop-in snippets in .d/*.conf does not
 scale very well ( due to it's own unit directory implementation ) I'm
 afraid we will need to rethink and reconstruct /etc/systemd/ directory
 structure sooner rather then later since it's slowly becoming too
 complex and ill manageable in the process.

Yes, it looks a bit messy there but it is maintainable for me.

 Anyway basically just think of systemd timer units cron like
 implementation like systemd's (x)inetd replacement which only replaces
 it up to 80% - 90%

Sure.

...but: I just want some simple timers and just for a few users (maybe two 
or three) and these should be able to tear down the spawned process cleanly 
which cron really cannot do so well.

The nice features from systemd as a simple (more or less) cron replacement 
are:

* clean process teardown and keeping track of run-away processes
* very good logging capabilities
* easy to maintain cpu and io policies

Actually it's meant to be used for an application server which has to spawn 
and watch background jobs every now and then and keep user-initiated 
services running. I don't think that can be done right with cron. At least 
we had our headaches with that in the past and here systemd seems to come in 
just right and handy.

Thanks for an elaborated answer thou, I appreciate it.

PS: I know that cron is the better tool for launching simple one-liners...

Regards,
Kai

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

Re: [systemd-devel] systemd user instance

[Kai Krakow]

Well, actually the timers are a nice benefit only. We want to control user-
initiated background-services for a web application server with this and 
cron hasn't been our best friend for this in the past.

David Strauss da...@davidstrauss.net schrieb:

 I don't recommend spawning user instances of systemd just for their
 timer units to run. Each instance comes with a few MB of overhead, and
 you'll have no fun trying to spawn sessions in a way isolated from
 (but somehow integrated with) the PAM session initialization process.
 
 On Mon, May 6, 2013 at 3:14 PM, Kai Krakow hurikha...@gmail.com wrote:
 Jóhann B. Guðmundsson johan...@gmail.com schrieb:

 But now I want to (and need to) give some users cron-like abilities. I
 discovered that systemd supports user instances - perfect!

 Then install cronie...

 That's the obvious solution but a little bit counter-productive with
 respect to my question...

 Anyway, one has to take that route if everything else fails.

 Regards,
 Kai

 ___
 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] systemd user instance

[Jóhann B. Guðmundsson]

On 05/06/2013 09:44 PM, Kai Krakow wrote:

But now I want to (and need to) give some users cron-like abilities. I
discovered that systemd supports user instances - perfect!


Then install cronie...

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

Re: [systemd-devel] systemd user instance

[Kai Krakow]

Jóhann B. Guðmundsson johan...@gmail.com schrieb:

 But now I want to (and need to) give some users cron-like abilities. I
 discovered that systemd supports user instances - perfect!
 
 Then install cronie...

That's the obvious solution but a little bit counter-productive with respect 
to my question...

Anyway, one has to take that route if everything else fails.

Regards,
Kai

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

Re: [systemd-devel] systemd user instance

[David Strauss]

I don't recommend spawning user instances of systemd just for their
timer units to run. Each instance comes with a few MB of overhead, and
you'll have no fun trying to spawn sessions in a way isolated from
(but somehow integrated with) the PAM session initialization process.

On Mon, May 6, 2013 at 3:14 PM, Kai Krakow hurikha...@gmail.com wrote:
 Jóhann B. Guðmundsson johan...@gmail.com schrieb:

 But now I want to (and need to) give some users cron-like abilities. I
 discovered that systemd supports user instances - perfect!

 Then install cronie...

 That's the obvious solution but a little bit counter-productive with respect
 to my question...

 Anyway, one has to take that route if everything else fails.

 Regards,
 Kai

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



-- 
David Strauss
   | da...@davidstrauss.net
   | +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user instance

[Kok, Auke-jan H]

On Mon, May 6, 2013 at 2:44 PM, Kai Krakow hurikha...@gmail.com wrote:
 Hey list,

 I've built a server with systemd and it really worked out well. Fast booting
 (that means shorter maintenance times) and most important: Reliable service
 teardown and auto-restarts of crashed services. And yeah, I love the
 journal. I'm logging everything there.

 But now I want to (and need to) give some users cron-like abilities. I
 discovered that systemd supports user instances - perfect!

 So I enabled a session service for one user (actually, that's me):

 # sudo systemctl enable user@kakra.service

 But I cannot start it, and the user can neither. Starting it states in the
 journal:

 # sudo systemctl start user@kakra.service

 May 06 23:35:00 vweb002.jugendinfo.de systemd[1]: Starting User Manager for
 root...
 -- Subject: Unit user@kakra.service has begun with start-up
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 --
 -- Unit user@kakra.service has begun starting up.
 May 06 23:35:00 vweb002.jugendinfo.de systemd[4438]: Failed at step PAM
 spawning /usr/lib/systemd/systemd: Operation not permitted
 -- Subject: Process /usr/lib/systemd/systemd could not be executed
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 -- Documentation:
 http://www.freedesktop.org/wiki/Software/systemd/catalog/641257651c1b4ec9a8624d7a40a9e1e7
 --
 -- The process /usr/lib/systemd/systemd could not be executed and failed.
 --
 -- The error number returned while executing this process is 1.
 May 06 23:35:00 vweb002.xx.de systemd[1]: Started User Manager for root.
 -- Subject: Unit user@kakra.service has finished start-up
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 --
 -- Unit user@kakra.service has finished starting up.
 --
 -- The start-up result is done.

 Why does it say Starting user manager for root (and not my username) and
 why does it fail with pam? If I start systemd --user , then I can enable
 and run the user services defined in .config/systemd.

 The server is running Gentoo with systemd-201. Here's the systemd unit:

 kakra@vweb002 ~ $ cat /etc/systemd/system/user\@kakra.service
 #  This file is part of systemd.
 #
 #  systemd is free software; you can redistribute it and/or modify it
 #  under the terms of the GNU Lesser General Public License as published by
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.

 [Unit]
 Description=User Manager for %u
 After=systemd-user-sessions.service

 [Service]
 User=%I
 PAMName=systemd-shared

^^ this line is the cause of your problems, as the
/etc/pam.d/systemd-shared file does not exist.

 # in order to allow MEM_CG features to work, add memory:/ here
 ControlGroup=%R/user/%u/shared cpu:/
 ControlGroupModify=yes
 Type=notify
 ExecStart=-/usr/lib/systemd/systemd --user
 Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket

 [Install]
 Alias=user@%i.service


 # as user:
 # systemctl start user@kakra.service
 Failed to issue method call: Access denied


 kakra@vweb002 ~ $ cat /etc/pam.d/system-auth
 authrequiredpam_env.so
 authrequiredpam_unix.so try_first_pass likeauth nullok
 authoptionalpam_permit.so

 account requiredpam_unix.so
 account optionalpam_permit.so

 passwordrequiredpam_cracklib.so difok=2 minlen=8 dcredit=2
 ocredit=2 retry=3
 passwordrequiredpam_unix.so try_first_pass use_authtok
 nullok sha512 shadow
 passwordoptionalpam_permit.so

 session requiredpam_limits.so
 session requiredpam_env.so
 session requiredpam_unix.so
 session optionalpam_permit.so

 session optionalpam_loginuid.so
 session optionalpam_systemd.so


You can copy /etc/pam.d/login to /etc/pam.d/systemd-shared, and then
things should somewhat work. Additionally, you may want to copy the
dbus user session service files from
github.com/sofar/user-session-units to get user based dbus services
working.

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