DTLOGIN(1)

📦

version 2.5.3 · 2 versions

2.5.3 · nixos 26.05 (latest)
2.5.3 · nixpkgs unstable

okay so this is dtlogin(1) — the CDE login service — straight outta the (user cmd) manual, and she is literally the first face you see on your display 👑💅

🌸 NAME 🌸

dtlogin — CDE login service. periodt. ✨

✨ SYNOPSIS ✨

dtlogin [-configconfiguration_file]  [-daemon]  [-debugdebug_level]
[-errorerror_log_file]  [-quiet]  [-nodaemon]  [-resourcesresource_file]
[-serverserver_entry]  [-udpPortport_number]  [-sessionsession_program]

💖 DESCRIPTION 💖

🎀 Key Supported Tasks 🎀

okay so the dtlogin client has these key tasks, and she ate:

Launch of dtgreet login screen for explicitly managed local and remote displays and XDMCP managed remote displays.
Access to traditional terminal (character) login from GUI login screen.
System dependent user authentication and login.
Launching the selected session.

The dtlogin client provides services similar to those provided by init(1m), getty(1m) and login(1) on character terminals: prompting for login and password, authenticating the user, and running a "session." 🫶

A "session" is defined by the lifetime of a particular process; in the traditional character-based terminal world, it is the user's login shell process. In the DT context, it is the DT Session Manager. no cap, that’s the whole vibe check.

If the DT Session Manager is not used, the typical substitute is either a window manager with an exit option, or a terminal emulator running a shell, where the lifetime of the terminal emulator is the lifetime of the shell process that it is running; thus reducing the X session to an emulation of the character-based terminal session. iconic behavior, honestly 💅

When the session is terminated, dtlogin resets the X server and (optionally) restarts the whole process.

The dtlogin client supports management of remote displays using the X Display Manager Control Protocol (XDMCP), Version 1.0. ✨

When dtlogin receives an Indirect query via XDMCP, it can run a chooser process to perform an XDMCP BroadcastQuery (or an XDMCP Query to specified hosts) on behalf of the display and offer a menu of possible hosts that offer XDMCP display management. This feature is useful with X terminals that do not offer a host menu themselves.

Because dtlogin provides the first interface that users see, it is designed to be simple to use and easy to customize to the needs of a particular site. main character energy, fr fr 🌈

The Login window allows the user to enter a user name and password, specify a locale, and select a startup session. A user may also reset the login screen or suspend the X server to access the character login prompt. 💖

Contents of Login window:

login field — Entry field to enter user name.
password field — Entry field to enter user password (no-echo).
OK — Authenticate user and start a session.
Clear — Clear login and password field.
Options — Display menu for language (locale), session, command line login (suspend the X server), and login screen reset.
Help — Display help message.

The Options menu allows the user to specify a locale for the startup session, select a startup session, suspend the X server to access the character login prompt, or reset the login screen. 🎀

Contents of Options Menu:

Languages — Show Language menu.
Sessions — Show Sessions menu.
Command Line Login — Display character login prompt (local displays only). Enabled when dtlogin is started by the system at boot time (see dtconfig man page). Disabled if dtlogin is started manually from a command line "root" login session. This type of manual login is performed for security reasons since it places the user in a running "root" session.
Reset Login Screen — Restart X Server and return to login screen.

The Language menu displays the languages (locales) available in the CDE environment. Selecting a language sets the LANG environment variable to the selected language and restarts the login screen in that language. Login screen localization and LANG return to the default value upon conclusion of the session. 🫶

The contents of this menu can vary depending upon the locales installed on the system and can be overridden by using the languageList resource. The default locale of C can be overridden using the language resource.

The system or languageList locales specified are displayed as menu items in the Languages menu. Alternate text to be displayed may be specified for a given locale name by using the languageName resource. 💜

The Sessions menu allows the user to select which of the following sessions to start:

Current — Start the user's most recent session.
Home — Start the user's home session.
display-name - Current — Create a new display-specific session and start the first of the following sessions that exists:
1. display-specific Home
2. generic Home
3. new user (initial) session
display-name - Home — Create a new display-specific session and start the user's generic home session if it exists. Otherwise, start a new user session.
Fail-safe Session — Start a fail-safe session (Xfailsafe)

Although a user's list of sessions is not known until after the user logs in, the dialog presents all of the session choices. If a user selects a session that does not exist, the Session Manager (dtsession) takes the following actions. If the user selects:

Home — The Session Manager starts a new user session.
Current — The Session Manager starts the user's home session if it exists. If it does not, it starts a new user session.

If the user selects a display-specific session and one does not exist, the Session Manager posts a warning dialog stating that a new session will be created. The warning dialog contains three buttons:

Cancel Login — Cancels the login and returns the user to the login screen.
OK — If a display-specific Home session was selected, the Session Manager creates a new display-specific session and starts the user's generic home session if it exists. If it does not exist, it starts a new user session.

If a display-specific Current session was selected, the Session Manager creates a new display-specific Caretsession and starts a display-specific home, generic home, or new user session, depending on which it finds first.

Help — Displays help text about the warning dialog.

🌈 Controlling The Server 🌈

The dtlogin client controls local servers using POSIX signals. SIGHUP is expected to reset the server, closing all client connections and performing other clean up duties. SIGTERM is expected to terminate the server. If these signals do not perform the expected actions, the resources resetSignal and termSignal can specify alternate signals. 💀

To control remote servers not using XDMCP, dtlogin searches the window hierarchy on the display and uses the KillClient X protocol request in an attempt to clean up the terminal for the next session. This may not actually kill all of the clients, since only those that have created windows are noticed. XDMCP provides a more sure mechanism; when dtlogin closes its initial connection, the session is over and the terminal is required to close all other connections.

💜 Controlling Dtlogin 💜

The dtlogin client responds to two signals: SIGHUP and SIGTERM. When sent a SIGHUP, dtlogin rereads the configuration file and the file specified by the servers resource and determines whether entries have been added or removed. If a new entry has been added, dtlogin starts a session on the associated display. Entries that have been removed are disabled immediately, meaning that any session in progress is terminated without notice, and no new session is started. 😭

When sent a SIGTERM, dtlogin terminates all sessions in progress and exits. This can be used when shutting down the system.

🧚 Internationalization 🧚

All labels and messages are localizable. The message catalog dtlogin.cat contains the localized representations of the default labels and messages. The dtlogin client reads the appropriate message catalog indicated by the LANG environment variable and displays the localized strings. An option on the authentication screen allows the user to override the default language for the subsequent session. If the authentication screen has been localized for the selected language, it is redisplayed in that language; otherwise, it is displayed in the default language. In either case, the LANG environment variable is set appropriately for the resulting session. 🌸

The resource language is available in the dtlogin configuration file to change the default language for a display. The resource languageList is available in the dtlogin configuration file to override the default set of languages displayed on the authentication screen. The resource languageName is available to provide a mapping from locale names to the text displayed on the Language menu.

🫶 Authentication And Auditing 🫶

The dtlogin client performs traditional local UNIX login and auditing. Additional authentication or auditing function such as Kerberos or B1 may be added by individual vendors.

👑 X Server Security 👑

The X server provides both user-based and host-based access control.

By default, dtlogin uses user-based access control to the X server (MIT-MAGIC-COOKIE-1). This level of security allows access control on a per-user basis. It is based on a scheme where if a client passes authorization data which is the same as the server has, it is allowed access. When a user logs in, this authorization data is by default stored and protected in the $HOME/.Xauthority file. 🔥

However, using host-based access control mechanisms may be preferable in environments with unsecure networks as user-based access control allows any host to connect, given that it has discovered the private key. Another drawback to user-based access control is that R2 or R3 clients will be unable to connect to the server.

The authorize resource controls whether user-based or host-based access control is used by dtlogin. See also the Xserver, Xsecurity, xhost, and xauth man pages for more information.

💅 OPTIONS 💅

okay so first thing, bestie: all options, except -config, specify values that can also be specified in the configuration file as resources. Usually you customize stuff through the configuration file rather than command line options. These options are mostly for debugging and one-shot tests. ✨

-config configuration_file — specifies a resource file that sets the remaining configuration parameters. This replaces the dtlogin default Xconfig file. See the Xconfig section for more info. 💖
-daemon — specifies True as the value for the daemonMode resource. This makes dtlogin close all file descriptors, disassociate the controlling terminal and put itself in the background when it first starts up (just like the host of other daemons). 🫶
-debug debug_level — specifies the numeric value for the debugLevel resource. A non-zero value causes dtlogin to print debugging statements to the terminal; it also disables the daemonMode resource, forcing dtlogin to run synchronously. 🔍
-error error_log_file — specifies the value for the errorLogFile resource. See the Xerrors section for more info. 🧚
-nodaemon — specifies False as the value for the daemonMode resource. 🙈
-quiet — specifies True as the value for the quiet resource. This prevents dtlogin from writing status messages to tty1. 🤫
-resources resource_file — specifies the value for the resources resource. See the Xresources section for more info. 🎀
-server server_entry — specifies the value for the servers resource. See the Xservers section for more info. 🖥️
-udpPort port_number — specifies the value for the requestPort resource. This sets the port-number that dtlogin monitors for XDMCP requests. Since XDMCP uses the registered well-known udp port 177, this resource should probably not be changed except for debugging. 👀
-session session_program — specifies the value for the session resource. See the Xsession section for more info. 🌸

🦋 RETURN 🦋

Exit values are:

0 — successful completion. slay. ✅
>0 — error condition occurred. 💀

🌈 RESOURCES 🌈

The dtlogin client is controlled via the contents of the dtlogin configuration file, and the default is:

/nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xconfig

Some resources control the behavior of dtlogin in general, and some can be specified for a particular display. 💜

✨ GENERAL RESOURCES ✨

The dtlogin general resources are not display-specific, and they apply to all displays where appropriate. Here’s the defaults lineup, bestie — every name, class, type and default, kept exactly:

accessFile — Class AccessFile, Type String, Default NULL
authDir — Class AuthDir, Type String, Default /var/dt
autoRescan — Class AutoRescan, Type Boolean, Default True
daemonMode — Class DaemonMode, Type Boolean, Default False
debugLevel — Class DebugLevel, Type Int, Default 0
errorLogFile — Class ErrorLogFile, Type String, Default NULL
errorLogSize — Class ErrorLogSize, Type Int, Default 50
exportList — Class ExportList, Type String, Default NULL
fontPathHead — Class FontPathHead, Type String, Default NULL
fontPathTail — Class FontPathTail, Type String, Default NULL
keyFile — Class KeyFile, Type String, Default /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xkeys
lockPidFile — Class LockPidFile, Type String, Default True
networkDevice — Class NetworkDevice, Type String, Default /dev/dtremote
pidFile — Class PidFile, Type String, Default NULL
removeDomainname — Class RemoveDomainname, Type Boolean, Default True
requestPort — Class RequestPort, Type Int, Default 177
servers — Class Servers, Type String, Default :0 Local local /system_dependent_path/X :0
sysParmsFile — Class SysParmsFile, Type String, Default /system_dependent_path
timeZone — Class TimeZone, Type String, Default NULL
wakeupInterval — Class WakeupInterval, Type Int, Default 10

And yes, the original defaults block also has this literal line, so we’re keeping it: tgroup dispwid="5.96in" 💅

`accessFile`

To prevent unauthorized XDMCP service and to allow forwarding of XDMCP IndirectQuery requests, this file contains a database of hostnames which are either allowed direct access to this machine, or have a list of hosts to which queries should be forwarded. The format of this file is described in the Xaccess section. If not set, all hosts will be allowed XDMCP service. 🔐

`authDir`

This is a directory name that dtlogin uses to temporarily store authorization files for displays using XDMCP. 📁

`autoRescan`

This boolean controls whether dtlogin rescans the configuration file and server file after a session terminates and the files have changed. You can force dtlogin to reread these files by sending a SIGHUP to the main process. 🔁

`daemonMode`

The dtlogin client can make itself into an unassociated daemon process. This is accomplished by forking and leaving the parent process to exit, then closing file descriptors and releasing the controlling terminal. This is inconvenient when attempting to debug dtlogin. Setting this resource to "false" disables daemonMode. 🫥

If dtlogin is started from /etc/inittab, it should not be run in daemon mode. Otherwise the init process will think it has terminated and will attempt to restart it. ⚠️

`debugLevel`

A non-zero value specified for this integer resource enables debugging information to be printed. It also disables daemon mode, which redirects the information into the bit-bucket. 🗑️

`errorLogFile`

Error output is normally directed at the system console. To redirect it, set this resource to any file name. This file contains any output directed to stderr by Xsetup, Xstartup and Xreset. 📝

`errorLogSize`

This resource specifies the maximum size of the error log file in kilobytes. When the limit is reached dtlogin will delete the oldest entries in the file until the file size is reduced to 75% of the maximum. 📏

Note that the errorLogFile is shared by dtlogin and the X server process. The errorLogSize limit may be exceeded if large numbers of errors are logged by the X server before dtlogin detects the size change. 😭

`exportList`

This resource can contain a set of variable names separated by a space or tab. Each variable named is obtained from the dtlogin environment and loaded into the environment of the server and session. See the Environment section for details. 🌱

`fontPathHead`

This resource value is prepended to the default X server font path. 🔤

`keyFile`

XDM-AUTHENTICATION-1 style XDMCP authentication requires that a private key be shared between dtlogin and the terminal. This resource specifies the file containing those values. Each entry in the file consists of a display name and the shared key. By default, dtlogin does not include support for XDM-AUTHENTICATION-1 because it requires DES, which is not generally distributable. 🔑

`lockPidFile`

This resource controls whether dtlogin uses file locking to prevent multiple instances of dtlogin from executing concurrently. 🔒

`networkDevice`

For remote connections, the value for 'line' in /etc/utmp must also exist as a device in the /dev directory for commands such as finger to operate properly. This resource specifies the pathname of the /dev file dtlogin will create when a remote display connects. For most platforms, the file will be created as a symbolic link to /dev/null. The specified value must start with "/dev/", otherwise the value is discarded and no file is created. 🛰️

`pidFile`

The filename specified is created to contain an ASCII representation of the process-ID of the main dtlogin process. This can be used when sending signals to dtlogin. The dtlogin client also uses file locking to attempt to prevent more than one dtlogin from running on the same machine. See the lockPidFile resource for more info. 🪪

`removeDomainname`

When computing the display name for XDMCP clients, dtlogin typically creates a fully qualified host name for the terminal. As this is sometimes confusing, dtlogin removes the domain name portion of the host name if it is the same as the domain name for the local host when this variable is set. 🏷️

`requestPort`

This indicates the UDP port number that dtlogin uses to listen for incoming XDMCP requests. Unless you need to debug the system, leave this with its default value. 📡

`servers`

This resource either specifies a file name full of server entries, one per line (if the value starts with a slash), or a single server entry. Each entry indicates a display that should constantly be managed and that is not using XDMCP. 🗂️

The general syntax for each entry is:

DisplayName DisplayClass DisplayType[@ite] [Command [options]]

A typical entry for local display number 0 is:

:0 Local local@console /usr/bin/X11/X :0

`DisplayName`

The display name must be something that can be passed in the -display option to any X program. This string is used in the display-specific resources to specify the particular display, so be careful to match the names (e.g., use ":0 local /usr/bin/X11/X :0" instead of "localhost:0 local /usr/bin/X11/X :0" if your other resources are specified as "Dtlogin._0.session"). A '*' in this field will be expanded to "&<hostname>:0" by dtlogin. 🎯

`DisplayClass`

The display class portion is also used in the display-specific resources as the class portion of the resource. This is useful if you have a large collection of similar displays (a group of X terminals, for example) and want to set resources for groups of them. When using XDMCP, the display is required to specify the display class, so perhaps your X terminal documentation describes a reasonably standard display class string for your device. 🧩

`DisplayType`

A DisplayType of "local" indicates that an X server should be started for this entry. A value of "remote" indicates to attach to an existing X server. 🌐

A value of "local_uid" indicates that an Xserver should be started for this entry under a specific user id. A user name such as "root" must follow in next field. In the following example, by placing "root" here, Xserver starts under the user id of "root".

:0 Local local_uid@console root /usr/openwin/bin/Xsun :0

Okay so sometimes you should not run the Xserver under a "root" id — security reasons, bestie, no cap. The examples are usually specific to Xserver extensions. On some Xservers, one example involves the Display Postscript extension. If the DPS extension is granted access (via the Xserver option line) to read and write Unix files via the -dpsfileops option, it should not be run under a "root" user id. For increased security, it could instead be run as the "nobody" user. Like this servers-file line, exactly:

:0 Local local_uid@console nobody /usr/openwin/bin/Xsun :0 -dpsfileops

@ite — On local bitmaps, the user may choose a "Command Line Login" option via the login screen, which temporarily suspends the X-server and presents the traditional character login: prompt. The user can then log in and perform non-X related tasks. When the user finishes and logs out, the X-server is restarted, and the login screen is redisplayed. 🦋

In order to support "Command Line Login" mode, the display must have an associated Internal Terminal Emulator (ITE) device. By default, dtlogin associates the ITE device console (/dev/console) with display :0. If your configuration does not match this default, specify @&<device> for the display(s) with an associated ITE and @none for all other displays listed in the servers file.

Command [options] — This is the string used to start the X server. The dtlogin client will always connect to the X server using the DisplayName specified, so you might need to specify an explicit connection number as an option to your X server (:0 in the above example).

`sysParmsFile`

This resource specifies a file containing shell commands, one of which sets the timezone environment variable (TZ) for the system. If the timezone is set via the shell syntax, TZ=, dtlogin can use this information to set the timezone for the user session.

`timeZone`

This resource specifies the local time zone for dtlogin. It is loaded into the environment of dtlogin as the value of the variable TZ and inherited by all subsequent sessions.

Some systems maintain a configuration file that contains the timezone setting (ex. /etc/src.sh). See the sysParmsFile resource.

`wakeupInterval`

If the user selects "Command Line Login" mode from the login screen, dtlogin terminates the X-server and allows the traditional character-based login prompt, login:, to become visible. If the user does not log in within 2 * wakeupInterval seconds, the X-server is restarted. Once the user has logged in, dtlogin checks every wakeupInterval seconds to see if the user has logged out. If so, the X-server is restarted and the login screen is redisplayed.

🌈 DISPLAY RESOURCES 🌈

The dtlogin client display resources can be specified for all displays or for a particular display. To specify a particular display, the display name is inserted into the resource name between Dtlogin and the final resource name segment. For example, Dtlogin.expo_0.startup is the name of the resource defining the startup shell file on the expo:0 display. The resource manager separates the name of the resource from its value with colons, and separates resource name parts with dots, so dtlogin uses underscores for the dots and colons when generating the resource name. ✨

Resources can also be specified for a class of displays by inserting the class name instead of a display name. A display that is not managed by XDMCP can have its class affiliation specified in the file referenced by the servers resource. A display using XDMCP supplies its class affiliation as part of the XDMCP packet.

Here's the whole resource roster, class/type/default all intact — pls don't lose these 💖:

authorize — class Authorize, type Boolean, default False
authName — class AuthName, type String, default MIT-MAGIC-COOKIE-1
authFile — class AuthFile, type String, default NULL
chooser — class Chooser, type String, default /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/dtchooser
cpp — class Cpp, type String, default system dep.
environment — class Environment, type String, default system dep.
failsafeClient — class FailsafeClient, type String, default /system_dep./xterm
grabServer — class GrabServer, type Boolean, default True
grabTimeout — class GrabTimeout, type Int, default 3 seconds
language — class Language, type String, default system dep.
languageList — class LanguageList, type String, default NULL
languageName — class LanguageName, type String, default NULL
openDelay — class OpenDelay, type Int, default 5 seconds
openRepeat — class OpenRepeat, type Int, default 5 seconds
openTimeout — class OpenTimeout, type Int, default 30 seconds
pingInterval — class PingInterval, type Int, default 5 minutes
pingTimeout — class PingTimeout, type Int, default 5 minutes
reset — class Reset, type String, default NULL
resetForAuth — class ResetForAuth, type Boolean, default False
resetSignal — class Signal, type Int, default 1 SIGHUP
resources — class Resource, type String, default NULL
session — class Session, type String, default /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/Xsession
setup — class Setup, type String, default NULL
startAttempts — class StartAttempts, type Int, default 4
startup — class Startup, type String, default NULL
systemPath — class SystemPath, type String, default system_dep._path
systemShell — class SystemShell, type String, default /bin/sh
terminateServer — class TerminateServer, type Boolean, default False
termSignal — class Signal, type Int, default 15 (SIGTERM)
userAuthDir — class UserAuthDir, type String, default /var/dt
userPath — class UserPath, type String, default system_dep._path
xdmMode — class XdmMode, type Boolean, default False
xrdb — class Xrdb, type String, default /system_dep./xrdb
tgroup dispwid="6.05in" — this exact line appears in the original resource table after xrdb; no separate class/type/default is shown for it

`authorize`

Authorize is a Boolean resource that controls whether dtlogin generates and uses authorization for the server connections. (See authName.)

`authName`

If authorize is used, authName specifies the type of authorization to be used. Currently, dtlogin supports only MIT-MAGIC-COOKIE-1 authorization, XDM-AUTHORIZATION-1 could be supported, but DES is not generally distributable. XDMCP connections state which authorization types are supported dynamically, so authName is ignored in this case. (See authorize.)

`authFile`

This file is used to communicate the authorization data from dtlogin to the server, using the -auth server command line option. It should be kept in a write-protected directory to prevent its erasure, which would disable the authorization mechanism in the server. If NULL, dtlogin will generate a file name.

`chooser`

Specifies the program run to offer a host menu for indirect queries redirected to the special host name CHOOSER. /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/dtchooser is the default. See the Xaccess section.

`cpp`

This specifies the path of the C preprocessor that is used by xrdb.

`environment`

This resource can contain a set of &<name>=&<value> pairs separated by a space or tab. Each item is loaded into the environment of the server and session. See the Environment section for details.

`failsafeClient`

If the default session fails to execute, dtlogin falls back to this program. This program is executed with no arguments, but executes using the same environment variables as the session would have had. (See The Xfailsafe File.)

`grabServer`

See grabTimeout.

`grabTimeout`

To improve security, dtlogin grabs the server and keyboard while reading the name and password. The grabServer resource specifies if the server should be held while the name and password is read. When False, the server is ungrabbed after the keyboard grab succeeds; otherwise, the server is grabbed until just before the session begins. The grabTimeout resource specifies the maximum time dtlogin will wait for the grab to succeed. The grab may fail if some other client has the server grabbed, or possibly if the network latencies are very high. The grabTimeout resource has a default of 3 seconds; be cautious when using this resource, since a user can be deceived by a look-alike window on the display. If the grab fails, dtlogin kills and restarts the server (if possible) and session.

Some X-terminals cannot display their login screens while the server is grabbed. Setting grabServer to false will allow the screen to be displayed, but opens the possibility that a user's login name can be stolen by copying the contents of the login screen. Since the keyboard is still grabbed and the password is not echoed, the password cannot be stolen.

`language`

This resource specifies the default setting for the LANG environment variable. If the dtlogin screen is localized for that language, it is displayed appropriately; otherwise, it is displayed in the language "C". The user may temporarily override this setting via an option on the login screen. When the subsequent session terminates, the LANG variable reverts to this setting.

`languageList`

This resource allows the user to override the default set of languages displayed in the "Language" menu of the login screen. It is useful if the set of languages actually used on a particular display is smaller than the set installed on the system. The resource value is a list of valid values for the LANG environment variable. Language values should be separated by one or more spaces or tabs.

`languageName`

This resource allows the user to override the default locale name displayed in the "Language" menu of the login screen with alternate text. This way, instead of users seeing an "En_US" item, they could see an "English (United States)" item instead. This resource is specified as "Dtlogin *&<locale name>. languageName: text" as follows:

Dtlogin*En_US.languageName: English (United States)
Dtlogin*Fr_CA.languageName: French (Canadian)

`openDelay`

See startAttempts.

`openRepeat`

See startAttempts.

`openTimeout`

See startAttempts.

`pingInterval`

See pingTimeout.

🫶 `pingTimeout`

Okay bestie, so pingTimeout is the “are you still there?” vibe check for remote displays. dtlogin occasionally “pings” them, using an X connection and sending XSync requests. The pingInterval resource specifies the time (in minutes) between successive ping attempts, and pingTimeout specifies the maximum wait time (in minutes) for the terminal to respond to the request. If the terminal does not respond, the session is terminated. The dtlogin client does not ping local displays. Although it may seem harmless, it is undesirable when a local session is terminated as a result of the server waiting (for remote filesystem service, for example) and not responding to the ping. 💅

🌸 `reset`

This specifies a program that is run (as root) after the session terminates. If not set, no program is run. The conventional name is Xreset. See The Xreset File.

🦋 `resetForAuth`

The original implementation of authorization in the sample server reread the authorization file at server reset time, instead of when checking the initial connection. Since dtlogin generates the authorization information just before connecting to the display, an old server does not get current authorization information. This resource causes dtlogin to send SIGHUP to the server after setting up the file, causing an additional server reset to occur, during which time the new authorization information is read.

💜 `resetSignal`

This resource specifies the signal dtlogin sends to reset the server. See the section Controlling The Server

🎀 `resources`

This resource specifies the name of the file to be loaded by xrdb(1) as the resource data-base onto the root window of screen 0 of the display. This resource data base is loaded just before the authentication procedure is started, so it can control the appearance of the "login" window. See the section on the authentication screen, which describes the various resources that are appropriate to place in this file. There is no default value for this resource, but the conventional name is Xresources. See the Resource section.

✨ `session`

This specifies the session to be executed for the authenticated user. By default, the /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/Xsession file is run. The conventional name is Xsession. See The Xsession File.

🌈 `setup`

This specifies a program that is run (as root) prior to the display of the authentication screen. By default, no program is run. The conventional name for a file used here is Xsetup. See the Xsetup section.

🔥 `startAttempts`

Four numeric resources control the behavior of dtlogin when attempting to open reluctant servers: openDelay, openRepeat, openTimeout, and startAttempts. openDelay is the duration (in seconds) between successive attempts; openRepeat is the number of attempts to make; openTimeout is the amount of time to wait while actually attempting the opening (i.e., the maximum time spent in the connect (2) syscall); and startAttempts is the number of times the entire process occurs before giving up on the server. After openRepeat attempts have been made, or if openTimeout seconds elapse in any particular attempt, dtlogin terminates and restarts the server, attempting to connect again. This process is repeated startAttempts time, at which point the display is declared dead and disabled. (See openDelay, openRepeat, and openTimeout.)

🍓 `startup`

This specifies a program that is run (as root) after the authentication process succeeds. By default, no program is run. The conventional name for a file used here is Xstartup. See the Xstartup section.

💖 `systemPath`

The dtlogin client sets the PATH environment variable for the startup and reset scripts to the value of this resource. Note the conspicuous absence of "." from this entry. This is a good practice to follow for root; it avoids many system penetration schemes.

🧚 `systemShell`

The dtlogin client sets the SHELL environment variable for the startup and reset scripts to the value of this resource.

👑 `terminateServer`

This boolean resource specifies whether the X server should be terminated when a session terminates (instead of resetting it). This option can be used if the server tends to grow without bound over time in order to limit the amount of time the server is run continuously.

⭐ `termSignal`

This resource specifies the signal dtlogin sends to terminate the server. See the section Controlling The Server

🫶 `userAuthDir`

When dtlogin cannot write to the usual user authorization file ($HOME/.Xauthority), it creates a unique file name in this directory and points the environment variable XAUTHORITY at the created file.

💀 `userPath`

The dtlogin client sets the PATH environment variable for the session to this value. It should be a colon-separated list of directories; see sh(1) for a full description.

🙈 `xdmMode`

If True, the $HOME/.xsession file will be executed from Xsession upon user authentication, rather than the Session Manager (dtsession).

🎀 `xrdb`

Specifies the program used to load the resources. The authentication screen reads a name-password pair from the keyboard. As this is a Motif toolkit client, colors, fonts and some layout options can be controlled with resources. General resources for this screen should be put into the file named by the dtlogin resources resource, the default being Xresources. Language specific values such as text or fonts should be specified in the Dtlogin app-defaults file.

🎀 Logo Resources 🎀

The default logo on the authentication screen may be replaced with a bitmap or pixmap of the user's choice. The resources should be prefaced with the string Dtlogin*logo* when specified.

Here are the resource specs, literally:

Name bitmapFile; Class BitmapFile; Type String; Default NULL
Name background; Class Background; Type Pixel; Default #a8a8a8
Name topShadowPixmap; Class TopShadowPixmap; Type String; Default 25_foreground
bitmapFile — Specifies the absolute path name to the bitmap or pixmap file to be used for the logo.
background — Specifies the background color for the logo.
topShadowPixmap — Specifies the pixmap to use for the logo border shadow.

🖥️ Alternative Desktop Session Resources

These resources allow adding additional desktops to the dtlogin option sessions menu. Resource names used to enable an alternative desktop follow.

Name altDtsIncrement; Class AltDtsIncrement; Type String; Example Value True
Name altDtName; Class altDtName; Type String; Example Value MyWindows Desktop
Name altDtKey; Class altDtKey; Type String; Example Value /usr/mywin/bin/mywm
Name altDtStart; Class altDtStart; Type String; Example Value /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xsession.mw
Name altDtLogo; Class altDtLogo; Type String; Example Value MWlogo

The file containing the above sample values will be found in /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/C/Xresources.d/Xresources.mw. They cause the MyWindow desktop to be added to the option sessions menu.

Additional files may be added in this Xresources.d directory to allow additional X-based desktops to appear on the dtlogin sessions menu. Or, a file may be placed in /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/C/Xresources.d for a workstation-specific addition.

The same resource names would be used. The presence of the altDtsIncrement resource in these files causes an incremented count number to be appended to the resources. So actual values of the above resource example after they are read into the system might actually be ... altDtName2, altDtKey2, altDtStart2, altDtLog2. The next desktop added would then be ... altDtName3, altDtKey3, altDtStart3, altDtlog3.

The syntax for setting the following resources is Dtlogin*altDt...n where n is an integer, as in altDtName1, altDtName2, etc. The numbers are added to resources either implicitly (such as in the above Xresources.d example, which is useful for "package added" desktops) or explicitly if used directly in the Xresources file to facilitate ordering of the desktops on the sessions menu.

altDtNamen — Specifies the name of the alternative desktop. This name will appear both on the sessions menu and also on the Login's greet window when the associated desktop is selected as the login destination.
altDtKeyn — Specifies a key file, which, if present, causes the alternative desktop to be added to the dtlogin option session menu. By convention, this file is often the desktop's window manager. But it can actualy be any file uniquely associated with the alternative desktop.
altDtStartn — Specifies the script that starts the alternative desktop.
altDtLogon — Specifies the base name of the alternative desktop's icon logo, either in XPM (color) or XBM (monochrome) format. This logo will display on the Login greet window when the associated desktop is selected as the login destination.

👋 Greeting Resources

The following resources describe the greeting string used on the login screen. The resources should be prefaced with the string Dtlogin*greeting* when specified.

Name foreground; Class Foreground; Type Pixel; Default black
Name background; Class Background; Type Pixel; Default dynamic
Name fontList; Class FontList; Type FontList; Default -*-*schoolbook-medium-i-normal--18-*
Name labelString; Class LabelString; Type String; Default Welcome to %LocalHost%
Name persLabelString; Class LabelString; Type String; Default Welcome %s
Name alignment; Class Alignment; Type String; Default ALIGNMENT_CENTER
Also literally in the original right there: tgroup dispwid="5.63in"
foreground — Specifies the foreground color for the welcome message.
background — Specifies the background color for the welcome message. The default is light-gray for color systems or white for monochrome systems.
fontList — Specifies the font to use for the welcome message.
labelString — Specifies the string to use for the welcome message. Multiple lines can be specified by including newline characters (0 in the text. If the token %LocalHost" is included in the text, it will be replaced with the name of the host providing login service. If the token %DisplayName% is included in the text, it will be replaced with the display name.
persLabelString — Specifies the string to use for the personalized welcome message. This is the message displayed after the user name has been entered. The %s will be replaced with the user name entered.
alignment — tells dtlogin what string to use for aligning the Welcome message. Valid values are ALIGNMENT_BEGINNING, ALIGNMENT_CENTER, and ALIGNMENT_END.

🎀 Matte Resources 🎀

Okay so these resources describe the matte layout used on the login screen. The resources should be prefaced with the string Dtlogin*matte. when specified.

width (class Width, type Int) — sets the width to use for login_matte. Defaults: 806 for Highres displays, 755 for Mediumres displays, 585 for lowres displays.
height (class Height, type Int) — sets the height to use for login_matte. Defaults: 412 for Highres displays, 385 for Mediumres displays, 300 for Lowres displays.

🌸 Label Resources 🌸

These resources describe the fonts layout used on the login screen. The resources should be prefaced with the string Dtlogin*. when specified.

labelFont (class LabelFont, type String) — picks the labelFont to use for the pushButtons and labels. Defaults:
- -*-swiss 742-bold-r-normal-*-140-*-p-100-* for lowres displays
- -*-swiss 742-medium-r-normal-*-140-*-p-110-* for high res displays.
textFont (class TextFont, type String) — picks the textFont to use for the pushButtons and labels. Defaults:
- -*-prestige-medium-r-normal-*-128-72-* for highres diqsplays.
- -*-helvetica-bold-r-normal-*-100-* for lowres displays

Also in that resource table: tgroup dispwid="6.03in". Yep, it’s literally there, bestie. 🫶

🌎 ENVIRONMENT 🌎

When the dtlogin client invokes the user’s session, it gives it this default environment:

DISPLAY — is set to the associated display name.
EDITOR — is set to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/dtpad.
HOME — is set to the home directory of the user.
KBD_LANG — is set to the value of LANG for applicable languages.
LANG — is set to the current NLS language (if any).
LC_ALL — is set to the current NLS language (if any).
LC_MESSAGES — is set to the current NLS language (if any).
LOGNAME — is set to the user name.
MAIL — is set to /var/mail/$USER (system dependent).
PATH — is set to the value of the userPath resource.
USER — is set to the user name.
SHELL — is set to the user’s default shell (from /etc/passwd).
TERM — is set to dtterm.
TZ — is set to the value of the timeZone resource or system default.
XAUTHORITY — may be set to an authority file.

💫 Adding to the Environment List 💫

Four methods are available to modify or add to this list depending on the desired scope of the resulting environment variable.

The exportList resource is available to allow the export of variables provided to the dtlogin process by its parent. Variables specified by this method are available to both the display’s X server process and the user’s session and override any default settings. The resource accepts a string of &<name> separated by at least one space or tab.

The environment resource is available in the dtlogin configuration file to allow setting of environment variables on a global or per-display basis. Variables specified by this method are available to both the display’s X server process and the user’s session and override any default settings. The resource accepts a string of &<name>=&<value> pairs separated by at least one space or tab. The values specified must be constants because no shell is used to parse the string. See the Resources section for details on setting this resource.

For example:

MAIL=/var/mail/$USER

Finally, personal environment variables can be set on a per-user basis in the script file $HOME/.dtprofile.

The dtlogin client accepts either sh, ksh, or csh syntax for the commands in this file. The commands should only be those that set environment variables, not any that perform terminal I/O, excepting tset(1) or stty(1). If the first line of .dtprofile is #!/bin/sh, #!/bin/ksh, or #!/bin/csh, dtlogin uses the appropriate shell to parse .dtprofile. Otherwise, the user’s default shell ($SHELL) is used.

📁 FILES 📁

The dtlogin client is designed to operate in a wide variety of environments and provides a suite of configuration files that can be changed to suit a particular system. The default dtlogin configuration files can be found in /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config with the exception of Xsession which is stored in /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin. They are listed below:

Xconfig — specifies other dtlogin configuration files and dtlogin behavior.
Xaccess — used by dtlogin to control access from displays requesting XDMCP service.
Xservers — contains the list of displays for dtlogin to explicitly manage.
Xresources — contains resource definitions specifying the appearance of the login screen.
Xsetup — a script executed as 'root' prior to display of the login screen.
Xstartup — a script executed as 'root' after user has successfully authenticated.
Xsession — a script executed as the authenticated 'user' that starts the user’s session.
Xfailsafe — a script executed as the authenticated 'user' that starts a failsafe session.
Xreset — a script executed as 'root' after the user’s session has exited.

🗂️ The Xconfig File 🗂️

The Xconfig file contains the general resources for dtlogin and is the top of the dtlogin configuration file tree. Xconfig specifies the location of other dtlogin configuration and log files and specifies dtlogin behavior. The locations of other dtlogin configuration and log files are specified by resource definitions. The defaults are listed below:

Dtlogin.errorLogFile — /var/dt/Xerrors
Dtlogin.pidFile — /var/dt/Xpid
Dtlogin.accessFile — Xaccess
Dtlogin.servers — Xservers
Dtlogin*resources — %L/Xresources
Dtlogin*setup — Xsetup
Dtlogin*startup — Xstartup
Dtlogin*reset — Xreset
Dtlogin*failsafeClient — Xfailsafe
Dtlogin*session — /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/Xsession

If the path specified for accessFile, servers, resources, setup, startup, reset, failsafeClient, or session is relative, dtlogin will first look for the file in directory /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config, then /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config.

Note that some of the resources are specified with * separating the components. These resources can be made unique for each different display, by replacing the * with the display-name. See the DISPLAY RESOURCES section for a complete discussion.

The default Xconfig file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xconfig. A system administrator can customize Xconfig by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xconfig to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xconfig and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xconfig.

The default Xconfig file contains the configuration and log file entries shown above as well as a few vendor specific resource definitions and examples. See the GENERAL RESOURCES and DISPLAY RESOURCES sections for the complete list of resources that can be defined in Xconfig.

🗝️ The Xaccess File 🗝️

The database file specified by the accessFile resource provides information which dtlogin uses to control access from displays requesting XDMCP service. This file contains three types of entries: entries which control the response to Direct and Broadcast queries, entries which control the response to Indirect queries, and macro definitions.

The format of a Direct entry is either a host name or a pattern. A pattern is distinguished from a host name by the inclusion of one or more meta characters ('*' matches any sequence of 0 or more characters, and '?' matches any single character) which are compared against the host name of the display device. If the entry is a host name, all comparisons are done using network addresses, so any name which converts to the correct network address may be used. For patterns, only canonical host names are used in the comparison, so ensure that you do not attempt to match aliases. Preceding either a host name or a pattern with a '!' character causes hosts which match that entry to be excluded.

An Indirect entry also contains a host name or pattern, but follows it with a list of host names or macros to which indirect queries should be sent. Indirect entries may also specify to have dtlogin run dtchooser to offer a menu of hosts to which a login screen can be displayed.

A macro definition contains a macro name and a list of host names and other macros that the macro expands to. To distinguish macros from hostnames, macro names start with a '%' character. Macros may be nested.

When checking access for a particular display host, each entry is scanned in turn and the first matching entry determines the response. Direct and Broadcast entries are ignored when scanning for an Indirect entry and vice-versa.

Blank lines are ignored, '#' is treated as a comment delimiter causing the rest of that line to be ignored, and '0wline' causes the newline to be ignored, allowing indirect host lists to span multiple lines.

Here is an example Xaccess file: DJB

#
# Xaccess - XDMCP access control file
#

#
# Direct/Broadcast query entries
#
!xtra.lcs.mit.edu # disallow direct/broadcast service for xtra
bambi.ogi.edu    # allow access from this particular display
*.lcs.mit.edu    # allow access from any display in LCS

#
# Indirect query entries
#

#define %HOSTS macro
%HOSTS         expo.lcs.mit.edu xenon.lcs.mit.edu                  excess.lcs.mit.edu kanga.lcs.mit.edu

#force extract to contact xenon
extract.lcs.mit.edu xenon.lcs.mit.edu

#disallow indirect access by xtra
!xtra.lcs.mit.edu  dummy

#all others get to choose among %HOSTS
*.lcs.mit.edu      %HOSTS

Okay so if XDMCP access is granted, a temporary file may get created in the directory named by authDir, and it holds the authorization info for the X-terminal. Then it gets deleted the moment the session starts. Poof. Gone. 💨

Now, some X terminals are out here with no host menu at all — like, they literally can't do a menu for Broadcast or Indirect queries. Rude of them, honestly. But bestie, the chooser program can do it for them. In the Xaccess file, you specify "CHOOSER" as the first entry in the Indirect host list. Then chooser sends a Query request to every remaining host name in the list, and serves you a whole menu of all the hosts that actually respond. Iconic. 👑

The list can also just be the word "BROADCAST," — yes, comma included, that's what it says — and in that case chooser sends a Broadcast instead, again giving you a menu of all the hosts that respond.

⚠️ Heads up though: on some operating systems, UDP packets cannot be broadcast, so this feature genuinely will not work there. No cap.

Example Xaccess file using chooser:

#offer a menu of these hosts to extract
extract.lcs.mit.edu CHOOSER %HOSTS

#offer a menu of all hosts to xtra
xtra.lcs.mit.edu  CHOOSER BROADCAST

Which program to use for chooser? That's decided by the chooser resource. And the resources for that program can go in the file named by resources. 🫶

The default Xaccess file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xaccess. A system administrator can customize Xaccess by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xaccess to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xaccess and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xaccess. 🎀

And the default Xaccess file contains, drumroll please… no entries. Empty. Blank. A whole vibe of nothing. 😭

The Xservers File 🖥️

This one contains the list of displays to manage. Where's the deets on that? Go look at the servers resource description under GENERAL RESOURCES, bestie. 📖

The default Xservers file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xservers. A system administrator can customize Xservers by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xservers to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xservers and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xservers.

The default Xservers file contains an entry for one local display. Just the one. Single. Solo. 💅

The Xresources File 🌸

Holds the resource definitions that specify how the login screen looks. Want the full glow-up details? See the dtgreet(1) man page. ✨

The default Xresources file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xresources. A system administrator can customize Xresources by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xresources to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xresources and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xresources.

The Xsetup File 🛠️

So this file is typically a shell script. It runs as "root" — yes, actual root, main character energy — so it should be very careful about security. Like, extremely. 🙈

This script runs before the login screen is displayed, and no arguments of any kind get passed to it. Nada. Dtlogin waits until this script exits before it displays the login screen, so don't leave it hanging, okay? ⏳

The default Xsetup file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xsetup. A system administrator can customize Xsetup by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xsetup to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xsetup and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xsetup.

The default Xsetup file contains vendor specific code, but typically it's code that sets up the X server before the login screen shows up — stuff like setting up keyboard maps. ⌨️

The Xstartup File 🚀

Also typically a shell script, also run as "root", also should be very careful about security. This is the place to put commands that display the message of the day, or do other system-level functions on behalf of the user. 🫡

Various environment variables get set for this script:

DISPLAY — set to the associated display name
HOME — set to the home directory of the user
PATH — set to the value of the systemPath resource
USER — set to the user name
SHELL — set to the value of the systemShell resource

No arguments of any kind are passed to the script. Dtlogin waits until this script exits before starting the user session. And if the exit value of this script is non-zero, dtlogin discontinues the session immediately and starts another authentication cycle. Straight up cancels the whole thing. 💀

The default Xstartup file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xstartup. A system administrator can customize Xstartup by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xstartup to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xstartup and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xstartup.

The default Xstartup file contains code to change ownership of /dev/console to the user whose session is running on the console. 🎀

The Xsession File 🌈

This script initializes a user's session and then invokes the desktop session manager. It runs with the permissions of the authorized user, and it has several environment variables pre-set. Want the list of pre-set variables? Scroll to the Environment section, bestie. 💜

The default Xsession file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/Xsession. A system administrator can customize Xsession by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/Xsession to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xsession and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xsession.

🚨 But wait — the session resource defined in Xconfig must also be changed to reference the customized Xsession file. See the Xconfig section for how to update the Xconfig file. Don't forget this part, it's giving "forgot the last step of the recipe." 😭

The default Xsession file contains session initialization code. It does contain some vendor specific code, but its general function goes like this:

Sources the user's $HOME/.dtprofile
Sources any /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xsession.d/* scripts
Sources any /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xsession.d/* scripts
Launches in the background the desktop welcome client, dthello
Sources the application search path setup script, dtsearchpath
Launches in the background the help setup client, dthelpgen
Launches in the background the application manager directory setup client, dtappgather
Execs the desktop session manager, dtsession

🙅‍♀️ System administrators are discouraged from customizing the Xsession file. Like, please don't. The original said it, I'm just relaying the message.

The Xreset File 🔄

Symmetrical with Xstartup — cute, right? This script runs after the user session has terminated. It runs as root, and it should probably contain commands that undo the effects of the commands in Xstartup, like unmounting directories from file servers. Cleanup era. 🧹

The collection of environment variables that were passed to Xstartup are also given to Xreset. Same set, no changes, fr fr.

The default Xreset file is /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xreset. A system administrator can customize Xreset by copying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xreset to /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xreset and modifying /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/Xreset.

The default Xreset file contains code to change ownership of /dev/console back to root. 🔐

✨ STATUS ✨

The Xerrors File 🐛

Contains error messages from dtlogin, plus anything output to stderr by Xsetup, Xstartup or Xreset. So when things go sideways, this is your receipts folder. A system administrator can use the contents of this file for dtlogin troubleshooting. 🔍

The errorLogSize resource limits the size of the Xerrors file and can prevent it from growing without bound. Because unbounded growth is not it. 📈💀

A system administrator can change the pathname of the Xerrors file by setting the errorLogFile resource in the Xconfig file. See the Xconfig section for how to update the Xconfig file. 📝

The Xpid File 🆔

Contains the process ID of the master dtlogin process — which is exactly what you need when you're sending signals to dtlogin. 📡

A system administrator can change the pathname of the Xpid file by setting the pidFile resource in the Xconfig file. See the Xconfig section for how to update the Xconfig file. 🫶

😭 ERROR MESSAGES 😭

Login incorrect; please try again.
Unable to change to home directory.
Sorry. Maximum number of users already logged in.
Login error, invalid user ID.
Login error, invalid group ID.
Login error, invalid audit ID.
Login error, invalid audit flag.
Logins are currently disabled.
Your current password has expired.

🚧 RESTRICTION 🚧

There's a resource in /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xconfig that controls the maximum error log file size of /var/dt/Xerrors — that's the error log for the dtlogin processes and the X server. This resource is called Dtlogin.errorLogSize, and it specifies the maximum file size in kilobytes. 📏

The dtlogin application will truncate the file if it grows larger than the size specified in the resource parameter. Chop chop. ✂️

⚠️ Okay so here's the caveat, and it's a real one: because both dtlogin and the X server can write to this file, the X server may write more data than the limit before the dtlogin process can trim it. So the cap is more of a vibe than a guarantee. 🫠

Sending a signal to the primary dtlogin process on the system will also force the file to be truncated. That's your manual override, iykyk. 💅

👀 SEE ALSO 👀

dtgreet(1)

That's the whole page, bestie — you made it to the end! 🎉💖 This was dtlogin(user cmd) (the CDE 2.5.3 build, that's the cde-2.5.3 you kept seeing in every single path up there 🍓), and the source/version + date footer is right here at the bottom where it belongs. Go forth and log in responsibly. Slay. 👑✨

📦 where this page comes from

nixos 26.05: cde 2.5.3
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

DTLOGIN(1)

🌸 NAME 🌸

✨ SYNOPSIS ✨

💖 DESCRIPTION 💖

🎀 Key Supported Tasks 🎀

🍓 Login Window 🍓

🦋 Login Window -- Options Menu 🦋

🌸 Login Window -- Language Menu 🌸

🎀 Login Window -- Sessions Menu 🎀

🌈 Controlling The Server 🌈

💜 Controlling Dtlogin 💜

🧚 Internationalization 🧚

🫶 Authentication And Auditing 🫶

👑 X Server Security 👑

💅 OPTIONS 💅

🦋 RETURN 🦋

🌈 RESOURCES 🌈

✨ GENERAL RESOURCES ✨

accessFile

authDir

autoRescan

daemonMode

debugLevel

errorLogFile

errorLogSize

exportList

fontPathHead

keyFile

lockPidFile

networkDevice

pidFile

removeDomainname

requestPort

servers

DisplayName

DisplayClass

DisplayType

sysParmsFile

timeZone

wakeupInterval

🌈 DISPLAY RESOURCES 🌈

authorize

authName

authFile

chooser

cpp

environment

failsafeClient

grabServer

grabTimeout

language

languageList

languageName

openDelay

openRepeat

openTimeout

pingInterval

🫶 pingTimeout

🌸 reset

🦋 resetForAuth

💜 resetSignal

🎀 resources

✨ session

🌈 setup

🔥 startAttempts

🍓 startup

💖 systemPath

🧚 systemShell

👑 terminateServer

⭐ termSignal

🫶 userAuthDir

💀 userPath

🙈 xdmMode

🎀 xrdb

🎀 Logo Resources 🎀

🖥️ Alternative Desktop Session Resources

👋 Greeting Resources

🎀 Matte Resources 🎀

🌸 Label Resources 🌸

🌎 ENVIRONMENT 🌎

`accessFile`

`authDir`

`autoRescan`

`daemonMode`

`debugLevel`

`errorLogFile`

`errorLogSize`

`exportList`

`fontPathHead`

`keyFile`

`lockPidFile`

`networkDevice`

`pidFile`

`removeDomainname`

`requestPort`

`servers`

`DisplayName`

`DisplayClass`

`DisplayType`

`sysParmsFile`

`timeZone`

`wakeupInterval`

`authorize`

`authName`

`authFile`

`chooser`

`cpp`

`environment`

`failsafeClient`

`grabServer`

`grabTimeout`

`language`

`languageList`

`languageName`

`openDelay`

`openRepeat`

`openTimeout`

`pingInterval`

🫶 `pingTimeout`

🌸 `reset`

🦋 `resetForAuth`

💜 `resetSignal`

🎀 `resources`

✨ `session`

🌈 `setup`

🔥 `startAttempts`

🍓 `startup`

💖 `systemPath`

🧚 `systemShell`

👑 `terminateServer`

⭐ `termSignal`

🫶 `userAuthDir`

💀 `userPath`

🙈 `xdmMode`

🎀 `xrdb`