Advice and guidance needed please to start windows program using wine with a cron job

English Applications
#1

I have a Leap 15.4 KDE system full updated. I have four Windows programs running using wine and can start them fine using a .desktop file and the program(s) start and run using a Wine virtual desktop window. I have installed dex which works also to start these programs with this command in a Konsole window

dex WXSIMate.desktop > /dev/null 2>&1

and the WXSIMate program starts and runs fine with no additional output in the Konsole window.

Now I need to run these programs on a timed basis and thought a cron job would work using the above command. I created a cron job for my user using the Task Manager panel in KDE systemsettings and when I list it in the user crontab it looks like

17 15 * * *      /usr/bin/dex WXSIMate.desktop > /dev/null 2>&1

and runs OK when I execute it manually from systemsettings (using the Run Now button), unfortunately it leaves a Konsole window open with an end of script message which I have to close manually. However when left to run on schedule at 15:17 nothing seems to happen and the program does not start.

So is there anything obvious that I have missed or something I need to do differently to make this work?

Stuart

#2

I have no idea running Wine or related stuff, but in a cron job you better define all files with absolute path. So when WXSIMate.desktop is a file, then better add the complete path (like you did with /usr/bin/dex).

#3

Well I have now tried

1 16 * * *      /usr/bin/dex /home/stuart/Desktop/WXSIMate.desktop > /dev/null 2>&1

and it makes no difference.

Is there any way to see what happens ā€˜under the coversā€™ when the scheduled time arrives so I can tell what if anything is actually happening?

Stuart

#4

You can test what cron would do by running
env -i /usr/bin/dex /home/stuart/Desktop/WXSIMate.desktop > /dev/null 2>&1
i.e. with an empty environment. Usually, environment variables have to be defined in the crontab. See man 5 crontab. You should be able to tell from the output of the env command which variables those are.

#5

And apart from the good hint to find out if environment variables are needed, you seem to expect output that you send to /dev/null. Instead sending to a file and inspecting the file could give some clue.

#6

OK so if I run env -i as suggested it fails to start and says it canā€™t find a display. However the command without the env works and starts the program in a Wine Desktop window and runs. If I leave out the bit about /dev/null etc it does produce some messages but nothing which stops the program from starting OK in the Wine Desktop window.

There is obviously enough defined in the .desktop file for the program to run it. All Iā€™m trying to do is to be able to schedule running it in a cron job.

Stuart

#7

Try putting your commands in a script and running the script in crontab. I always do it that way.

1 Like
#8

This must be a very old one for you. But we do not like talking like this. We want to see what prompt/command you used and the complete output including the next prompt line.
In this case

crontab -l

And I support @peteh100 's suggestion. It is always more handy to call a script of your own and then test altering the script.

#9

That is very likely the problem, these programs likely must have a display and running them without does not work.
So try setting the display.

$ echo $DISPLAY
:1

That is for my computer, for your computer it is likely ā€œ:0ā€. Then edit cron and make the entry

17 15 * * * export DISPLAY=:0 /usr/bin/dex WXSIMate.desktop > /tmp/mycrontab.log 2>&1

If that does not work it might be you have to make it run as under your user account.

Side-tip: Try start using systemd timers.

#10

That can not be correct. That is an export command, not a command with an added environment variable before it. I assume you mean
17 15 * * * DISPLAY=:0 /usr/bin/dex WXSIMate.desktop > /tmp/mycrontab.log 2>&1

But yes, this is probably the old case of startimg a program in the background that then wants to opena window in a desktop that may be available or not.

Many people to not understand that Unix/Linux is a multi-user/multi-session operating system. Thus there can be none, one, two, more sessions open at the same time, those sessions belonging to different users.

And even if one of those sessions is chosen (with the DISPLAY variable) then still the session owner must probably allow outside programs to open windows (see 'xhost +`).

#11

Indeed it is not correct:

$ export MYTESTVAR="test" echo $MYTESTVAR
<nothing>
$  MYTESTVAR="test" echo $MYTESTVAR
test
$ export MYTESTVAR="test" && echo $MYTESTVAR
test

So I missed the &&

I did add export to have the DISPLAY variable passed to child processes.

One warning on ā€œxhost +ā€, xhost + is a huge security hole.

#12
  1. The first is a nonsense statement.
  2. The second adds the variable only to the execution of the echo command.
  3. The third is in fact two commands of which the first creates the variable in the current process and exports it to all eventual child processes; the second shows it to prove that it is in the environment.

Making it more complicated by using the && (why not simply a ; ? Are you afraid that the export fails?) is not needed. As I show it to you in the earlier post, it will only add the variable and itā€™s value to the environment of the process started by the command and only to that process, not polluting the current process.

Same for that what we advice to many to show command output in English on systems with another language:

LANG=LC zypper lr -d

The LANG=LC is in the environment of zypper without changing anything in the current environment.

And yes, xhost is a security hole. As is the very fact that someone wants even to try to open a window from outside a GUI session as the OP here seems to want.

#13

The correct way to specify environment variables in the cronfile is to put them in a separate lines.

DISPLAY=:0
17 15 * * * /usr/bin/dex WXSIMate.desktop > /tmp/mycrontab.log 2>&1

Try

env -i DIPLAY=:0 /usr/bin/dex WXSIMate.desktop

to check first whether the command now runs (use the correct display of course).

#14

Just recently it was extensively discussed how to start GUI program outside of session.

1 Like