Your message dated Sun, 10 Mar 2019 11:54:16 +0100
with message-id <[email protected]>
and subject line Re: systemd: Unable to disable mount of /run/user/$something
has caused the Debian Bug report #806885,
regarding systemd: Unable to disable mount of /run/user/$something
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
806885: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806885
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 215-17+deb8u2
Severity: normal
Dear Maintainer,
(thats mostly a bug/feature for upstream, please forward to wherever needed,
thanks).
It seems that the mounting of /run/user/$something as tmpfs can not be
disabled. Would be nice if it has an option for this.
Background / Use case: We have a login server here, the only way to
reach our internal machines. This is pretty restricted, down to the
inability of any new mount while the system is running. Yet, logind
does try to mount the /run/user/$id on every users login (well, inital
session creation), which gets denied.
As the directory gets created before the mount (and thankfully chmod
700 too), there is no trouble - it is there for whatever wants to use
it (nothing, really), but every mount try spits out an error.
An option to turn off this behaviour would be nice.
I tried setting RuntimeDirectorySize to 0, hoping that this may be
seen as "mount of size 0 isnt useful, not doing it". Well, no, it
still tries to mount it. If I allow mounts so i can test things, the
mount doesn't appear, as a tmpfs of size 0 doesn't work out inside the
tmpfs driver. But the mount call is still issued. As such, in the
restricted system, it spits out an error.
Not using logind would be a possibility, but it does other nice things
(killing user processes on logout, removing IPC, ...), so we would
like to keep it.
--
bye Joerg
--- End Message ---
--- Begin Message ---
Version: 239-1
On Wed, 02 Dec 2015 14:20:36 +0100 Joerg Jaspert <[email protected]> wrote:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
>
> Dear Maintainer,
>
> (thats mostly a bug/feature for upstream, please forward to wherever needed,
> thanks).
>
> It seems that the mounting of /run/user/$something as tmpfs can not be
> disabled. Would be nice if it has an option for this.
>
> Background / Use case: We have a login server here, the only way to
> reach our internal machines. This is pretty restricted, down to the
> inability of any new mount while the system is running. Yet, logind
> does try to mount the /run/user/$id on every users login (well, inital
> session creation), which gets denied.
>
> As the directory gets created before the mount (and thankfully chmod
> 700 too), there is no trouble - it is there for whatever wants to use
> it (nothing, really), but every mount try spits out an error.
>
> An option to turn off this behaviour would be nice.
Turns out, you can do that nowadays. The setup of the XDG_RUNTIME_DIR is
now handled by /lib/systemd/system/[email protected]
You can override this file (systemctl edit --full
[email protected]) and replace systemd-user-runtime-dir with
your own implementation.
This could be as simple as mkdir + chown, you might not even need the
ExecStop.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
