Bug 266858

Summary: x11/sddm: Fails to start: /usr/local/etc/profile.d/vte.csh: 19: Syntax error: word unexpected (expecting "then")
Product: Base System Reporter: Edward Tomasz Napierala <trasz>
Component: binAssignee: Adriaan de Groot <adridg>
Status: Closed FIXED    
Severity: Affects Some People CC: adridg, eduardo, grahamperrin, kde, mhorne, mikael, peter, pjfloyd, rhurlin, sascha.folie
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   
URL: https://cgit.freebsd.org/src/commit/bin/sh/profile?id=8d7221ca2dd5e0b6c633761b314cffed82ddca72
See Also: https://reviews.freebsd.org/D37034

Description Edward Tomasz Napierala freebsd_committer freebsd_triage 2022-10-05 19:31:58 UTC
SDDM fails to start.  /usr/local/etc/sddm/home/.local/share/sddm says:

/usr/local/etc/profile.d/vte.csh: 19: Syntax error: word unexpected (expecting "then")

Commenting out the contents of vte.csh makes SDDM work again.

Fun fact: that file

1. Lacks shebang
2. Doesn't seem to be doing anything useful even if it worked
3. Contains syntax error
4. Most of it is GPL license
5. Came from Red Hat.
Comment 1 Nuno Teixeira freebsd_committer freebsd_triage 2022-10-05 20:48:00 UTC
(In reply to Edward Tomasz Napierala from comment #0)
/usr/local/etc/profile.d/vte.csh comes from vte3 pkg (x11-toolkits/vte3).
I've deleted it because I was having same error when login root.
Comment 2 Peter Wemm freebsd_committer freebsd_triage 2022-10-06 03:16:17 UTC
Something is more wrong than is first apparent.  The script has valid csh/tcsh syntax, and is even documented in the tcsh man page.

Here's the real problem:

root@overcee:/home/peter # csh /usr/local/etc/profile.d/vte.csh
root@overcee:/home/peter # sh /usr/local/etc/profile.d/vte.csh
/usr/local/etc/profile.d/vte.csh: 19: Syntax error: word unexpected (expecting "then")

Something is running the *.csh profile scripts with sh.

On my system, root still has the tcsh as a shell while the sddm user has a nologin shell.
Comment 3 Peter Wemm freebsd_committer freebsd_triage 2022-10-06 03:21:43 UTC
Hmm. I think the real problem is /etc/profile itself:
        for _file in "${_dir}"/profile "${_dir}"/profile.d/* ; do
In the Linux universe, profile.d uses shell extensions.  eg: sh runs *.sh, csh/tcsh runs *.csh, and so on.

root@overcee:/home/peter # ls /usr/local/etc/profile.d/
vte.csh vte.sh

Our /etc/profile script isn't compatible with packages developed with Linux expectations.
Comment 4 Paul Floyd 2022-10-11 12:17:25 UTC
I had a similar problems

paulf> sudo cat /usr/local/etc/sddm/home/.local/share/sddm/xorg-session.log
QKqueueFileSystemWatcherEngine::addPaths: open: No such file or directory

I wish that the developers had a clue how to write an error message and tell us which fire or directory is missing.

There is no /usr/local/etc/profile.d/vte.csh on my system.

Deleting and reinstalling the nvidia-driver-390 port fixed the problem.
Comment 5 Rainer Hurling freebsd_committer freebsd_triage 2022-10-11 14:54:18 UTC
I get this vte.csh:19 error when trying to start PostgreSQL server via rc script. 

Looking into /usr/local/etc/rc.d/postgresql it turns out, that the following part of line 107, run as root, throws the error:

${su_cmd} -l ${postgresql_user}

The same executed as a normal user gives no error. If there is no vte.csh script, PostgreSQL server starts fine via rc script.


So on my systems (all recent 14.0-CURRENT amd64) it is the 'su' command run as root, which seems to also execute all scripts under /usr/local/etc/profile.d/. I think, Peter Wemm is right with comment #2 and comment #3.
Comment 6 Mitchell Horne freebsd_committer freebsd_triage 2022-10-27 19:53:17 UTC
It looks like this was found and fixed independently by des@:

https://cgit.freebsd.org/src/commit/bin/sh/profile?id=8d7221ca2dd5e0b6c633761b314cffed82ddca72

Applying this fixes the issue with sddm and vte.csh for me. If someone else confirms it works then this PR can be closed.
Comment 7 Adriaan de Groot freebsd_committer freebsd_triage 2022-11-13 23:57:03 UTC
In 13-STABLE, this doesn't show up because /etc/profile is quite different. Since it is fixed by des@, closing. It wasn't an SDDM problem after all.