I'm trying to start a service via a script that I run through cron. Basically it just does this
/local/services/servicename status
/local/services/servicename stop
/local/services/servicename start
The service starts fine if I run the commands myself, but whenever I run it via the script, and I check for the service status manually, its response is always
Servicename Service is not running.
I am truly confuse right now. Any particular reason why a bash script wouldn't be able to start the services?
Not really an answer to your specific question, but definitely a useful tip for debugging cron behavior in general. Cron sends email messages to the user it runs as. If you run that in the root crontab, run the mail command in a terminal as root and you'll see the cron messages in your inbox. Check them by typing the message number (or man mail to learn how to use it).
Related
Im writing a tool and one of its commands allows you to start a new session
How can I make a golang program restart itself? If your solution is OS-Strict im on Linux.
I tried
// exec from os/exec
exec.Command(os.Args[0]).Run()
but it doesnt work. I get a blank input session which is hard to explain
My Program Input: session new
:(
:(
each of the :( represent a blank line where im able to type stuff and hit enter, there are 2 which means i hit enter twice
Im expecting
My Program Input: session new
My Program Input:
Edit: more accurately, i want to make a subprocess of the same program
You could use a separate process, like radovskyb/gobeat.
Example:
sudo gobeat -pid=1234 -cmd="go run sendemail.go"
Run with sudo so gobeat will restart the server in the same terminal tty that it originated in. (sudo)
Point gobeat to the process of the running server that you want gobeat to monitor. (gobeat -pid=1234)
Set the cmd flag to run a Go file that will send an email notifying you that the server was restarted. (-cmd="go run sendemail.go")
If you do not want a separate process, then consider implementing a graceful upgrade
You can use the library cloudflare/tableflip for instance.
I'm targeting ubuntu 22.04
I know how to use cloud-init to do simple stuff like runcmd and add user using users in the yaml.
I have two scripts that I like to be triggered via systemd
before-shutdown-script.sh : this script is to be triggered before the server is shutdown or before the server goes into reboot. The script's job is to call a webhook so network must at least be working before the script is activated. The webhook is simply to tell a centralized place, hey this server is powering down.
upon-bootup-script.sh : this script is to be triggered when the server is booted up. The script's job is to call a webhook so network must at least be working before the script is activated. The webhook is simply to tell a centralized place, hey this server has just booted up.
I am not confident of how to use systemd and how to use cloud-init to configure this. How should I script the cloud-init yaml?
I need to write a shell script in which I need to bounce the Tomcat server(it would possibly on anyone's system). Hence, I wanted to know how should I check if tomcat is ran as a service with "service tomcat6 start" or with the script "./bin/startup.sh"?
If this is for a production server: Assume that it's always started as a service. If you find out that it isn't: Find the person that started from the shell and fire them.
Hard words, but on production systems: Hand off, keep them operating according to a standard. If you automate the bouncing (restart): This is what you do.
Dangers when starting through startup.sh: The process will be started as whatever user executes the script - potentially lacking write permissions to the log and temp files, or ruining it for the next start through service tomcat start, when the service can't access those files any more.
Thinking of it: It might be a good idea to check (at least) the identity of the current user in startup.sh (or setenv.sh) and terminate if it's not the expected one. Thus effectively forbidding to ever run startup.sh as a regular user, including root.
I'm using Ubuntu. I have two bash script files. Both will run in parallel. Now I want to continuously monitor on another file that it is running or not.
So any way to find that the file is currently executing or not ?
Numerous possibilities, it is a question of creativity...
Some suggestions:
periodically poll the process list and filter it by name or process id
start the script with control sockets, as long as the sockets are open the script runs
use the usual locking strategy in file system.
have the script do a lifebeat on a regular base, then watch that lifebeat.
start the script in a series of commands, the moment the script exists the next command will be executed by the calling shell. That one could be a notification script or something.
have the script do some wiggling on your desktop and watch it yourself.
start it using nohup and watch the log file.
implement a deamon inside the script and connect periodically.
open a file from within the script and watch the file system using the fuser system call.
periodically write a token into a file by the monitoring script and have the monitored script remove that token, like a baton.
call the script using a blocking call. The script executes as long as that blocking call does not return.
create a singleton strategy on process level and simply try starting it periodically.
make the monitoring script act as a monitor deamon the executing script connects to. If the connection is terminated the scipt obviously has stopped executing.
...
Sorry, this starts getting boring...
I'm using an AutoIt script to start and automate a GUI application. I need to activate the script each hour.
Will AutoIt scripts (which perform actions on a GUI) work when used as a service? The script will be run as a service (not scheduled task).
You can easily make an autoit script run as a service using service.au3 written by archer of the autoit forums. Unfortunately or fortunately since it is a security measure. A service needs to start independent of the current user session (before login). It cant access send APIs for input manipulation of the current user session from there. It does sound much more like you need a scheduled task and not a service.
As mentioned above, a scheduled task is what you're looking for. To run a script as a service read this:
Q4. How can I run my script as a service?
This is also a question with multiple answers, and none of them are the only way to do it. The first question to ask yourself is whether or not you wish to install the service on other computers besides your own.
A1. If you only wish to install the service on your own computer, The easiest way to do this is to use Pirmasoft RunAsSvc. This program makes services easy to install and easy to remove when necessary.
A2. If you wish to make the service available to anyone running your script, you can use SRVANY.EXE and ServiceControl.au3. You can then use this code to install your script as a service:
#include "ServiceControl.au3"
$servicename = "MyServiceName"
_CreateService("", $servicename, "My AutoIt Script", "C:\Path_to_srvany.exe", "LocalSystem", "", 0x110)
RegWrite("HKLM\SYSTEM\CurrentControlSet\Services\" & $servicename & "\Parameters", "Application", "REG_SZ", #ScriptFullPath)
or use the following code to delete this service:
#include "ServiceControl.au3"
$servicename = "MyServiceName"
_DeleteService("", $servicename)
There is one caveat to setting up AutoIt as a service. If the service is not installed using the above code, it must have the "allow service to interact with the desktop" setting or else automation functions such as Control* or Win* functions will not function. To assure the service does indeed have this setting, use the following code:
RegWrite("HKLM\SYSTEM\CurrentControlSet\Services[ServiceName]", "Type", "REG_DWORD", 0x110)
Taken from the FAQ topic on the AutoIt Forums. www.autoitscript.com/forum/index.php?showtopic=37289)
It sounds like you're want to use a scheduled task instead of a service. Scheduled tasks can execute every hour, while you're logged in, and should also be able to interact with your desktop. Just remember that a task run as a normal user can not interact (send input) to a elevated program if you're using Vista/Windows Server 2008 with User Account Control enabled.