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.
(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.
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.
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.
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.
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.
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.
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.