After starting, I can enter "commands" to the program via the terminal. Basically an admin console for a server app.

My question is this. 1) I may need more than one person to be able to send these console commands to said server, 2) I certainly want to be able to run this in the BG via a daemon so that I don't have to be logged in for it to be running.

The problem is that only the user who started the server can access the console, and if I move it to the bg, no one can send commands.

I'm wondering if there's perhaps some way to send commands to it via stdin? I have searched wide, but not far, and I haven't seen anything that I think will help, likely because I don't really know what I'm searching for.

If I'm understanding this correctly, this is running in a console on the command line.
There is actually a pretty simple solution that will both allow it to continue to run when your session disconnects,

Do you have the source code for the jar that you are running? If so you could probably write other Java code that uses that jar and gets the commands to it in another way. (It may even be possible to do that without the source code, but it would depend on how it was written)

Otherwise, I could suggest that maybe netcat may be able to help you. I am pretty sure that netcat can start up as a TCP socket server and pipe anything that it receives over a socket to its stdout, then you can just pipe that to you jar, eg.

nc <options> | /usr/bin/java -jar /prog/ram/jarfile.jar

It probably would take quite a bit of tweaking though to get it doing the right things. I don't have a linux box near me at the moment to test some things out for you.

I need to be able to send commands to a running process, not just at launch...

IE:
I run start.sh, which launches the server jarfile. It outputs various messages to the screen and then waits there for input. If I type stop for example, the server will shutdown. Or i can type various admin commands to affect the server.

No, only whatever is already in somefile will be passed into the process. Writing to it afterwards won't send anything additional into the process.

That's why both objects and I said you have to have a process that pipes into the java process (not just a static file)

nc <option> | java -jar jarfile.jar

This way nc (or whatever you can find to do what you want) stays running and so can continuously send input into the java process. You may be able to do something with a FIFO to do sort of what you are asking. ie..

Let me give you unconventional suggestion.
Install VNC server on this linux machine and run your server in VNC terminal.
This terminal will not bother you on the screen, and, more importantly, you or whoever you choose to charge with
it, will be able to access it from any platform and even from mobile and feed in the next
input. It is true it will probably be waiting more often than when you'll be reading from some file or pipe, but this system
will address at least some of your concerns, as far as I understood them.

You should be able to see what is going through the pipe by doing something like this...

echo wrapper | tee /tmp/command_log.txt | /usr/java/bin/java -Xms1024M -Xmx1024M -jar /prog/ram/somefile.jar &
"tee" will write what ever comes into it to that file while also sending it on to stdout, which we pipe into the java program. So you should be able to see your commands that you "echo" to the fifo, come up in that file

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

If I'm understanding this correctly, this is running in a console on the command line.

There is actually a pretty simple solution that will both allow it to continue to run when your session disconnects, and also allow multiple people to access the same session running the console (at the same time even).

It is the "screen" utility. If this works for you, no modification or wrappers are needed for the program in question.

How about "expect"? The kibbutz expect script allows two processes to share stdout and stdin, so it should be fairly easy either to use that directly, or to use the same principles to allow anyone to connect to stdout and stdin of the running Java program.

Other things to note:
I am running a damnsmalllinux distro and screen is not installed. Nor is gcc so that I could download and compile screen. I'm in the process of pouring over the DSL documentation/help to see if I can figure out how to get screen running - which sounds like it'll be very close to what i'm looking for.

OK, I understand, I didn't know you were not running X, but the basic thing is still similar - still no way to get into the process itself, but just
to get access to the screen - which will already help you.

My question is this. 1) I may need more than one person to be able to send these console commands to said server, 2) I certainly want to be able to run this in the BG via a daemon so that I don't have to be logged in for it to be running.

The problem is that only the user who started the server can access the console, and if I move it to the bg, no one can send commands.

Would you check the file permission on your start.sh? Is it appearing like this:

where it grants the ownership of the started-up process to admin/admingroup no matter who started/executed it (in this case you may let it started by the background daemon). At the same time grant every one in the admin group the execute right such that they may connect without problems.

Well, after all, to install minimal X on DSL and then run VNC is probably the simplest solution, which will
still be of use for access by several users, even though would not allow to get into the process itself.

Featured Post

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…

Introduction
This article is the first of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article explains our test automation goals. Then rationale is given for the tools we use to a…

Viewers learn about the “for” loop and how it works in Java. By comparing it to the while loop learned before, viewers can make the transition easily. You will learn about the formatting of the for loop as we write a program that prints even numbers…