Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[MohanR]

On Fri, 2016-12-02 at 12:28 +, Simon McVittie wrote:
> Does this mean your user is trying to be physically present in two
> places
> at the same time? How is this a useful thing to do? :-)

I thought the same when I came across this requirement. People
explained me that the admins who are going to use our solution will
mostly be Windows Admins and they are scared (or lazy) to create
different accounts for each people. They also said this kind of setup
possible in Windows (but I don't know exactly how it works) and they
will require that kind of setup in Linux too.

> pam_systemd does not do this unless you have configured dbus-daemon
> to provide one bus per logind user-session
> (./configure --enable-user-session), which is not the default.
> Either you or your OS vendor have explicitly chosen this model: if
> that
> doesn't match your requirements, you need to revert this choice.
> 
> If you require multiple D-Bus sessions per logind user-session, you
> must
> either configure dbus without --enable-user-session (the default is
> equivalent to --disable-user-session), or mask or remove the
> dbus.service and dbus.socket systemd user units that are installed
> by enabling that option (/usr/lib/systemd/dbus.*).

I'm looking through this --enable-user-session in dbus-daemon. Even if
I enable that option, how can I retrive uniq DBUS_SESSION_BUS_ADDRESS
from systemd started dbus-daemon to pass it to gnome-session?

I think this is a silly requirement and will make our display-manager
stop user starting two sessions by checking with logind whether that
user already have a graphical session.

Thanks,
Mohan R
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Skipping temporary coredump file during coredump generation

[P.R.Dinesh]

During coredump generation I could find a temporary uncompressed file
getting generated from the corefile and written to the harddisk, later this
file is getting compressed (if compression was enabled) and then the file
coredump file is stored and this temporary file is removed.

I have a process whose memory consumption is typically around 5GB, it
generates around 13GB of uncompressed coredump ( coredump_filter = 0x33).
Later this file is compressed to 20MB and the uncompressed file is removed.
I have set the
ProcessSizeMax=16GB
ExternalSizeMax= 16GB
But sometimes my disk doesn't have sufficient space to store this temporary
file, hence systemd-coredump aborts the coredump processing.

Is it possible to skip this temporary file generation and generate the
compressed file directly from the Corefile passed through STDIN?

Is there any impact on doing so?
I tried modifying the coredump.c and was able to get this compressed file
directly from the core file.  But I am not sure on whether it will fail on
some scenarios or I am missing some important data.

Also please let me know if my understanding of systemd coredump behaviour
is wrong.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] mount-matrix support, user-space "done"

[Bastien Nocera]

Hey accelerometer lovers,

I have, bar any bugs obviously, finished adding support for "mount-
matrix" in iio-sensor-proxy.

The code reads the "ACCEL_MOUNT_MATRIX" udev property of the device,
which it will apply to raw readings. After testing, I will provide a
patch to systemd's hwdb to gather all the quirks that were provided to
me.

Note that, for now, I expect all those quirks to be added to the hwdb
file in systemd, even if available in Device Tree or the ACPI _PLD
property.

In both of those cases, as I don't have the hardware to test with,
somebody will need to add a rule to udev to extract the mount-matrix
property attached to the iio sensor device, using the "IMPORT". Hans?

For the _PLD, this isn't currently exported by the kernel at all. Maybe
a minimal version of this patch:
http://www.spinics.net/lists/linux-acpi/msg51540.html
could be added to the IIO subsystem so that the iio core exports the
information from both sources in the same way.

I expect Thomas and Carlos (both CC:'ed) to come back to me with the
quirks for their devices, so I can finalise the systemd/udev hwdb
patch, documentation included.

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

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Jóhann B . Guðmundsson]

On 12/02/2016 12:28 PM, Simon McVittie wrote:


Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do?:-)


Clones are very useful things to have.

You just sit a drink a pina colada in hut in bora bora while they do all 
the hard work ;)


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

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Simon McVittie]

On Fri, 02 Dec 2016 at 13:58:01 +0530, Mohan R wrote:
> Let say if a user already have a session(session0) in a seat (customseat0) and
> he want to start another session in another seat (customseat1).

Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do? :-)

> Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS 
> for
> every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is
> there any way to ask 'systemd --user' to provide different
> DBUS_SESSION_BUS_ADDRESS to the childs?

More background on user-sessions in general:
https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

pam_systemd does not do this unless you have configured dbus-daemon
to provide one bus per logind user-session
(./configure --enable-user-session), which is not the default.
Either you or your OS vendor have explicitly chosen this model: if that
doesn't match your requirements, you need to revert this choice.

If you require multiple D-Bus sessions per logind user-session, you must
either configure dbus without --enable-user-session (the default is
equivalent to --disable-user-session), or mask or remove the
dbus.service and dbus.socket systemd user units that are installed
by enabling that option (/usr/lib/systemd/dbus.*).

The user-session support in dbus is designed to be easy to enable or
disable by adding/removing packages, if your OS vendor packages it
suitably. For example, in Debian (including derivatives like Ubuntu),
/usr/lib/systemd/dbus.* are packaged separately in the dbus-user-session
package, so you can remove that package to go back to the older model.

If your OS vendor has not packaged dbus like that, perhaps ask them to
look at how it's done in Debian? Or if they have deliberately chosen
not to support multiple D-Bus sessions per logind user-session, then
that OS distribution is not suitable for your requirements, and you
need to change either your requirements or your OS distribution.

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

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Mantas Mikulėnas]

On Fri, Dec 2, 2016 at 10:28 AM, Mohan R  wrote:

> Hi,
>
> I'm working on a display-manager for a multiseat environment. Here is how
> we use logind
>
> 1. create new seat through udev
> 2. we set the XDG_SEAT in pamenv before calling pam_open_session()
> 3. we take XDG_SESSION_ID, XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS
> from pam_systemd
>
> Let say if a user already have a session(session0) in a seat (customseat0)
> and he want to start another session in another seat (customseat1). Our
> display manager would get the same DBUS_SESSION_BUS_ADDRESS from
> pam_systemd for session1.
>
> As we cannot use the same address for two sessions, we have to start
> dbus-session manually. Using the address provided by dbus-session as
> DBUS_SESSION_BUS_ADDRESS, we then proceed with starting gnome-keyring and
> gnome-session.
>
> Problem is, processes forked by 'systemd --user' will have
> DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" but processes
> forked by gnome-session will have DBUS_SESSION_BUS_ADDRESS=$
> DBUS_SESSION_PROVIDED_ADDRESS.
>
> Is there any way to make pam_systemd provides uniq
> DBUS_SESSION_BUS_ADDRESS for every session (may be
> unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is there any way to
> ask 'systemd --user' to provide different DBUS_SESSION_BUS_ADDRESS to the
> childs?
>

No, only one graphical session at a time is supported. While you can start
additional sessions using `dbus-run-session` or the old `dbus-launch` (and
have them run independently, "traditional way"), systemd --user will only
ever use the main user bus.

Also, if you made systemd specify different bus envvars for different
services, you wouldn't be able to start the same service for *both*
sessions at once...

(*Technically,* I suppose it would be possible to make logind start
per-session instances of --user and so on and so on, but as it is nothing
like that is supported.)

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Mohan R]

Hi,

I'm working on a display-manager for a multiseat environment. Here is how
we use logind

1. create new seat through udev
2. we set the XDG_SEAT in pamenv before calling pam_open_session()
3. we take XDG_SESSION_ID, XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS
from pam_systemd

Let say if a user already have a session(session0) in a seat (customseat0)
and he want to start another session in another seat (customseat1). Our
display manager would get the same DBUS_SESSION_BUS_ADDRESS from
pam_systemd for session1.

As we cannot use the same address for two sessions, we have to start
dbus-session manually. Using the address provided by dbus-session as
DBUS_SESSION_BUS_ADDRESS, we then proceed with starting gnome-keyring and
gnome-session.

Problem is, processes forked by 'systemd --user' will have
DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" but processes
forked by gnome-session will have
DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_PROVIDED_ADDRESS.

Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS
for every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)?
or is there any way to ask 'systemd --user' to provide different
DBUS_SESSION_BUS_ADDRESS to the childs?

Thanks,
Mohan R
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Martin Pitt]

Kai Krakow [2016-12-02  8:47 +0100]:
> Am Thu, 17 Nov 2016 18:53:53 +0100
> schrieb Lennart Poettering :
> > I now added a small extension to this line: "(to the level the
> > firmware permits this)" ot clarify that we are bound by firmware
> > limitations for this.
> I think this should be pointed out better. In the common case, with
> usual firmwares out there, names change in unpredictable ways if you
> swap hardware. This, of course, totally reverses what the man page says
> about "even when hardware is added/removed"...

It does not *totally* reverse it -- existing interface names remain
stable in a lot of cases actually, just not with your case where the
firmware decides to rearrange the numbering completely (which should
hopefully not be the majority of cases, given how few reports we get
about it). So IMHO the "(to the level the firmware permits this)"
qualification seems to adequately address that?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel