For those joining us, TrueOS (formerly PC-BSD) has a display manager.
It involves a set of rather confusingly named programs. An rc shell
script named pcdm invokes a shell script named PCDMd, which invokes
xinit, which invokes a C++ program named PCDM-session, which invokes a C
program named pcdm-session, which invokes another shell script, which
invokes more shell scripts and runs the GUI login session. There's a
whole lot of mess in there and several outright bugs. I gave the TrueOS
people a couple of suggestions and fixes.
*
https://github.com/trueos/trueos-core/issues/260
*
https://github.com/trueos/trueos-core/issues/261
Ken Moore:
> I just wanted to point out that the code block you mention is there,
> but I am fairly certain I left disabled/disused via a compile flag in
> the main() function. That was just some random code I left in there
> while testing out an alternative to the PCDMd startup script. I may
> resurrect it later on with version 2 of PCDM, but my available time is
> still too limited to tackle this right now.
>
You should let the world help you. Laurent Bercot et al. can help you.
I can help you.
You've switched TrueOS from Mewburn rc to OpenRC. Laurent Bercot et al.
can help you because OpenRC can integrate with M. Bercot's s6 service
manager. You can get PCDM running under proper service management, done
by s6. Then you do not need *either* of the Poor Man's Dæmon
Supervisors that you have, neither the one written in shell script in
PCDMd nor the (as the bug report explains, broken) one written in C++ in
PCDM-session.
*
https://github.com/OpenRC/openrc/blob/master/s6-guide.md
*
http://www.mail-archive.com/supervision_at_list.skarnet.org/msg00848.html
*
https://github.com/trueos/pcbsd/blob/releng/10.3/src-qt5/PCDM/PCDMd#L52
*
https://github.com/trueos/pcbsd/blob/master/src-qt5/PCDM/src/main.cpp#L240
We can help you with more than that. We know how to do this stuff.
We've done it. The likes of M. Bercot, Gerrit Pape, Wayne Marshall, me,
and others all look at your pcdm-session program and the first thought
(if my experience is anything to go by) is that it is setuidgid done ...
well ... very oddly. Again, you can just use tools like s6-setuidgid
rather than reinventing this particular wheel.
*
http://www.skarnet.org/software/s6/s6-setuidgid.html
*
https://github.com/trueos/pcbsd/blob/releng/10.3/src-qt5/PCDM/src/pcdm-session.c#L35
In fact, I have successfully replaced your entire pcdm-session program
with my two tools setuidgid and userenv, as follows:
#!/bin/sh -
chown -v -h -- "$1" "${XAUTHORITY}"
exec >>"$5" 2>&1 \
setuidgid --supplementary "$1" \
userenv --set-path --set-other --set-tools --set-timezone
--set-locale \
sh "$4"
This illustrates the benefits of your not reinventing this particular
wheel. Not only have we already written toolsets to handle this sort of
stuff, we've written far more capable tools than what you are
reinventing. My userenv, for example, is designed to set up the
environment variables relevant to a user account. It actually
understands the FreeBSD login.conf system, and so with a couple of
general-purpose tools, rather than a custom PC-BSD program, I actually
get *better* functionality. All of my PCDM login sessions now get all
of the environment variables set up that I have in ~/.login_conf and
/etc/login.conf . And I don't get an extra process, running as me,
sitting around in the process list, doing nothing more than waiting for
a child process to terminate.
Which brings us to other obvious things that we have some expertise in.
All of these programs that start background desktop applications leave
unnecessary shell processes lying around. The lesson from the
daemontools world that can be usefully applied here is to ensure that
they overlay the shell processes with the main program, by using "exec".
*
https://github.com/trueos/pcbsd/tree/releng/10.3/src-qt5/xtrafiles/local/share/pcbsd/xdg-auto
These leave processes around parented to process #1, not all of which
properly exit when the X server goes away. Martin Misuth has been
working on cleaning up all the dross left around by services, which
covers desktop sessions, using subreapers.
We even know how to run display managers under proper service
management. I've been running TrueOS/PC-BSD under nosh service
management for years, now. I've been running PCDM under proper service
management since before nosh version 1.25, back in January 2016. I've
done all of the work to turn PCDMd and its collection of subordinate
shell scripts into a more coherent system that runs as a service under a
service manager, including even the "firstboot" session and the display
wizard fallback. I've even done part of the work of stopping it using
global flag files in /tmp, which is both a security problem and
something that stands in the way of the goal of having multiple PCDM GUI
login sessions running simultaneously as multiple services.
There's more in that vein relating to the fact that the Desktop Bus
people are changing from per-session desktop buses to per-user desktop
buses, and this is visibly heading down the tunnel towards you. (-:
This means adjusting your on-the-fly shell scripts that the PCDM-session
program writes to invoke Desktop Bus differently or even not at all.
Again, I've done this. I have per-user service managers. I have
per-user Desktop Bus servers. I have the XDG user runtime directories.
I have per-user Unicode rxvt daemons. I even have a
setenv=DBUS_SESSION_BUS_ADDRESS=unix\cpath=/run/user/$/bus in
~/.login_conf, which (again) the userenv tool picks up quite nicely.
And there are several chapters in the nosh Guide on how this all works.
And this is all published.
Received on Sat Jan 14 2017 - 13:58:34 UTC