Shell login, needed?

[Thanatermesis]

I see in the logs that the graphical session is run from a shell login (zsh here), I wonder how much this is needed? do we need to keep a shell process for it? or it may be switched to a simply "run process" instead?

[wltjr]

Hi, that is a good question. I will have to do some research and experiment without a shell to see if that is possible. As long as the process has access to env variables, it might be possible.

[Thanatermesis]

Looking how LightDM does it, which seems to be very correct and stable code, if im not wrong all happens from here:

https://github.com/canonical/lightdm/blob/03f218981733e50d810767f9d04e42ee156f7feb/src/session-child.c#L242

Maybe the (almost) entirely code can be re-used for a correct session launching? :thinking:

[wltjr]

Thank you for that link. I briefly looked it over. It does seem to be a better approach. However, one difference between entrance and lightdm is the ~/.entrance_session.log. I would need to allow the running process some means to output session information to that log file. That might be why entrance is being run in a shell rather than stand alone process. Either way, I would need to ensure session information is still logged to that file. But that may have nothing to do with the shell and be able to accomplish the same without launching in a shell.

[Thanatermesis]

Lightdm saves the equivalent X process logs to ~/.xsession-errors which is probably a standard file (or at least a common one), https://github.com/canonical/lightdm/blob/03f218981733e50d810767f9d04e42ee156f7feb/src/session.c#L984

[Thanatermesis]

I don't know how much needed is a log file but maybe as a suggestion could be good to being able to disable it from the entrance conf file, this could avoid huge generation of logs, for example from new E's which logs a lot of ERR/CRI/INF messages to stdout/stderr

[wltjr]

I am open to dropping the shell and running in a stand alone process. But it will likely be sometime before I get around to this. I need to look into the issues with newer EFL as reported in #34. Then, I need to see about finishing dbus logind/elogind integration for Wayland. Since this is more a change/enhancement than issue to fix or new features, it will be low priority. It will just introduce new breakage at first I will need to fix, for something that works now, albeit not in an ideal manner. I have been fixing and changing all sorts of things since taking over the codebase.

It might also be a good idea to make the session log optional. Although, I seem to recall other things in the past writing to a session file of some name. They may not have been as noisy as EFL/E.