VirtualBox CentOS Python GUI program needs to run on boot without logging in and output audio

Question

I have a web service running in a VM (virtualBox) on CentOS (in the VM). To access it, I use a browser on the host machine (Windows). I have a Python script that outputs audio from the VM and launches a GUI (TKinter). This script runs when I select a button on the webpage. Note: the GUI portion of the code is there for a rare use case. Most of the time it doesn't need to run.

My Issue: This script runs fine when I log into the user on CentOS in the VM. (It runs fine when the screen is locked too). The script does not run when CentOS is shutdown and powered on. I have to initially sign in to the user on CentOS for the script to run.

I'm a bit of a novice, but I think this might be caused by the OS not running any support for GUIs before someone logs into the system. Do you have any idea what a solution would be? I can't log in automatically (unless I can maintain the same level of security, i.e. log in but stay locked). I don't need to see the GUI, but I do need the audio.

I did mess with my script to disable the TKinter code if no one is logged in. I ran os.popen("last user") to get the last login. I checked for "still logged in" which is returned when someone logged in. This got me to a weird use case:

Now the system works when:

1) user logs on

OR

2) user logs on. Shuts down the VM. Boots up without logging on.

It does not work if I shut it down again. Boot it back up and run the code without logging on. It's like it remembers that I logged on before that last power cycle but not after I reboot it a second time.

EDIT: Running CentOS 6.7, GNOME 2.28.2

A bit more about the program: It's a Python script that outputs audio and a GUI to adjust the audio if there is an issue. This GUI is rarely used, but needed. Apparently the audio itself fails to run under the same conditions (after I removed all the GUI code to test just the audio). I don't need to worry about GUI automation. Also, the python script is called when a Python-Flask endpoint is hit. Does it make sense to move the script to the daemon? I know the program can start when session is locked.

Answer 1

GUI programs NEED an active X-server running a desktop environment (Gnome, KDE or mate, among many others) in order to execute, however, this is puzzling me:

2) user logs on. Shuts down the VM. Boots up without logging on.

It does not work if I shut it down again. Boot it back up and run the code without logging on. It's like it remembers that I logged on before that last power cycle but not after I reboot it a second time.

If that works it means that your program only fails if someone who is not logged in shutdowns the computer, but if a logged in user shuts it down it will work properly later on login? If so, I think this is not a desktop issue, however, the following will serve as a workaround for you. Go to the bottom to read more about this particular thing in the "The rare case" section, or continue reading if you want a solution to autostart your session maintaining security and avoid the problem.

Usually CentOS comes packed with Gnome unless you installed a different one. Considering you said you've no linux experience, I'll consider you're using Gnome and provide you an specific example later on, however, since you didn't state it explicitly, I'll give you a generic answer aswell so you could google piece by piece if you needed to.

The best option is ALLWAYS to use a non-GUI program which is able to run as a daemon with systemd. This allows you to maintain the highest degree of security in a relatively easy way. Of course it is not the only way, and depending on your environment, a small loss of security may be OK.

If there's no such program version, then you need to automatically start the x-server and a user sesion (which you can then automatically lock down without closing if you need security). On a default CentOS with GUI instalation, I think it is the default setting nowadays (CentOS 7 and above), and since you did not tell us your CentOS version, I'll leave this aside.

You should provide CentOS version in order to get specific instructions of how to do this, since the way to do it changes btween CentOS 6 and CentOS 7 (most commonly used versions). We'd also need to know with desktop environment are you using (Gnome, KDE, mate, etc), since the way to autologin and then block a session depends on it.

To sum up, you have two options:

Proper solution:

1. Find a version of your program which does not need a GUI to run. Some linux GUIs are just a command line envelope, others provide both interfaces, but some of them are really GUI dependant. If your program is one of those (being python makes it more likely) you should really consider using a different software to achieve your goals, since GUI software automation, although not impossible, requires far more time than CLI automation, specially if the software forces you to perform many clicks.
2. Configure it to run as a daemon ("equivalent" to Windows services). You need to add it as a daemon in the configuration, which depends on CentOS version.
3. If you dont want to look into services, you could allways use the "nohup &" trick in order to run a normal process as a service, then put it into the startup script and set a watchdog in order to monitor if the executable crashes (which is what systemd would do your you if you configured it as a daemon)

I'll not get into this solution any further, as I don't know if your program supports this, I dont even know what program are you trying to autostart.

Second solution (workaround)

1. Configure your Linux to start with the X enabled in a graphical login window. (I think it is CentOS 7 default)
2. Configure your desktop environment for autologin. Procedure depends on the desktop environment you use (KDE, Gnome, mate, etc)
3. Add your program to the desktop environment program autostart list. Procedure depends on the desktop environment.
4. (OPTIONAL if security is required) - Configure it to lock the user and ask for pasword without closing session. This should let the program running in the background. You should ensure that your program has time to start or that it is able to start even if the session is locked. Some security configurations or programs may avoid it. A dirty solution would be to wait some seconds before locking screen, but this would add a security breach, giving an attacked some seconds to get into your system and avoid it to get locked.

Once again, if you provided more details I could've looked for the specific commands or hints on how to accomplish this, however, this is the theoretical answer which works for any modern Linux OS.

For instance, CentOs 7 + Gnome is as simple as this:

Autologin (Copied the link's mini guide and image just for completeness):

1. Login to GNOME as usual

2. Find your name at the top right and click on it

3. Now select Settings

4. In the new window that opens, find Users

5. Click on Unlock at the top right

6. Select your own user and turn on Automatic Logins

You need supervisor privileges to make this change. Next time you restart your system, you’re logged in automatically.

Autostart applications in Gnome with CentOS 7 - I'm not copying the answer since it is inside StackExchange. Shows you how to add programs using GUI.

Lock screen after autologin - This is for ubuntu + gnome, but should work with anything using gnome.

The rare case

What you said on 2 is strange. If the program can actually run without the X server opened but fails when it is shutdown in that circunstance, it means that it is not necesarily a desktop environment issue: the program may not be closing properly and prevents the system from initializing it later (leaving some lock behind, for instance). You should provide logs or contact into the program's support forums to get instructions of how to close the program properly in any circumstances. It may even be a permission issue caused by a bug in the software which is not opening things in the proper mode. More details about the program should be provided, but as I said, it is allways better to contact with the software specific community.

Some generic hints of how to debug things like this:

• Read the logs. Normally errors like this show something in the log without any configuration: at the end of the day, a lot of problems are solved copy-pasting a single error line in Google. If you can't see anything, read about how to increase log level of your application (normally called debug level or verbosity). Look at the configuration files in case there are unknown log files or if your program outputs to syslog. You may actually need to modify something in your configuration file in order to make the program store logs in a file: investigate it, ask the community if the documentation is not clear enough.

• If program is poorly designed, it may not give you a chance to confingure proper logging, so you will need to activelly monitorice your process in order to see what does it access. You may find out that your program is leaving a lock behind or a PID file which is not properly handled and prevents new instances from starting. This may be a tedious process in big programs, specially if you dont have the experience. This is a VERY BASIC starting point that will allow you to grasp what is going on in your system: Linux monitoring tools 1 Linux monitoring tools 2

• Sandbox technology is also available on linux, and can be used not only for security, but also for testing purposes like this scenario. You can get a grasp on linux sandbox: Approeaches to sandboxing in linux , however, this approach usually requires time and experience.

EDIT:

In your situation, using this gui dependant script makes some sense, you dont need to switch it out.

I'm not a total GUI expert, but according to this there's a way to make KDE start autolocked. MAYBE there's a way in Gnome2 too, however, I'm not sure. The "autolock" script is an option, but as I said, it may end up beign a vulnerability, even if it just normally give some milliseconds. I'm not an expert in security, specially when it comes to desktop environments, so maybe there's no real liability, but from a theoretical point of view there's a potential breach there. Maybe having a less privileged user with a non-usable desktop layout mitigates your problem.