Change default value of RemoveIPC in logind.conf

[msekletar]

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]

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.

[msekletar]

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]

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]

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

[poettering]

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]

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]

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";)

[CyberShadow]

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]

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]

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