# xdm_enable="YES" does not work?



## forquare (Feb 15, 2018)

As per the Handbook, I've always turned XDM on in /etc/ttys, however I've noted that SirDice has mentioned numerous times that it should instead be enabled in /etc/rc.conf.  So last night I gave it a go and XDM never loaded after a reboot, I was left with a console login screen.

I've tried it again this morning on my FreeBSD 11.1-RELEASE VirtualBox VM I use for work and had the same effect.  What am I doing wrong?

/etc/ttys:

```
#
# $FreeBSD: releng/11.1/etc/etc.amd64/ttys 289634 2015-10-20 16:10:46Z gjb $
#    @(#)ttys    5.1 (Berkeley) 4/17/89
#
# This file specifies various information about terminals on the system.
# It is used by several different programs.  Common entries for the
# various columns include:
#
# name  The name of the terminal device.
#
# getty The program to start running on the terminal.  Typically a
#       getty program, as the name implies.  Other common entries
#       include none, when no getty is needed, and xdm, to start the
#       X Window System.
#
# type The initial terminal type for this port.  For hardwired
#      terminal lines, this will contain the type of terminal used.
#      For virtual consoles, the correct type is typically xterm.
#      Other common values include dialup for incoming modem ports, and
#      unknown when the terminal type cannot be predetermined.
#
# status Must be on or off.  If on, init will run the getty program on
#        the specified port.  If the word "secure" appears, this tty
#        allows root login.
#
# name    getty                type    status        comments
#
# If console is marked "insecure", then init will ask for the root password
# when going to single-user mode.
console    none                unknown    off secure
#
ttyv0    "/usr/libexec/getty Pc"        xterm    on  secure
# Virtual terminals
ttyv1    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv2    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv3    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv4    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv5    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv6    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv7    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv8    "/usr/local/bin/xdm -nodaemon"    xterm    off  secure
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyu0    "/usr/libexec/getty 3wire"    vt100    onifconsole secure
ttyu1    "/usr/libexec/getty 3wire"    vt100    onifconsole secure
ttyu2    "/usr/libexec/getty 3wire"    vt100    onifconsole secure
ttyu3    "/usr/libexec/getty 3wire"    vt100    onifconsole secure
# Dumb console
dcons    "/usr/libexec/getty std.9600"    vt100    off secure
```

/etc/rc.conf:

```
clear_tmp_enable="YES"
syslogd_flags="-ss"
sendmail_enable="NONE"
hostname="fbsd-bil"
keymap="uk"
ifconfig_em0="SYNCDHCP"
ifconfig_em1="192.168.56.9 netmask 255.255.255.0"
sshd_enable="YES"
dumpdev="AUTO"
zfs_enable="YES"
hald_enable="YES"
dbus_enable="YES"
vboxguest_enable="YES"
vboxservice_enable="YES"
ntpd_enable="YES"
bsdstats_enable="YES"
motd_enable="YES"
xdm_enable="YES"
```

I've noted that there is no xdm service file in any of the rc.d directories I can find (in /etc/rc.d and /usr/local/etc/rc.d) on either of the machines I've tried...Is there something additional I need to install?


```
bil@fbsd-bil:~ %>pkg info | grep -i xdm
libXdmcp-1.1.2                 X Display Manager Control Protocol library
xdm-1.1.11_8                   X.Org X display manager
```


----------



## Sensucht94 (Feb 15, 2018)

forquare said:


> I've noted that there is no xdm service file in any of the rc.d directories I can find (in /etc/rc.d and /usr/local/etc/rc.d) on either of the machines I've tried...Is there something additional I need to install?



Hi, finally another XDM user!
I usually start it from`/etc/ttys` as per default, turning on the 8th entry, I've never attempted to start as rc service, nad I can confirmx11/xdm port doesn't extract any script inside /usr/local/etc/rc.d, and on the other had, it seems there's no default xdm service in FreeBSD, otherwise rc.conf(5) would have mentioned it, and it doesn't; also see this thread on freebbsd-questions mailing list.  Hence, is it possible SirDice had forgotten about having made his own script when he stated so?
Anyway I suppose you could safely make one as well...I'm far less competent than you here, but something like:

```
#!/bin/sh

. /etc/rc.subr

# PROVIDE: xdm
# REQUIRE: DAEMON LOGIN FILESYSTEMS #optionally I'd put "moused"
# KEYWORD: nojail shutdown

name=xdm
rcvar=${name}_enable
command="/usr/local/bin/${name}"
command_args="-nodaemon"
pidfile="/var/run/${name}.pid"
required_files="/usr/local/etc/X11/xdm/xdm-config"
export PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"

load_rc_config $name
run_rc_command "$1"
```

Anyway, as a side note while ago I was trying to customize Xorg on NetBSD and the result was this:





Looking for a way to get a screenshot every time on boot, I found your thread on Unix stack exchange wondering about the same thing...I finally managed to do this through an extremely simple xwd script. My full XDM config including it, on pastebin:
https://pastebin.com/EM3HYrwi


----------



## forquare (Feb 15, 2018)

Hey!



Sensucht94 said:


> Hence, is it possible SirDice had forgotten about having made his own script when he stated so?



Possibly so, I hope SirDice might find some time to reply and see what he says.



Sensucht94 said:


> Looking for a way to get a screenshot every time on boot, I found your thread on Unix stack exchange wondering about the same thing...I finally managed to do this through an extremely simple xwd script. My full XDM config including it, on pastebin:
> https://pastebin.com/EM3HYrwi



Oh that's awesome!  If you'd post an answer on the question I'll happily mark it as the anwser


----------



## SirDice (Feb 15, 2018)

No, I've never made my own script for this. I'm quite adamant it used to be there, but it's not there any more. I'm also quite sure that ttys was not used because it actually caused problems. I even remember a post from someone that said he fixed the issues with ttys. 

But I can't find the info on short notice, I'm going to have to dig around for it. 

In any case, a xdm_enable would be preferred, so I hope we can resurrect it again. It would make things more consistent, everything else is turned off/on via /etc/rc.conf, even GDM, KDM and SLiM, so why would XDM need to be treated differently?


----------



## sidetone (Feb 15, 2018)

Same here. Also, I would also rather use ttys, because if not, what is that file for, when it comes to switching consoles?

ttys is easy to mess up, and difficult to understand. If my ttys file becomes messed up, I just copy one over from the install cd. From there, I learned how to configure it better, through a little trial and error.

Here's mine, with remote logins disabled, that hasn't caused noticeable problems:
	
	



```
console none                            unknown off secure
#
ttyv0   "/usr/libexec/getty Pc"         xterm   on  secure
# Virtual terminals
ttyv1   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv2   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv3   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv4   "/usr/local/bin/xdm -nodaemon"  xterm   on  secure
ttyv5   "/usr/libexec/getty Pc"         xterm   off  insecure
ttyv6   "/usr/libexec/getty Pc"         xterm   off  insecure
ttyv7   "/usr/libexec/getty Pc"         xterm   off  insecure
ttyv8   "/usr/libexec/getty Pc"         xterm   off  insecure
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyu0   "/usr/libexec/getty 3wire"      vt100   off     insecure
ttyu1   "/usr/libexec/getty 3wire"      vt100   off     insecure
ttyu2   "/usr/libexec/getty 3wire"      vt100   off     insecure
ttyu3   "/usr/libexec/getty 3wire"      vt100   off     insecure
# Dumb console
dcons   "/usr/libexec/getty std.9600"   vt100   off             secure
```
Dcons is off on my system, because I use my video card driver, through rc.conf with kld_list=. VESA falls back to dcons, when switching to the console.


----------



## obsigna (Feb 16, 2018)

Sensucht94 said:


> ... My full XDM config including it, on pastebin:
> https://pastebin.com/EM3HYrwi



Thank you for providing your configuration files, it helped me quite a lot to set up a Power Control Panel on my XDM login screen. There is one obstacle which is somewhat hidden in the manual of xmessage(1):


> ...
> *EXIT STATUS*
> If it detects an error, xmessage returns 1, so this value should not be used with a button.​



I modified the xmessage command in my setup accordingly and it works quite nice:

```
#!/bin/sh
xsetroot -solid "#7F7F7F"
(
   xmessage -buttons " Shutdown ":2,"   Reboot   ":3 "      Power Control      " ;
   case $? in
      2)
         exec /sbin/shutdown -p now;;
      3)
         exec /sbin/shutdown -r now;;
      *)
         ;;
   esac
)&
```


----------



## Sensucht94 (Feb 16, 2018)

Update: I've just tested the XDM service sample I submitted above, and works shamelessly, I'm going to use `xdm_enable="YES"` from then  on


----------



## forquare (Feb 16, 2018)

Sensucht94 said:


> Update: I've just tested the XDM service sample I submitted above, and works shamelessly, I'm going to use `xdm_enable="YES"` from then  on



I was thinking a bug/patch should be submitted.  Seeing as you've got something working maybe you could submit?


----------



## Sensucht94 (Feb 16, 2018)

forquare said:


> I was thinking a bug/patch should be submitted.  Seeing as you've got something working maybe you could submit?



Sure, why not  I'll do this the first free evening I get; is there a mailing list to submit pull request?


----------



## forquare (Feb 17, 2018)

Sensucht94 said:


> Sure, why not  I'll do this the first free evening I get; is there a mailing list to submit pull request?



Awesome  I was considering submitting a bug against x11/xdm, but I don’t know if that would be the ‘official’ method for this. 
Otherwise I guess freebsd-x11@freebsd.org would be the mailing list to use?


----------



## sidetone (Mar 30, 2018)

On NetBSD, `xdm_enable="YES"` is the only way it works. Their ttys file is also much simpler. I'm not sure if this is more recent than any postings above.


----------



## Sensucht94 (Mar 30, 2018)

sidetone said:


> On NetBSD, `xdm_enable="YES"` is the only way it works. Their ttys file is also much simpler. I'm not sure if this is more recent than any postings above.




I submitted a bug, sharing the rc service sample I had made, but got no response yet: I wonder if there's any concrete reason at this point for xdm package not providing a service


----------



## sidetone (Mar 30, 2018)

I should have mentioned that it was implied that Sensucht94 maybe used a script or idea for FreeBSD from his reference to NetBSD. I wonder if others who used xdm_enable were also using a secondary BSD related operating system.


Sensucht94 said:


> I submitted a bug, sharing the rc service sample I had made, but got no response yet: I wonder if there's any concrete reason at this point for xdm package not providing a service


Non-critical bugs usually sit there for months, (or maybe to be forgotten). It is as if committers are understaffed.


----------



## tobik@ (Apr 1, 2018)

The script in PR 225985 actually stops the boot process midway through because xdm never forks into the background and blocks. Probably because of -nodaemon.

It would probably also help to make this a real patch against the port not just a script that a committer has to spend extra time on to integrate into the port.


----------



## sidetone (Apr 1, 2018)

It seems like it should be commented about in the PR.


----------



## Sensucht94 (Apr 2, 2018)

T





tobik@ said:


> The script in PR 225985 actually stops the boot process midway through because xdm never forks into the background and blocks. Probably because of -nodaemon.
> 
> It would probably also help to make this a real patch against the port not just a script that a committer has to spend extra time on to integrate into the port.



This somehow strange, since I'd swear the same script has been working for me meanwhile. Or perhaps I changed something?(Not sure). Anyway I cannot access that computer at the moment,but I'll be back to it in a 48h time.

I'll add that I'm  100% sure NetBSD's and Slackware's rc services append the -nodaemon option, Void Linux' Runit services does the same, since I think that, in this way, user is presented with XDM screen again when he/her logs out, like in all modern DMs. Anyway,as I said,I'll make a couple of tests as soon as I can



sidetone said:


> It seems like it should be commented about in the PR.



Yes, explaining the issue with a simple and quick sentence,wouldn't have hurt


----------



## Sensucht94 (Apr 2, 2018)

So, I rather decided to make a couple of tests on my desktop before going to work and the results are:

- if -nodaemon is specified, xdm does lock rc(8) after the specified service dependencies have been executed and before launching any user service located under /usr/local/etc/rc.d, in a way that user can correctly login into a X session, but all the adidtional 3rd-party services are not initiated  de facto as long as  XDM is not killed or user does not log out. This is probably something I had never realized on laptop, as the latter has almost no additional service enabled in /etc/rc.conf

- if -nodaemon is removed xdm does not lock rc andwaits for all services to be initiated, but it fails somehow at detecting the keyboard and this results in user being caged in the xdm login screen. I've tried to debug, change some options in the service, but with no luck.

Side note: I double checked other inits' XDM services  (NetBSD's rc, Runit and systemd), and they *all* have indeed the -nodaemon option appended to the respective service script. I wonder why. Anyway, there's surely something I'm missing


----------



## tobik@ (Apr 2, 2018)

Sensucht94 said:


> I think that, in this way, user is presented with XDM screen again when he/her logs out


This is the case with Runit because it supervises services and restarts them after they exit. When you run xdm in daemon mode it does this itself. We have -nodaemon in /etc/ttys for xdm because init(8) takes care of restarting terminal ports defined in there.


Sensucht94 said:


> Side note: I double checked other inits' XDM services (NetBSD's rc, Runit and systemd), and they *all* have indeed the -nodaemon option appended to the respective service script. I wonder why.


NetBSD's xdm rc script [1] doesn't seem to add -nodaemon, but I might be looking in the wrong place. Runit is a fundamentally different way to run services. For it to properly supervise things daemons need to _not_ fork themselves into the background, something that rc(8) specifically requires (there is a helper tool daemon(8) for programs that do not do this themselves). Systemd can do it either way depending on what you set in the unit file.

[1] https://github.com/NetBSD/src/blob/trunk/etc/rc.d/xdm.in


----------



## Sensucht94 (Apr 2, 2018)

Tobik, thanks a lot for the info,that was very detailed and kind of yours. I'm still quite the noob with Runit, only tried it a couple of times in jail on FreeBSD and 'accepted' it as a standard in Void Linux. But I should have guessed the running-in-foreground thing, providing the Runit service scripts I made would actually work only after removing any end-string '&'. 

I'll make sure to read more about Runit on official smarden's website.

Regarding NetBSD, I'm still on 7.0, and I'm failing to find the time to upgrade, so things might have changed meanwhile


----------



## sidetone (May 16, 2018)

xdm needs a file in /usr/local/etc/rc.d/ in order for `xdm_enable="YES"` to work from /etc/rc.conf, or as I prefer for what's not in the base system /usr/local/etc/rc.conf.

`xdm_enable` is not referenced by `rcvar=` by in any file under either rc.d/ directory, as nearly everything enabled by rc.conf is.


----------



## crees@ (Jan 8, 2020)

I'll get this committed.


----------

