Folks,
Sorry to revisit such an old thread, but issues raised there
seem to still apply to most recent images (both ivi and mobile).
The problem is that logging in via serial-console (ssh/sdb)
causes whole user session to start - this includes X11 server
on mobile and wayland on ivi.
I have briefly looked into logind-exported stuff (/run/systemd/
{seat,session}) hoping that something could be used to decide if
GUI stuff should be started or not. Seats export CAN_GRAPHICAL
variable. In our case we always have one seat ("seat0") and
CAN_GRAPHICAL is always set ("=1"). My understanding is that
each physical serial line would be distinct seat (with
CAN_GRAPHICAL=0). Network lines would be handled differently.
Anyway, fixing this correctly requires considerable amount of time
I don't currently have.
Kai proposed moving pam_systemd to PAM config used by
user-session-launch only which seems sensible workaround.
Could you give us hint how this should be solved? Is using
Kai's workaround ok still with you?
Cheers,
--
Karol Lewandowski, Samsung R&D Institute Poland
On 01/07/2014 07:18 PM, Kok, Auke-jan H wrote:
> On Tue, Jan 7, 2014 at 2:14 AM, Yin Kangkai <[email protected]> wrote:
>> On 2014-01-06, 11:06 -0800, Patrick McCarty wrote:
>>> What PAM config changes would you propose?
>>
>> bash-4.2# diff -urN /etc/pam.d/ pam.d.new/
>> diff -urN /etc/pam.d/system-auth pam.d.new/system-auth
>> --- /etc/pam.d/system-auth 2013-12-16 14:27:47.000000000 -0800
>> +++ pam.d.new/system-auth 2013-02-12 20:54:28.000000000 -0800
>> @@ -11,7 +11,6 @@
>> password required pam_deny.so
>>
>> session optional pam_keyinit.so revoke
>> -session optional pam_systemd.so
>> session required pam_limits.so
>> session [success=1 default=ignore] pam_succeed_if.so service in crond
>> quiet use_uid
>> session required pam_unix.so
>> diff -urN /etc/pam.d/systemd-user pam.d.new/systemd-user
>> --- /etc/pam.d/systemd-user 2013-12-19 13:45:35.000000000 -0800
>> +++ pam.d.new/systemd-user 2013-02-12 20:54:59.000000000 -0800
>> @@ -4,5 +4,6 @@
>>
>> account include system-auth
>> session include system-auth
>> +session optional pam_systemd.so
>> auth required pam_deny.so
>> password required pam_deny.so
>> diff -urN /etc/pam.d/user-session-launcher pam.d.new/user-session-launcher
>> --- /etc/pam.d/user-session-launcher 1969-12-31 16:00:00.000000000 -0800
>> +++ pam.d.new/user-session-launcher 2013-02-12 20:54:59.000000000 -0800
>> @@ -0,0 +1,9 @@
>> +#%PAM-1.0
>> +
>> +# Used by systemd when launching systemd user instances.
>> +
>> +account include system-auth
>> +session include system-auth
>> +session optional pam_systemd.so
>> +auth required pam_deny.so
>> +password required pam_deny.so
>> bash-4.2#
>>
>> /etc/pam.d/user-session-launcher is just a link/copy to
>> /etc/pam.d/systemd-user
>
> this isn't such a bad idea - at least temporarily...
>
>> This can make sure systemd user session launches the whole UI, but
>> login and su don't.
>>
>> Downside of this change is that sessions opened by login and su are
>> not tracked in their own session tree, they're all in system session
>> tree. But this is acceptable I think.
>
> makes it harder to work with `systemctl --user`, so that's a downside again.
>
>>> If there should be only *one* instance of a service (e.g. a middleware
>>> service), then we should move it to the system session, but it wouldn't
>>> run as "app" in this case.
>>
>> Yes, they can? with specifying "User=app" in service file.
>
> either run them as root, or run them as User=pulse (for example). But
> never as User=app...
>
>>> would be useful to configure the default target on a per-user basis,
>>> possibly in /etc/systemd/logind.conf, so that we have more flexibility
>>> in specifying per-user units to start.
>>
>> Yeah good idea. is that do-able with current systemd? or we have to
>> cook the patch...
>
> ln -sf some.target ~/.config/systemd/user/default.target
>
> been possible since systemd-40 or so... :^)
>
> Auke
>
>>
>> Regards,
>> Kangkai
> _______________________________________________
> Dev mailing list
> [email protected]
> https://lists.tizen.org/listinfo/dev
>
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
