Linux VM - TriggerCMD shows messages like it's working, but commands don't actually execute

Joe

Here is the result (run as me, not as root -- for root nothing happens):

[jhupcey@orw-mobile-vm ~]$ triggercmdagent --console
squirrelEvent --console
/usr/share/triggercmdagent/triggercmdagent --console: symbol lookup error: /usr/share/triggercmdagent/triggercmdagent --console: undefined symbol: gtk_widget_get_scale_factor
[jhupcey@orw-mobile-vm ~]$

Possibly related: looking at the timestamps in /root/.TRIGGERcmdData (above) all the timestamps are from the initial install. My point being: whatever I run as me, does it get superceeded by this "stale" root stuff ? Hence, to do a pure UNinstall, should I do some sort of "rm -r" all this, stop some systemctl service, rm -r the <my_home>/.TRIGGERcmdData?

Joe

Update: apologies -- I didn't see the second part of your prior comment.

I will delete both the root and my .TRIGGERcmdData folders and start over.

Stay tuned ...

Joe

Update:
So I blew away the root and my own .TRIGGERcmdData directories, and did a fresh "yum" install. It asked me for my token, etc.

The good news is the "Computer" as reappeared in the list. However, no triggers are there.

Back on the Linux VM:

I still get the familiar error message:

[jhupcey@orw-mobile-vm ~]$ triggercmdagent --console
squirrelEvent --console
/usr/share/triggercmdagent/triggercmdagent --console: symbol lookup error: /usr/share/triggercmdagent/triggercmdagent --console: undefined symbol: gtk_widget_get_scale_factor
[jhupcey@orw-mobile-vm ~]$

and I also tried running agent.js directly as noted above, and got this:

[jhupcey@orw-mobile-vm src]$ pwd
/usr/share/triggercmdagent/resources/app/src
[jhupcey@orw-mobile-vm src]$ 
[jhupcey@orw-mobile-vm src]$ node agent.js --console
Run installdaemon.sh to install the triggercmdagent daemon so it runs during boot
Daemon install: false
Logging in with saved token.
Checking if the  computer exists.
This computer exists in your account.
Tokenfile: /home/jhupcey/.TRIGGERcmdData/token.tkn
ComputerIDfile: /home/jhupcey/.TRIGGERcmdData/computerid.cfg
Logging in with saved token to run foreground tasks.
SyntaxError: Unexpected end of JSON input
    at Object.parse (native)
    at updateCmds (/usr/share/triggercmdagent/resources/app/src/agent.js:429:24)
    at /usr/share/triggercmdagent/resources/app/src/agent.js:274:5
    at initFiles (/usr/share/triggercmdagent/resources/app/src/agent.js:124:3)
    at foreground (/usr/share/triggercmdagent/resources/app/src/agent.js:270:3)
    at /usr/share/triggercmdagent/resources/app/src/agent.js:164:13
    at Request._callback (/usr/share/triggercmdagent/resources/app/src/agent.js:239:11)
    at Request.self.callback (/usr/share/triggercmdagent/resources/app/node_modules/request/request.js:185:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
Restoring the last known good file
Restore backup completed.
[jhupcey@orw-mobile-vm src]$

Joe

Edited to add, since the above called out a JSON error, be advised I haven't touched commands.json in either root or my home area

The root commands.json is the default from the install, and the commands.json in my area is 0 bytes/empty

Russ

@Joe, I'm glad you tried running node agent.js --console

That's very strange that it couldn't parse the commands.json file. Please try this:

cp /usr/share/triggercmdagent/resources/app/src/linuxcommands.json /home/jhupcey/.TRIGGERcmdData/commands.json

Then re-run that node agent.js --console command.

Also, please show me the output of this command. I'd like to know what version of node js you're running:

node -v

Joe

@Russ, here are the results -- all run as me in my home directory:

[jhupcey@orw-mobile-vm ~]$ pwd
/home/jhupcey
[jhupcey@orw-mobile-vm ~]$ 
[jhupcey@orw-mobile-vm ~]$ cp /usr/share/triggercmdagent/resources/app/src/linuxcommands.json /home/jhupcey/.TRIGGERcmdData/commands.json
[jhupcey@orw-mobile-vm ~]$ node agent.js --console
module.js:471
    throw err;
    ^

Error: Cannot find module '/home/jhupcey/agent.js'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:393:7)
    at startup (bootstrap_node.js:150:9)
    at bootstrap_node.js:508:3
[jhupcey@orw-mobile-vm ~]$ node -v
v6.10.2
[jhupcey@orw-mobile-vm ~]$

Russ

@Joe, sorry I meant for you to be in the src directory when you run the agent.js file like you where earlier.

That node version seems old. I'll try that version myself and see if I get a .json parse problem.

EDIT: I tried node v6.10.2 and it worked fine for me, so that's not the reason for the .json parsing problem.

Joe

Thanks for the update, @Russ!

First, this isn't super urgent, so please enjoy the holiday weekend and we'll reconnect Tuesday

Since I had basic functionality working before the "uninstall" (which I could live with at a "work around" level of functionality to get my project going), it suggests that the uninstall process / guidelines are missing steps to get me back to time zero. Hence, I ask, before I do another fresh RPM re-install:

What are all the directories and files I need to remove -- both in the root areas, and in a user home area?
What daemons and other processes need to be killed?

Joe

Russ

@Joe, I enjoy doing this - I don't mind doing it on a holiday.

Here are the steps I think should be adequate to start from scratch:

sudo su -
systemctl stop triggercmdagent
/usr/share/triggercmdagent/resources/app/src/removedaemon.sh
yum remove triggercmdagent
rm -rf /usr/share/triggercmdagent
rm -rf /root/.TRIGGERcmdData
rm -rf /home/(your user)/.TRIGGERcmdData

Joe

Update:

I did a scorched earth deletion as listed above, plus did "ps -aux | grep cmd" to find and kill any remaining processes
I did the yum install (systemctl seemed to need to be run under sudo in order to work), got asked for my token, etc.
I also went to /usr/share/triggercmdagent/resources/app/src to run installdaemon.sh (which needed sudo to be happy)

The good news:

The "Computer" re-appeared in https://www.triggercmd.com/user/computer/list !
In the "Trigger" list, the Gnome Editor appears, and in-fact fires up perfectly when I click the green "Trigger" button! Yeah!

Now, the less good news:

ONLY the the Gnome Editor appears in the Trigger list, despite my local/personal commands.json being setup as follows (where I deleted the "Reboot" trigger, and added in my hello_world.sh script):

[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$ pwd
/home/jhupcey/.TRIGGERcmdData
[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$ 
[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$ more commands.json
[
  {"trigger":"Gnome Editor","command":"gedit","ground":"foreground","voice":"edit","allowParams": "false"},
  {"trigger":"yum update","command":"yum -y update","ground":"background","voice":"yum update","allowParams": "false"},
  {"trigger":"apt update","command":"apt-get -y update","ground":"background","voice":"update","allowParams": "false"},
  {"trigger":"hello world","command":"\/home\/jhupcey\/hello_world.sh","ground":"background","voice":"hello world","allowParams": "false"}
]
[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$

Incidentally, when I save this file, I get the following promising messages:

[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$ vi commands.json
[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$ Write backup completed.
Initiated command removals
Initiated command adds

[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$

FWIW, the commands.json in the root area (that the installdaemon.sh seemed to generate ) is the default:

[root@orw-mobile-vm .TRIGGERcmdData]# pwd
/root/.TRIGGERcmdData
[root@orw-mobile-vm .TRIGGERcmdData]# more commands.json 
[
  {"trigger":"Reboot","command":"shutdown -r","ground":"background","voice":"reboot","allowParams": "false"},
  {"trigger":"Gnome Editor","command":"gedit","ground":"foreground","voice":"edit","allowParams": "false"},
  {"trigger":"yum update","command":"yum -y update","ground":"background","voice":"yum update","allowParams": "false"},
  {"trigger":"apt update","command":"apt-get -y update","ground":"background","voice":"update","allowParams": "false"}
]
[root@orw-mobile-vm .TRIGGERcmdData]#

Again, one would expect to see the extra triggers on the Computer webpage -- not just the Gnome Editor trigger -- given either of these commands.json

So close ...

Russ

@Joe, I can explain why you're only seeing Gnome Editor.

The foreground agent only runs, adds, and removes foreground commands. Gnome Editor is a foreground command. You're only running the foreground agent.

You seem to have run the foreground agent under root too, which would have added a second computer with a different computer ID. You can see the ID in ~/.TRIGGERcmdData/computerid.cfg. Then you installed the background agent under root using root's home directory by running installdaemon.sh as root.

You should delete the /root/.TRIGGERcmdData directory and the corresponding computer record in your account, so all you have is the /home/jhupcey/.TRIGGERcmdData/computerid.cfg computer. Then, while logged in as jhupcey, I think if you run this, it will install the background agent and configure it to use /home/jhupcey/.TRIGGERcmdData:

sudo sh /usr/share/triggercmdagent/resources/app/src/removedaemon.sh
sudo sh /usr/share/triggercmdagent/resources/app/src/installdaemon.sh

I don't have time to test this right now - I can later today though. I realize I need to do that and produce some better documentation on this. Sorry about that.

EDIT: I downloaded the Centos DVD. I'll install it and test this tomorrow.

Joe

Good news, @Russ : I'm back in business with hello_world.sh!

Interesting news: it took a few more steps in addition to what you noted above. Specifically:

1 - I deleted the Computer, and deleted the /root/.TRIGGERcmdData directory

2 - For some reason neither installdaemon.sh nor removedaemon.sh in /usr/share/triggercmdagent/resources/app/src had execute permissions, so I had to sudo chmod 755 both of them to get them to run. (Is this a bug in the RPM, or did I make an install mistake somehow?)

3 - Now running installdaemon.sh gave me the following promising output:

[jhupcey@orw-mobile-vm ~]$ sudo sh /usr/share/triggercmdagent/resources/app/src/installdaemon.sh 
Daemon install: true
No token exists.  Login to request one.
prompt: token:  triggercmdagent.service - TRIGGERcmd Agent
   Loaded: loaded (/etc/systemd/system/triggercmdagent.service; enabled)
   Active: active (running) since Wed 2020-05-27 20:23:33 PDT; 106ms ago
 Main PID: 15920 (node)
   CGroup: /system.slice/triggercmdagent.service
           \u2514\u250015920 node /usr/share/triggercmdagent/resources/app/src/daemon.js --run /root/.TRIGGERcmdData

May 27 20:23:33 orw-mobile-vm systemd[1]: Started TRIGGERcmd Agent.
[jhupcey@orw-mobile-vm ~]$

3 - Still, a new Computer did not reappear. However, this was not a surprise given the "No token exists. Login to request one." message above.

4 - Hence, playing a hunch (or if you prefer, shooting in the twilight), I re-ran in my area:

sudo systemctl start triggercmdagent

then

node /usr/share/triggercmdagent/resources/app/src/agent.js --console

which prompted me for my token, which it digested and I got the comforting message with the text sail boat, etc. which finished with "Added Gnome Editor" -- but nothing else was reported as "Added".

5 - Recalling the "foreground" note in your immediately prior post, I edited my commands.json to have hello_world.sh be a "foreground" thing, and viola! -- it appeared along with Gnome Editor as a Trigger, and executes as expected.

6 - Oddly, anything listed as "background" doesn't get "Added" or appear in the Triggers. To confirm this, I added back in an entry for Gnome Calculator -- first as "background" -- nada; then as "foreground", which upon saving commands.json produced the message "Added Gnome Calculator" was reported, and it appeared as a Trigger.

To summarize, my current commands.json file is as follows:

[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$ more commands.json
[
  {"trigger":"Gnome Editor","command":"gedit","ground":"foreground","voice":"edit","allowParams": "false"},
  {"trigger":"Gnome Calculator","command":"gnome-calculator","ground":"foreground","voice":"calculator","allowParams": "false"},
  {"trigger":"yum update","command":"yum -y update","ground":"background","voice":"yum update","allowParams": "false"},
  {"trigger":"apt update","command":"apt-get -y update","ground":"background","voice":"update","allowParams": "false"},
  {"trigger":"hello world","command":"\/home\/jhupcey\/hello_world.sh","ground":"foreground","voice":"hello world","allowParams": "false"}
]
[jhupcey@orw-mobile-vm ~/.TRIGGERcmdData]$

Again, anything listed as "background" does not appear as a trigger.

That said, since I can now execute a bash script and invoke a program via The System, I'm back-in-business; and this foreground-background distinction is only of academic interest at this point (or am I missing out?)

Finally, I truly appreciate all your diligent support!!! Many thanks!!!

Russ

@Joe, I'm glad you've got it working with the foreground agent. I realize I need to clear up how to get the background agent installed. Until I saw your output, I actually was thinking the background service could run as root but share your user's /home/jhupcey/.TRIGGERcmdData folder, but that was my mistake because I see it automatically pointed to /root/.TRIGGERcmdData. Sorry, I had it confused in my head with Windows where the background service uses the user's .TRIGGERcmdData folder.

The benefits of the background service are:

It can startup automatically during boot
It runs as root, so it can run more powerful commands.

But, on Linux you'd need a separate computer object in your account, associated with your /root/.TRIGGERcmdData folder to use the background service.

Joe

Ahhh -- now most of the issues above make sense.

Simply restated, to see if I get it:

1 - Only Foreground Triggers work in a user's regular account

2 - Root can support both Foreground and Background Triggers

3 - But running Triggers as Root will mask/override all the Triggers in your regular account

4 - The exception to (3) is if you can instantiate two "Computers" -- one pointing to Root for the "Background", and a separate "Computer" pointing to your normal Linux account to support the "Foreground"

So how do you setup two Computers -- one for root and one for regular accounts -- pointing to the same physical machine?

Related: how do you create separate Computers associated with different regular Linux accounts all run on the same machine? e.g. if you wanted anyone logged into a given machine/VM to enjoy the same set of Triggers, would you ONLY install triggercmdagent+ as root so everyone can tie into them?

Somewhat related: are Linux user accounts the key point of connection to the Mother Ship, or the machines MAC address, or what?

Russ

@Joe,

1 - Only Foreground Triggers work in a user's regular account - because the background service only runs as root and uses /root/.TRIGGERcmdData.

2 - Root can support both Foreground and Background Triggers - because you can install the background service (see #1), and because you can login as root and run the agent in foreground mode.

3 - ~~But running Triggers as Root will mask/override all the Triggers in your regular account~~ - I wouldn't say mask/override, it's just separate as you covered in #4. Running the agent as root will create another separate computer entry in your account associated with /root/.TRIGGERcmdData. That computer will be named the same initially, but you could rename it.

4 - The exception to (3) is if you can instantiate two "Computers" -- one pointing to Root for the "Background", and a separate "Computer" pointing to your normal Linux account to support the "Foreground" - correct, although as you pointed out in #2, you could also run the foreground agent as root.

You create a separate computer just by running the agent as the other user. If the ~/.TRIGGERcmdData directory doesn't exist, the agent will prompt you for a token, create a computer record in your account, and store the ID for that computer in the computerid.cfg file.

Different Linux accounts could setup different computer records, or you could give everyone sudo access to be able to edit /root/.TRIGGERcmdData/commands.json to run background command via the background agent.

The agent stores the .TRIGGERcmdData directory in the home folder of the user running the agent. The files in that directory are the key point of connection to the mother ship.

Good questions @Joe.