[systemd-devel] systemd as a docker process manager

[Jeff Solomon]

This is a followup to this thread:

https://lists.freedesktop.org/archives/systemd-devel/2015-July/033585.html

To see if there are any new developments.

We have multi-process application that already uses systemd successfully.
Our customers want to put the application into a container and that
container should be docker because that is what they use. We can't use
systemd-nspawn or podman or whatever because our customers want to use
docker because they are already using docker for other applications.

I understand that containers are not a security technology but we want to
find a solution that allows us to run systemd in a docker container that
isn't blatantly less secure than systemd running outside of a container. I
have yet to find a way.

Fundamentally, the problem is that the systemd in the container require
read/write access to the host's /sys/fs/cgroup/systemd directory in order
to function at all. Even if the container isn't privileged, it's necessary
to mount the host's /sys/fs/cgroup directory inside the directory and let
the container write to it, you have a security hole that doesn't exist when
systemd is just run on the host. That hole is described here:

https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/

Using user namespaces doesn't help because then the container user wouldn't
have permission to write to the /sys/fs/cgroup/systemd.

Our application runs as a non-root user. The security concern is that any
user on the host who is in the docker group would be able to start a shell
inside the container as "container root" and then be able to get root on
the host. So basically membership in the docker group is equivalent to host
root.

Taking a step back - I wonder (mostly asking Lennart) if there is a way to
run systemd without it needing access to /sys/fs/cgroup/systemd? I'm sure
there isn't but I thought I would ask.

Also, we actually use the systemd user service and only need to use a few
of systemd's feature related to process management (ExecStart, ExecStop,
restart behavior, kill behavior, env vars).

I don't care about 97% of systemd features (resource management, private
whatevers). But the process management of systemd is the gold standard in
my opinion and we already use it which is why I want to continue to use it
inside of a container.

Is there a way to run systemd's user service without it having the system
systemd service as a parent?

Like I said, I'm just looking for process management.

Any thoughts or ideas Lennart? Thanks!

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

Re: [systemd-devel] loginctl hangs when run at boot time

[Jeff Solomon]

Thanks Lennart, I hear what you're saying but I'm still confused.

I can run any commands in the "User Data" section. And when I run
"systemctl" immediately prior to attempting to run loginctl (which hangs),
I see the following (snipped):

dbus.service  loaded
active running D-Bus System Message Bus
dbus.socket  loaded
active running D-Bus System Message Bus Socket
systemd-logind.service   loaded
active running Login Service

which makes me think that even though cloud-init and these two services all
run after basic.target, the two needed to loginctl to run successfully are
already running.

Additionally, the following command works:

systemd-run loginctl ...

I understand what you're saying about dead-lock, but when I run
systemd-run, all I'm really doing is changing the execution environment,
not the flow of my entire script, and loginctl works in that case.

I guess I still don't understand how your explanation makes sense given the
behavior I observe.

On Thu, Apr 5, 2018 at 1:42 AM, Lennart Poettering <lenn...@poettering.net>
wrote:

> On Mi, 04.04.18 23:19, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
> > Hi,
> >
> > On the CentOS7 AWS with the following systemd installed:
> >
> > systemd-219-42.el7_4.4.x86_64
> >
> > Any loginctl command that we try to run at boot time (during the AWS
> "user
> > data" section of cloud-init), will hang and then timeout.
> >
> > The same loginctl command run after you ssh into the box and become root,
> > works fine.
> >
> > I can currently get around this problem by running:
> >
> > systemd-run loginctl 
> >
> > which implies that something about the boot time execution environment
> > doesn't allow loginctl to run.
> >
> > When I strace the hanging command, I can see that it's waiting on
> > /run/dbus/system_bus_socket.
> >
> > I don't think I have a unit ordering problem because systemd-run is able
> to
> > run the command. It must be the environment.
> >
> > Sorry for what must be a dumb question, but what is different about the
> > execution environment at boot time that is preventing loginctl from
> running?
>
> loginctl is a client tool for systemd-logind, the communicatoin
> between both happens through dbus, hence both are client to
> dbus-daemon. Both systemd-logind and dbus-daemon are run during late
> boot (i.e. are ordered after basic.target). systemd-logind is bus
> activated, and dbus-daemon is socket activated, which means that as
> soon as dbus-daemon's socket unit is up (i.e. dbus.socket is started)
> any client (such as loginctl) connecting to it will implicitly wait
> first for dbus-daemon to be fully started, and then until logind to be
> fully started.
>
> Now, if you invoke loginctl from something that itself delays the boot
> process, then you might create a deadlock: you are waiting for
> dbus.service/systemd-logind.service to start-up but are at the same
> time blocking it from being started.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] loginctl hangs when run at boot time

[Jeff Solomon]

Hi,

On the CentOS7 AWS with the following systemd installed:

systemd-219-42.el7_4.4.x86_64

Any loginctl command that we try to run at boot time (during the AWS "user
data" section of cloud-init), will hang and then timeout.

The same loginctl command run after you ssh into the box and become root,
works fine.

I can currently get around this problem by running:

systemd-run loginctl 

which implies that something about the boot time execution environment
doesn't allow loginctl to run.

When I strace the hanging command, I can see that it's waiting on
/run/dbus/system_bus_socket.

I don't think I have a unit ordering problem because systemd-run is able to
run the command. It must be the environment.

Sorry for what must be a dumb question, but what is different about the
execution environment at boot time that is preventing loginctl from running?

Thanks,

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

Re: [systemd-devel] what is the best way to connect to another user's service (when root)?

[Jeff Solomon]

On the one hand, I understand your point. On the other hand, there are
three other ways of doing this:

systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid=
systemctl --user ...
su -l  -c "XDG_RUNTIME_DIR=/run/user/ systemctl --user"
machinectl --uid= shell /bin/systemctl --user ...

(I'm assuming the last way actually works. Does it?)

So I thought that my suggestion was an even cleaner way to accomplish the
same thing. I get that you don't want priv code to depend on unpriv code
but systemctl is a command line tool. It's up to the user if they want to
run it that way.






On Fri, Nov 24, 2017 at 5:05 AM, Lennart Poettering <lenn...@poettering.net>
wrote:

> On Do, 23.11.17 22:56, Jeff Solomon (jsolomon8...@gmail.com) wrote:
>
> > Hi,
> >
> > More questions about the systemd user service.
> >
> > Inside a script running as root, I want to control another user's
> service.
> >
> > I have found two ways to do this:
> >
> > systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid=
> > systemctl --user ...
> >
> > or:
> >
> > su -l  -c "XDG_RUNTIME_DIR=/run/user/ systemctl
> --user
> > ..."
> >
> > Both work.
> >
> > If there a better way to do this?
> >
> > My distros aren't recent enough to include "machinectl shell" but is that
> > the recommended way now?
> >
> > machinectl --uid= shell /bin/systemctl --user ...
> >
> > Perhaps there is not enough demand to justify it, but I would love if the
> > systemctl command itself had a way to specify that it should communicate
> > with a different user's service rather than system service or the calling
> > user's service. Something like:
> >
> > systemctl --uid= --user ..
> >
> > would be awesome.
>
> Hmm, sorry, but this is something we'll are unlikely to support in any
> special way. Making privileged code a client of unpriveled user code
> like this makes me feel very uncomfortable. Privileged code really
> should not transition and block on unprivileged user code likes
> this. Philosophically it has this feeling of being the wrong way
> round: the unpriv code should ask the priv code what it should do, it
> shouldn't be the priv code that asks the unpriv code, in any blocking
> way... I mean, the unpriv code can ultimately do whatever it wants,
> and priv code should not block on that for good. It's simply the wrong
> way round to design such a system, if you follow what i mean.
>
> Usually most usecase like that are better solved by making things
> asynchronous notifier based, and make the unpriv code just react to
> notifications, instead of synchronous call-ins...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] what is the best way to connect to another user's service (when root)?

[Jeff Solomon]

Hi,

More questions about the systemd user service.

Inside a script running as root, I want to control another user's service.

I have found two ways to do this:

systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid=
systemctl --user ...

or:

su -l  -c "XDG_RUNTIME_DIR=/run/user/ systemctl --user
..."

Both work.

If there a better way to do this?

My distros aren't recent enough to include "machinectl shell" but is that
the recommended way now?

machinectl --uid= shell /bin/systemctl --user ...

Perhaps there is not enough demand to justify it, but I would love if the
systemctl command itself had a way to specify that it should communicate
with a different user's service rather than system service or the calling
user's service. Something like:

systemctl --uid= --user ..

would be awesome.

Jeff
___
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]

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

[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 <lenn...@poettering.net>
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 <lenn...@poettering.net>
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 <lenn...@poettering.net>
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

[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 <lenn...@poettering.net>
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] 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 <lnyk...@redhat.com> 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 <lenn...@poettering.net>
> 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] 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

[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 <graw...@gmail.com>
wrote:

> On Sun, Nov 19, 2017, 22:01 Jeff Solomon <jsolomon8...@gmail.com> 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 <graw...@gmail.com>
> Sent from my phone
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

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

Machine stats (although I see the same behavior on Ubuntu and on Centos7.3):

$ systemctl --version
systemd 229
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

$ uname -a
Linux foo-ubuntu-vm1 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
LSB Version:
core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID: Ubuntu
Description:Ubuntu 16.04.3 LTS
Release:16.04
Codename:   xenial
___
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 <m...@very.puzzling.org>
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

[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

[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

[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 <m...@very.puzzling.org> 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

[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