Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change default value of RemoveIPC in logind.conf #2039

Closed
msekletar opened this issue Nov 26, 2015 · 10 comments
Closed

Change default value of RemoveIPC in logind.conf #2039

msekletar opened this issue Nov 26, 2015 · 10 comments
Labels

Comments

@msekletar
Copy link
Contributor

@msekletar msekletar commented Nov 26, 2015

We received bug reports that default of RemoveIPC=yes in logind.conf may break 3rd party software not shipped as part of distribution. For example, consider software running various daemons which use SYSV or Posix defined IPC mechanism for communication and synchronization. At the same time, there is some maintenance script scheduled with cron which runs under same UID as daemons mentioned before. In such case, session will be created for this user and once cron job ends then session is released and given user has no active sessions (from logind's POV). logind will then do cleanup of allocated IPC resources, which is wrong because they still maybe needed by the daemon processes.

@poettering
Copy link
Member

@poettering poettering commented Nov 26, 2015

Well, it's configurable, because it can break stuff.

But I am pretty sure the usecase you describe is borked... The cleanup stuff already excludes system users, i.e. all daemon users. As it appears the customer created a non-system account for this stuff, and that's what should be fixed.

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

Sorry.

@poettering poettering closed this Nov 26, 2015
@msekletar
Copy link
Contributor Author

@msekletar msekletar commented Nov 27, 2015

Ahh, I missed that if statement in clean_ipc. There is really nothing to fix in systemd then. At any rate, thanks for looking it this.

@ringerc
Copy link

@ringerc ringerc commented Jul 11, 2016

Overall this seems like a helpful change. From a sysadmin PoV I'd really like to know more about what the behaviour is expected to be though.

Related thread: https://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html

What does systemd consider a "system user" for this purpose? The thread there discusses a hardcoded uid, but reached no clear conclusion. There's no "system user" flag in the traditional password database. Are you using a uid threshold from login.defs as was discussed as a possibility in that thread?

Where's the system user specific part of this behaviour documented? I found a note in NEWS:

        * logind will now automatically remove all IPC objects owned
          by a user if she or he fully logs out. This makes sure that
          users who are logged out cannot continue to consume IPC
          resources. This covers SysV memory, semaphores and message
          queues as well as POSIX shared memory and message
          queues. Traditionally, SysV and POSIX IPC had no life-cycle
          limits. With this functionality, that is corrected. This may
          be turned off by using the RemoveIPC= switch of logind.conf.

but it doesn't describe the system uesr behaviour. Similarly, in man/logind.conf.xml

        <term><varname>RemoveIPC=</varname></term>

        <listitem><para>Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the
        user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the
        last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as
        well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users
        are excluded from the effect of this setting. Defaults to <literal>yes</literal>.</para></listitem>

it mentions system users, but doesn't define what systemd considers to be a "system user", how to make a user a system user, what consequences or other behaviour differences are experienced by system users, etc.

Is the system-user-ness of a user tied to sysusers.d or is that just a convenience mechanism for creating system users?

Is there any wrapper command that allows a user to spawn a daemon that survives their session for where legacy behaviour is needed? Or a systemd API a wrapper (or something like pg_ctl) could call? I couldn't find one when I went looking. Or can a "normal" user be exempted on a user-by-user basis from RemoveIPC, perhaps via some group membership? Again, I didn't find any such mechanism when I looked.

For sites that manage deployed service users via LDAP, etc, is there any way they can safely create "system users" in their directory that won't suffer from uid collisions vs local users?

This is useful enough that I don't think most sites will want to just turn it off, but they're going to have to unless there's enough information to actually use it correctly.

@ringerc
Copy link

@ringerc ringerc commented Jul 12, 2016

Examination of the code shows that it seems to use thelogin.defs user threshold ... determined at compile time.

@poettering
Copy link
Member

@poettering poettering commented Jul 12, 2016

This is an issue tracker, not a support forum. Please direct your questions to a proper support forum, such as the systemd mailing lists. Thank you.

@oberstet
Copy link

@oberstet oberstet commented Aug 1, 2016

The default of this option should be off.

It has cost me literally many days to track down PostgreSQL instability to this (a collegue found this).

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

Your arrogance is breathtaking.

@oberstet
Copy link

@oberstet oberstet commented Aug 1, 2016

For others coming along, Oracle Linux has configured away this misfeature by default: https://docs.oracle.com/cd/E52668_01/E67200/html/section-t51_kcn_f5.html

They call it a feature "intended for laptops";)

@evverx evverx mentioned this issue Nov 1, 2016
1 of 2 tasks complete
@CyberShadow
Copy link
Contributor

@CyberShadow CyberShadow commented Feb 12, 2017

Hello,

But I am pretty sure the usecase you describe is borked... The cleanup stuff already excludes system users, i.e. all daemon users. As it appears the customer created a non-system account for this stuff, and that's what should be fixed.

What about situations such as ...

  • The user launched a background task using disown and logs out

  • The user has a program running in a screen/tmux session

  • The user has a cronjob configured, and the program launched from the cronjob is running at the moment when the user logs out (or their SSH connection drops)

I think systemd should check whether the user has any processes running, not just whether they have any active login sessions.

@semmerson
Copy link

@semmerson semmerson commented Nov 27, 2017

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

I agree. Capricious and arbitrary changes should not be sacrificed on the alter of backward-compatibility.

@ringerc
Copy link

@ringerc ringerc commented Nov 28, 2017

@poettering It's being discussed here because it's a misfeature/bug for which changes are being suggested.

@systemd systemd locked and limited conversation to collaborators Nov 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.