I have a script at /etc/shadow-maint/useradd-post.d/ that takes a created username, gets their UID, adds one and prints :##=username to the end of /etc/tigervnc/vncserver.users, as well as writes a default VNC password in their home directory and links their VNC service. This script works great when adding a user manually via terminal, automatically setting up the new user VNC.

However, when I add the script before the initial user login via kickstart/ansible configuration push, and gnome-initial-login tries to add the user, the initial login hangs. The user is created, but the password is not set; they have a homedir created and mail as well.

So it seems the useradd part is running fine and I think it is just my post-script that is hanging for some reason. My initial thought was that the gnome-initial-login user was running the adduser program, and subsequent solution was to catch the user running the script with something like if [[ "$USER" == "gnome-initial-login" ]]; then exit; fi but that seems to fail anyway; I think the script will still be run as root possibly?

I have no idea where to go to troubleshoot this as root is locked and the user doesn't get their password set, so there's no way to log in and say check journal or logs, plus I'm not exactly sure what logs to check for either..?

So I guess my question might be, what user is useradd run as in the context of gnome-initial-login, and also... what logs could I check for to figure out the issue?

Here is a copy of the script in question, in case I am just missing something that gets passed over when running interactively. Also the perms are set to 755.

#!/usr/bin/env bash
    if [[ "${SUBJECT}" == "" || "${USER}" == "gnome-initial-setup" ]]; then exit; fi
    uid=$(id -u $username)
    if [[ ${#display_num} -eq 1 ]]; then
    printf "${display}=${SUBJECT}\n" >> /etc/tigervnc/vncserver.users
    su $username -c 'printf "password\npassword\n" | vncpasswd'
    systemctl enable vncserver@${display}.service
    systemctl start vncserver@${display}.service
} 2>&1 >> /tmp/log.txt

1 Answer 1


I figured it out, with the help of @wjt Will Thompson over at Gnome - I essentially had to go down an SELinux rabbit hole and allow each exception that my script generated, including useradd, bash, su, systemctl and vnc, including some only found in the audit log.

like this:

sudo grep AVC /var/log/audit/audit.log >> problems.txt
cat problems.txt | sudo audit2allow -M custompolicy
sudo semodule -i custompolicy.pp

Also, if you don't have a user configured yet, you can append systemd.debug_shell to the kernel line and it will have a root shell on vty 9.

  • please add tags for kickstart, ansible, tigervnc, to help others with similar issues find this Q+A.
    – jmullee
    Commented Aug 7, 2022 at 22:02
  • I added a few more tags. I had originally omitted them because this was a more general question more related to how the OS was handling my script, not necessarily related to the other bits specifically. Commented Aug 8, 2022 at 23:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .