Session Manager and 'non-login' shells

32 views
Skip to first unread message

Kimmo

unread,
Feb 3, 2026, 3:58:54 AM (8 days ago) Feb 3
to TurboVNC User Discussion/Support
Hi,

When a session is started within the Session Manager the shells inside the session are 'non-login'-type while a session started via SSH using command 'vncserver' have 'login'-type shells. In 'non-login'-type shells e.g. the '/etc/profile' isn't sourced. 

What would be the most elegant way to make sessions started with Session Manager to be 'login'-type? Or is there one?

Kimmo

unread,
Feb 3, 2026, 4:16:21 AM (8 days ago) Feb 3
to TurboVNC User Discussion/Support
Clarification to the original post:

The shells inside all sessions are actually 'non-login' type, but the sessions started using Session Manager don't source '/etc/profile'. This causes some environmental variables set using '/etc/profile' not to load.

What would be the most elegant way to source '/etc/profile' for new session while using Session Manager?

DRC

unread,
Feb 4, 2026, 9:47:35 AM (7 days ago) Feb 4
to turbovn...@googlegroups.com
I can't reproduce the issue.  For me, /etc/profile is sourced properly
for all connections made through the Session Manager.  Is there
additional information that might help me reproduce the problem, such as
a special configuration on the host?

DRC

Kimmo

unread,
Feb 5, 2026, 2:35:26 AM (6 days ago) Feb 5
to TurboVNC User Discussion/Support
Hi,

I will do some more testing but the system is pretty stock Ubuntu 22.04.5. and can't think of any settings that would affect this. The TurboVNC version is 'TurboVNC Server v3.2.91 (build 20251222)'. The /etc/turbovncserver.conf has only 'wm' and 'resolution' set. I found out if I log in with SSH and start a session by running the 'vncserver'-command, the session inherits the correct environmental variables. So when the session starts it never sources /etc/profile or ~/.profile. However it sources /etc/bash.bashrc and ~/.bashrc. To me this indicates the session starts somehow as "non-login"-type if you get what I mean. I will let you know if I find out more.

Michael D. Setzer II

unread,
Feb 5, 2026, 4:28:27 AM (6 days ago) Feb 5
to turbovn...@googlegroups.com
On 4 Feb 2026 at 23:35, Kimmo wrote:
Date sent: Wed, 4 Feb 2026 23:35:26 -0800 (PST)
From: Kimmo <kimmo.h...@gmail.com>
To: TurboVNC User Discussion/Support <turbovn...@googlegroups.com>
Subject: Re: [TurboVNC-Users] Re: Session Manager and 'non-login' shells
>
> Hi,
>
> I will do some more testing but the system is pretty stock Ubuntu
> 22.04.5. and can't think of any settings that would affect this. The
> TurboVNC version is 'TurboVNC Server v3.2.91 (build 20251222)'. The
> /etc/turbovncserver.conf has only 'wm' and 'resolution' set. I found out if I
> log in with SSH and start a session by running the 'vncserver'-command,
> the session inherits the correct environmental variables. So when the
> session starts it never sources /etc/profile or ~/.profile. However it
> sources /etc/bash.bashrc and ~/.bashrc. To me this indicates the session
> starts somehow as "non-login"-type if you get what I mean. I will let you
> know if I find out more.
>
On my setup (Fedora 42 on this machine) have this.
tail -n2 /etc/sysconfig/tvncservers
VNCSERVERS="PP:msetzerii"
VNCSERVERARGS[PP]="-wm xfce -geometry 1920x1080"
# rpm -qa | grep -i Turbo
libjpeg-turbo-3.1.2-1.fc42.x86_64
libjpeg-turbo-devel-3.1.2-1.fc42.x86_64
turbojpeg-3.1.2-1.fc42.x86_64
libjpeg-turbo-3.1.2-1.fc42.i686
libjpeg-turbo-devel-3.1.2-1.fc42.i686
turbovnc-3.2.91-20251222.x86_64
My file only has comments??
# cat /etc/turbovncserver.conf
##
## TurboVNC Server Configuration
##
## This file uses Perl syntax, although only one-line assignments
## are allowed.  Assignments can be applied to the following variables:
##
##  $autokill    -- 1 to automatically kill the TurboVNC session when the
##                  X startup script exits or 0 to leave it running
##                  [equivalent of -noautokill command-line option]
##  $depth       -- color depth in bits per pixel (8, 16, 24, 30, or 32)
##                  [equivalent of -depth command-line option]
##  $desktopName -- remote desktop name
##                  [equivalent of -name command-line option]
##  $fontPath    -- X11 font path
##                  [equivalent of -fp command-line option]
##  $generateOTP -- 1 to generate an initial one-time password.  (OTP
##                  authentication must be enabled and permitted)
##                  [equivalent of -otp command-line option]
##  $geometry    -- desktop geometry, WIDTHxHEIGHT or
##                  W0xH0+X0+Y0[,W1xH1+X1+Y1,...,WnxHn+Xn+Yn]
##                  [equivalent of -geometry command-line option]
##  $noVNC       -- directory containing noVNC
##                  [equivalent of -novnc command-line option]
##  $noxstartup  -- 1 to start the TurboVNC session with no X startup script
##                  [equivalent of -noxstartup command-line option]
##  $passwdFile  -- path to VNC password file to use with VNC Password
##                  authentication
##  $securityTypes -- comma-separated list of security types to enable
##                    (passed to Xvnc in the -securitytypes argument)
##  $serverArgs  -- additional arguments to pass to Xvnc (refer to the Xvnc man
##                  page for a list of accepted arguments)
##  $userDBus    -- Using a unique D-Bus session bus instance for each TurboVNC
##                  session is necessary in order to run multiple TurboVNC
##                  sessions (or a local session and a TurboVNC
##                  session) simultaneously under the same user account, but
##                  this also causes issues with Control Group (cgroup) v2 on
##                  some systems.  If this variable is set to 1, then the
##                  TurboVNC session will use the per-user D-Bus session bus
##                  instance provided by systemd rather than a unique D-Bus
##                  session bus instance.  That improves cgroup v2
##                  compatibility at the expense of multi-session capability.
##  $useUDS      -- listen on a Unix domain socket rather than a TCP port for
##                  connections from VNC viewers
##                  [equivalent of -uds command-line option]
##  $useVGL      -- 1 to run the window manager using VirtualGL.  This variable
##                  is ignored if $xstartup or $noxstartup is specified.
##                  [equivalent of -vgl command-line option]
##  $vglrun      -- the command used to invoke VirtualGL.  This variable can be
##                  used to specify the location of the vglrun script or to
##                  specify additional arguments to vglrun.
##  $vncUserDir  -- path to TurboVNC user directory (session information, VNC
##                  passwords, and log files are stored here)
##  $wm          -- the window manager to use (for instance, "mate" or "2d"),
##                  which corresponds to a session desktop file under
##                  /usr/share/xsessions or /usr/share/wayland-sessions
##                  (/usr/local/share/xsessions on *BSD systems.)  This
##                  variable is ignored if $xstartup or $noxstartup is
##                  specified.
##                  [equivalent of -wm command-line option]
##  $x509CertFile -- path to X.509 signed certificate file (in PEM format) to
##                   use with X.509 encryption
##                   [equivalent of -x509cert command-line option]
##  $x509KeyFile -- path to X.509 private key file (in PEM format) to use with
##                  X.509 encryption
##                  [equivalent of -x509key command-line option]
##  $xstartup    -- path to alternative X startup script
##                  [equivalent of -xstartup command-line option]
##
## These settings are the default.  Uncomment and edit to change.
#
# $autokill = 1;
# $depth = 24;
# $desktopName = "TurboVNC ($ENV{USER})";
# $fontPath = "";
# $generateOTP = 0;
# $geometry = "1240x900";
# $noVNC = "";
# $noxstartup = 0;
# $securityTypes = "TLSVnc, TLSOtp, TLSPlain, X509Vnc, X509Otp, X509Plain, VNC, OTP, UnixLogin, Plain";
# $serverArgs = "";
# $userDBus = 0;
# $useUDS = 0;
# $useVGL = 0;
# $vglrun = "vglrun +wm";
# $vncUserDir = "$ENV{HOME}/.vnc";
# $wm = "";
# $xstartup = "${exedir}xstartup.turbovnc";
## Here is an example of setting the font path:
#
# $fontPath = "/usr/lib/X11/fonts/misc/"
# $fontPath = "$fontPath,/usr/lib/X11/fonts/75dpi/";
## You might wish to create the TurboVNC user directories under /tmp, to
## ensure that VNC passwords are always kept on the local filesystem.  To do
## that, uncomment the line below.  Note that in this case, Xvnc will search
## for the .Xauthority file in this same directory by default.
#
# $vncUserDir = "/tmp/$ENV{USER}-vnc";
## These settings are the default.  Uncomment and edit to change.
#
# $passwdFile = "$vncUserDir/passwd";
# $x509CertFile = "$vncUserDir/x509_cert.pem";
# $x509KeyFile = "$vncUserDir/x509_private.pem";
the /etc/profile doesn't seem to have anything about turbovnc??
and don't have a ~.profile file
> keskiviikko 4. helmikuuta 2026 klo 16.47.35 UTC+2 DRC kirjoitti:
> I can't reproduce the issue. For me, /etc/profile is sourced properly
> for all connections made through the Session Manager. Is there
> additional information that might help me reproduce the problem, such
> as
> a special configuration on the host?
>
> DRC
>
>
> On 2/3/26 4:16 AM, Kimmo wrote:
> > Clarification to the original post:
> >
> > The shells inside all sessions are actually 'non-login' type, but the
> > sessions started using Session Manager don't source '/etc/profile'.
> > This causes some environmental variables set using '/etc/profile' not
> > to load.
> >
> > What would be the most elegant way to source '/etc/profile' for new
> > session while using Session Manager?
> >
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> To view this discussion visit
> 547-90dedb3f1e54n%40googlegroups.com .
+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)    
 mailto:mi...@guam.net                           
 Guam - Where America's Day Begins                       
 G4L Disk Imaging Project maintainer
+------------------------------------------------------------+

Kimmo

unread,
Feb 5, 2026, 5:10:50 AM (6 days ago) Feb 5
to TurboVNC User Discussion/Support
Hi Michael,

The /etc/profile and /etc/turbovncserver.conf have nothing to do with each other. /etc/profile is a system-wide environment setup file which is loaded when an interactive login shell is started. Same goes for ~/.profile. /etc/turbovncserver.conf is a configuration file used when a TurboVNC-server is started. I just provided the information about /etc/turbovncserver.conf mainly to point out that I'm not using any custom startupx-script which could result the /etc/profile and ~/.profile not to be loaded.

I'm not that familiar with what 'vncserver' -command actually does but with my system it seems not to source the /etc/profile and ~/.profile -files. This causes the TurboVNC remote desktop environment not to be configured properly. 

As manual pages for bash (man bash) point out, the ~/.profile is sourced only if one is found. Thus it doesn't mater if you don't have one.

Kimmo

unread,
Feb 5, 2026, 7:55:45 AM (6 days ago) Feb 5
to TurboVNC User Discussion/Support
I've done some testing and sorry for the confusion but this is my understanding about the situation:
  1. When a TurboVNC session is started inside a normal 'login'-type SSH session, the TurboVNC session inherits the environmental variables of that SSH session
    1. When I use e.g. 'Mate Terminal' inside the TurboVNC-session everything works fine because /etc/profile and ~/.profile were sourced when the SSH session was started
  2. When a TurboVNC session is started from Session Manager the TurboVNC session doesn't inherit environmental variables set at /etc/profile or ~/.profile
    1. This indicates the TurboVNC built-in SSH client opens a 'non-login'-type shell from where the TurboVNC session is started
  3. The shells started (using e.g. 'Mate Terminal') inside the TurboVNC session are 'non-login' type which is expected to my knowledge
    1. This makes me think have I just been lucky with the correct environmental variables inherited from the original SSH session
      1. As a result I will probably just move the things I've done in /etc/profile into /etc/bash.bashrc -> Problem solved !

DRC

unread,
Feb 5, 2026, 10:26:00 AM (6 days ago) Feb 5
to turbovn...@googlegroups.com

That's unrelated.  You are using the legacy init.d daemon to start TurboVNC.  We are discussing an issue with the Session Manager, which is a completely different method of startup.

DRC

DRC

unread,
Feb 5, 2026, 10:44:24 AM (6 days ago) Feb 5
to turbovn...@googlegroups.com

My previous message was incorrect.  I thought that I couldn't reproduce the issue on Rocky Linux, but in fact I can.  I was just testing for it incorrectly.

The behavior of the TurboVNC Session Manager in this regard is identical to the behavior of SSH if you specify a command to run.  For example, if you modify /etc/profile so that it exports PROFILE_READ=1 and modify /etc/bashrc so that it exports BASHRC_READ=1:

$ ssh {host} env | grep READ
BASHRC_READ=1

However,

$ ssh {host} bash -cl env | grep READ
PROFILE_READ=1
BASHRC_READ=1

The TurboVNC Session Manager does the equivalent of 'ssh bash -c /opt/TurboVNC/bin/vncserver', so you are correct that /etc/profile has not been executed at the point that /opt/TurboVNC/bin/vncserver is invoked by the Session Manager.  However, if you open a shell in the TurboVNC session, /etc/profile will be executed.  Thus, the issue is only that /etc/profile customizations will not affect the startup of the TurboVNC Server.  Those customizations will still affect applications launched in the TurboVNC session.

If you want environment variables to affect the TurboVNC Server or the window manager, then the preferred ways to do that are:

1. Modify /etc/turbovncserver.conf if the environment variable is for TurboVNC configuration and has an equivalent config file variable (most do.)

2. Use a custom xstartup.turbovnc file.  For example:

   #!/bin/bash
   export MY_ENVIRONMENT_VARIABLE=foo
   exec /opt/TurboVNC/bin/xstartup.turbovnc

   Then set '$xstartup = "/etc/xstartup.turbovnc";' in /etc/turbovncserver.conf.

DRC

Kimmo

unread,
Feb 6, 2026, 2:12:52 AM (5 days ago) Feb 6
to TurboVNC User Discussion/Support
Thank you for very informative reply. That all makes sense. 

As described in my previous message, I was just using TurboVNC in a way which worked for me. With Session Manager things work the way they are designed to work (mainly with login or non-login shells and which files do the source). After understanding these things it's all clear for me now.
Reply all
Reply to author
Forward
0 new messages