fluxbox restart mod keys in a script

[VastOne]

I am looking for a way to restart fluxbox every 90 seconds... I need to do this because of how I use this server on a big screen TV and access it via nomachine.. When I do this it causes fluxbox to lose it's mind and a restart from the menu works to restore order

I also have created a mod key sequence in ~/.fluxbox/keys file as

Code Select Expand

Mod1 F7 :Restart

and it works fine... I need to now run that key sequence every 90 seconds from a script.. Conky makes the most sense since it runs all the time anyway... doing something like

Code Select Expand

${execpi 90 Mod1 F7 :Restart}

Anyone done this?

@PackRat?

@Jedi?

[PackRat]

Conky won't run a key binding or an window manager internal command, you would have to set up an xdotool command to simulate the key sequence - more trouble than it's worth IMO.

If you want to run it in conky:

${execpi 90  pkill -x -USR1 fluxbox}

or set that command up as a cron job.

[PackRat]

I use this server on a big screen TV and access it via nomachine.

You mean via ssh?

Looked it up - you mean this?

When I do this it causes fluxbox to lose it's mind and a restart from the menu works to restore order

Just one restart required?

May be best to code a script that restarts fluxbox after the remote access.

Why is a 90 second restart frequency required? Fluxbox loose it's mind every 90 seconds thereabouts?

[PackRat]

How does nomachine work? You apparently log into it, but is there something similar to dhcp going on where it provides a lease - like every 90 seconds maybe?

Is there some configuration on the host you can change?

[VastOne]

nomachine is just a headless server tool... All I do is access full gui from one machine to the other.. It is very light and easy to use .. the secondary server is a KODI and the V-Ger server so I access it frequently and just do not want a separate monitor KB and mouse

I see this same behavior from when changing hdmi ports on this machine (or any fluxbox machine) and all that it does is cause tint2 to switch to the top left and windows borders disappear.. a restart of fluxbox fixes it

As far as 90 seconds goes, that is just arbitrary... I really do not care how long it is, 90 seconds is good knowing that when I log into the server with nomachine I can get a cup of coffee and get back to a correct screen

[VastOne]

I use this server on a big screen TV and access it via nomachine.

You mean via ssh?

Looked it up - you mean this?

When I do this it causes fluxbox to lose it's mind and a restart from the menu works to restore order

Just one restart required?

May be best to code a script that restarts fluxbox after the remote access.

Why is a 90 second restart frequency required? Fluxbox loose it's mind every 90 seconds thereabouts?

pkill -x -USR1 fluxbox does not work from terminal so need something else..

Just one restart is needed, yes, until I access the machine again

nomachine is just access over tcpip and the machine itself (the KODI/V-Ger machine stays static always) so I can run a script at anytime .. the ideal setting would be a cron that recognized a nomachine access and restarting fluxbox .. but that seems like over kill when since conky runs all the time I can just set a execpi as a perfect tool with a timer

[PackRat]

pkill -x -USR1 fluxbox does not work from terminal so need something else..

That's apparently a Debian (Sid) security thing; works with conky, tint2, but not the window manager. Works on the wm in Void.

Try -

Code Select Expand

xdotool key alt+F7


and see if that works; it's working with my VSIDO fluxbox restart key binding - "Super + q"

[VastOne]

Code Select Expand

xdotool key alt+F7

is the winner....

I knew I could use xdotool, I just wanted to see if any new or existing fluxbox scripting could be used

Thanks RatMan I knew you would solve this

[VastOne]

Code Select Expand

${execpi 90 xdotool key alt+F7}

is the final bit of code..

[PackRat]

all that it does is cause tint2 to switch to the top left and windows borders disappear

Those are the only issues? You can otherwise use fluxbox as intended?

Thought about this some more, the closest I've come to an issue like this is when using tmux or emacs with fluxbox. Starting either, wouldn't crash the window manager, but fluxbox wouldn't respond correctly to any mouse or keyboard input - like it got reconfigured.

Turned out to be a key binding collision between fluxbox and either tmux or emacs. Made a couple changes to ~/.fluxbox/keys and tmux.conf and all was right with the world. Does nomachine have some default keybindings so you can administer the system from a console? If so, see if they conflict with your ~/.fluxbox/keys file.

[VastOne]

I brought up nomachine because this issue happens frequently within it.. It also happens every time you change any video port.. Change from hdmi1 to hdmi2 or DVI  to hdmi1.. It can just as easily be an X11 issue but it only affects fluxbox..

I have seen and known about this for years but never really cared to solve it because how often do you change video ports on a live machine?

Thanks RatMan

[DeepDayze]

Maybe this is either a quirk in how Fluxbox interacts with nomachine?

[VastOne]

I can reproduce it 100% of the time without nomachine by simply unplugging the video from the PC and plugging it back in

[PackRat]

@vastone -

Do you start fluxbox so that it keeps an event log?

in the $HOME/.fluxbox/startup:

Code Select Expand

# exec fluxbox
# or if you want to keep a log:
exec fluxbox -log "$HOME/.fluxbox/log"

Be interesting to see if something was generated for this. May be worth a bug report?

[VastOne]

I created the log and recreated the issue and nothing is generated in that log.. Good suggestion RatMan

I have long suspected this as being an X11 issue and really with the xdotool fix I am very satisfied with it