[systemd-devel] systemd as a docker process manager

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

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

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

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

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

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

t 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 scri

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

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/

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

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

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

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 So

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

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

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

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@" >

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

v 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? > > >&g

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

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 Solomo

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

> 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

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

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...@gmai

[systemd-devel] systemd user instance and raising limits

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"

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

or 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

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

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

[systemd-devel] systemctl --user roadmap question

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

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

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

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

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