I have a single instance of InDesign Server running on a Windows 2007 VPS, which runs a SOAP service on port 8081. This runs as a Windows Service and runs both dev and live JSX scripts, depending on the path of the script (we have a dev folder and a live folder).
I am having trouble running a new script, so would like to get access to the console of the running service, but I am struggling to find a reference to how to do this in the Adobe PDF docs. I know the script itself being found, since there are errors in the Windows Event Viewer for a specific code line, but I think it is having trouble locating JSXBIN resources. The error message just lists the variable in question, rather than the explicit path.
I have modified the script to output path information to stdout, but this doesn't get into the Event Log. So, can I get a window on the console of the running service? I don't want to stop the current service as that is in use for live.
Some ideas I've got from the docs:
InDesignServer -console
InDesignServer -LogToApplicationEventLog
I think this executable however starts up a new instance, which isn't what I want (either it would choose a new port number, or try with 8081 and fail to start since the port is in use - I've not tried either for obvious reasons). The flags respectively display stdout in the DOS window, and redirect std out to the Event Log.
In short, I don't think this is possible. I was hesitant to start a new instance on our live server in case it upset anything, but in fact it is quite safe; just ensure that the port you specify is different to your usual one.
InDesignServer -noconsole -port 10001
The noconsole connects stdout and stderr with the current DOS window - using console opens a new one, so it's the former you want.
Aside: it may be worth avoiding LogToApplicationEventLog, since the process can get disconnected from the console, which makes it fiddly to kill in a graceful manner.
Related
My project: go - 1.12.5; gin-gonic; vue-cli - 3.8.2.
On windows server 2008 go under the local account, run main.exe - works well. But when log off my account, all local account programs are closed, including my go server.
The first thing I did was try to configure IIS for my GO. Nothing good came of it.
Then I tried to run main.exe from the SYSTEM account psexec -s c:\rafd\main.exe. When log off the process does not close. But the frontend is in my account and SYSTEM does not see the local files (js, html, css) of my project
Tell me how to start the Go server, to after log off my project did not stop life
Two ways to approach it.
Go with ISS (or another web server).
Should you pick this option, you have further choices:
Leave your project's code as is, but
Make sure it's able to be told which socket to listen for connections on—so that you can tell it to listen, say, on localhost:8080.
For instance, teach your program to accept a command-line parameter for that—such as -listen or whatever.
Configure IIS in a way so that it reverse-proxies incoming HTTP requests on a certain virtual host and/or path prefix to a running instance of your server. You'll have to make the IIS configuration—the socket it proxies the requests to—and the way IIS starts your program agree with each other.
Rework the code to use FastCGI protocol instead.
This basically amounts to using net/fastcgi instead of net/http.
The upside is that IIS (even its dirt-old versions) support FastCGI out of the box.
The downsides are that FastCGI is beleived to be slightly slower than plain HTTP in Go, and that you'll lose the ability to run your program in the standalone mode.
Turn your program into a proper Windows™ service or "wrap" it with some helper tool to make it a Windows™ service.
The former is cleaner as it allows your program to actually be aware of control requests the Windows Service Management subsystem would send to you. You could also easily turn your program into a shrink-wrapped product, if/when needed. You could start with golang.org/x/sys/windows/svc.
The latter may be a bit easier, but YMMV.
If you'd like to explore this way, look for tools like srvany, nssm, winsv etc.
Note that of these, only srvany is provided by Microsoft® and, AFAIK, it's missing since Win7, W2k8, so your best built-in bet might be messing with sc.exe.
In either case, should you pick this route, you'll have to deal with the question of setting up proper permissions on your app's assets.
This question is reasonably complex in itself since there are many moving parts involved.
For a start, you have to make sure your assets are tried to be accessed not from "the process' current directory"—which may be essentially random when it runs as a service—but either from the place the process was explicitly told about when run (via command-line option or whatever) or figured out somehow using a reasonably engeneered guess (and this is a complicated topic in itself).
Next, you either have to make sure the account your Windows™ uses to run your service really has the permissions to access the place your assets are stored in.
Another possibility is to add a dedicated account and make the SCM use it for running your service.
Note that in either case proper error handling and their reporting is paramount: when your program is being run non-interactively, you want to know when something goes wrong: socket failed to be opened or listened on, assets not found, access was denied when trying to open an asset file, and so on—in all these cases you have to 1) handle the error, and 2) report it in a way you can deal with it.
For a non-interactive Windows™ program the best way may be to use the Event Log (say, via golang.org/x/sys/windows/svc/eventlog).
Simplest solutions would be using windows schedular.
Start your exe file on system logon with highest privilage in background. So whenever your system will logon it will start your exe and make runnign in background.
You can refer this answer,
How do I set a Windows scheduled task to run in the background?
If I run a website using a http_deamon on a server is it possible to ssh into the server then open the prolog interface, run some queries, notably make and close the interface with the website still running?
Yes, it's possible to reload definitions with a running HTTP server.
Steps to reproduce:
Start a screen or tmux session. This lets you detach the terminal to log in later into the same session.
Start the server. With the HTTP daemon library, use the --interactive flag to get an interactive toplevel.
Detach the session.
Log out.
At any later time, to reload definitions while the server is still running, simply:
log in again
re-attach the session
run ?- make. as usual.
Caveat: With the HTTP Unix daemon, make/0 currently some issues, but you can always start an HTTP server also without using the http_unix_daemon library, and in that case make/0 works more nicely.
An alternative is to simply provide a special URL handler that runs make/0 within the server when that URL is accessed. Again, it may not work smoothly with the Unix daemon library, but typically when run without it.
I am trying to run console application (say win_a.exe; which is having few command line parameters) from ruby script(say lin_r.rb) on linux. win_a.exe is interacting with windows services on windows server 2008. I want to run win_a.exe at particular point via lin_r.rb (reason is that, at this time; I am having few parameters those need to be passed to win_a.exe and get some result)
I searched online but I did not get any useful links.
One solution in my mind is:
create the NFS share on windows and map that to linux.
Linux: write parameter/command in a new file(should be created on NFS share) from lin_r.rb
Window: watchdog program(need to write this) looking for a new file. If found execute win_a.exe with parameters and write result to new out file.
Linux: Yey! Got result
Is this good approach? What do you think?
Thanks, Vipul
Your approach could be made to work, however If I were implementing this, I would use HTTP instead of NFS. Likely both computers involved already are capable of making and receiving HTTP requests, so the setup should be less than NFS.
The basic approach would be to have the linux based script make an HTTP request to the windows machine, with the parameters to the .exe specified as query parameters (if you use a GET request). On the windows side, your "watchdog" program would be a small web service that would respond to the request from the linux machine, execute the program with the specified options, and return the result.
The web service on the windows machine can use whatever technology you prefer. I would likely use Sinatra+Thin, but the choice is up to you.
Whichever approach you take, NFS based, HTTP based, or something else, you should make sure you give thought to security. That means that you should not blindly pass the arguments you receive from lin_r.rb to the win_a.exe program. You should only accept specific arguments, and you should make some effort to verify that the person making the request (or writing the file if you use NFS) is someone who you have authorized to have access.
I'm currently working on a command line tool and since this is my first time designing a tool like this I have a few design questions, most notably how to handle a non lethal error.
The tool that I'm working on raises a main server on a configurable port and after that an optional web server on a non configurable port. If we then choose to do this again (while using a different port for the main server) we would obviously get an binding error when try to start up the optional web server.
Since this is a non lethal error (running the webserver is optional) and from UI experience my initial thoughts would be to print out a clear error and carry on with the program. However I've been told that from a scripting stand point print out the error and then existing is better practice.
So what is the better?
You might also want to consider that people might want to write scripts which expect the invocation to succeed even if the webserver is already running.
If you define a default behavior of 'fail if webserver already running', then such scripts will have to parse your error message, or read/understand your return value and figure out that the invocation failed for this particular reason (i.e. webserver already running).
Give them a way out of this and introduce a flag (argument) where they can decide which behavior they want. In the absence of the flag, do the safer thing maybe (i.e. error out if webserver is running).
I have a C++ Windows application that was designed to be a Windows service. It executes an updater periodically to see if there's a new version. To execute the updater, _execv() is used. The updater looks for new versions, downloads them and stops the Windows service (all of these actions are logged), replaces the files, and starts the service again. Doing that in CLI mode (not going into service mode) works fine that way. According to my log files, the child process is launched, but the parent process (the Windows service) exits.
Is it even "allowed" to launch child processes in Windows services, and, why does the service exit unexpected then? My log files show no error (I am even monitoring for segfaults etc which is written to the log).
Why are you using _execv() rather than doing it the windows way and using CreateProcess()?
I assume you've put some debug into your service and you aren't getting past the point where you call _execv() in your service?
_execv replaces the existing process with a new one running the file you pass as the parameter. Under Unix (and similar) that's handled directly/natively. Windows, however, doesn't support that directly -- so it's done by having the parent process exit and arrange for a child process to be started as soon as it does.
IOW, it sounds like _execv is doing exactly what it's designed to -- but in this case, it's probably not what you really want. You can spawn a process from a service, but you generally want to use CreateProcessAsUser to create it under a specified account instead of the service account (which has a rather unusual set of rights assigned to it). The service process will then exit and restart when it's asked to by the service manager when your updater calls ControlService, CreateService, etc.