I need to do call diverts(redirects) on SIM card which is used by gammu sms daemon all the time.
The divert operation can be done few times per day.
Gammu sms daemon is occupying communication with GSM modem 24h/day.
I cannot send any AT command to port, while daemon is running.
Gammu tool(not daemon) have ready to use commands to divert calls, and they work perfectly, while daemon is stopped.
Of course, when daemon is running command correctly claims, that port is busy.
Is there any way to gently inject AT commands to gammu-smsd, and read the response?
My idea is to:
1. Stop daemon.
2. Perform call divert, read the result
3. Start daemon
but this idea don't look like smart or elegant solution.
If injecting commands to sms daemon is not possible, is there any gentle way to stop the daemon not by killing process? I don't want to interrupt daemon work, while it is sending SMS.
You can use SIGUSR1 and SIGUSR2 to suspend and resume the daemon and use Gammu command line while SMSD is suspended.
See Gammu SMSD Signals Documentation for more information. There is even example for this:
SMSD_PID=`pidof gammu-smsd`
if [ -z "$SMSD_PID" ] ; then
echo "Failed to figure out SMSD PID!"
else
kill -SIGUSR1 $SMSD_PID
gammu identify
kill -SIGUSR2 $SMSD_PID
fi
Related
I am using a systemd service which calls a process when it's been "started" (e.g. systemctl start test.service). As per the design, the process stays in a loop forever, we are able to see process existence using the ps command. We have also seen that the process is getting killed (as intended) for systemctl stop command.
However, our requirement is that we want to do some safe shutdown operations from within the process before it gets killed. But I am not sure how to detect a systemd stop operation from within the process.
Does a systemctl stop test.service command send SIGKILL or SIGTERM signal to kill the process? How can I detect a systemctl stop operation from within a process?
By default, a SIGTERM is sent, followed by 90 seconds of waiting followed by a SIGKILL.
Killing processes with systemd is very customizable and well-documented.
I recommend reading all of man systemd.kill as well as reading about ExecStop= in man systemd.service.
To respond to those signals, refer to the signal handling documentation for the language you are using.
Does a systemctl stop test.service command send SIGKILL or SIGTERM signal to kill the
process? How can i detect a systemctl stop operation from within a process?
Systemd sends SIGTERM signal to process. In process you have to register signals, which are "caught".
In process, eg. SIGTERM signal can be registered like this:
void signal_callback()
{
printf("Process is going down\n");
}
signal(SIGTERM, signal_callback)
When SIGTERM is sent to the process, the signal_callback() function is executed.
I'm trying to use gammu and gammu-smsd to send and receive sms with my raspberry pi using a Huawei intrnet key.
My problem is that when I send an sms from my phone to raspberry pi, it read the sms, it try to start the program linked at RunOnReceive = in /etc/gammu-smsdrcn file but then, it says: Process failed with exit status 1.
I tried any kind of solution but I'm not capable to solve this problem by my self; I've set each permission on the script.
Can someone help me?
Thank you a lot.
You no doubt have this sorted by now, but I have just been through the same trip, tore out a lot of hair and finally made it out the back .... :-)
I'm using a ZTE stick with wvdial for internet connection. The stick appears as modems on /dev/USBtty0, 1 and 2. wvdial uses USBtty2, so gammu (I think) has to use a different one.
So I installed gammu/gammu-smsd on USBtty1 in gammu-config and /etc/gammu-smsdrc. The receive daemon gammu-smsd fires up automatically on boot.
First trap for young players - if you want to send an SMS with
echo "whatever" | gammu sendsms TEXT xxxyyyzzzz (where the last is the phone no) - you need to kill the receive daemon for that to work ie
service gammu-smsd stop # kill receive daemon
echo etc etc gammu etc etc # send the SMS
service gammu-smsd start # revive the receive daemon
Now for the RunOnReceive thing ...
start with sudovi - gives some config file to edit. There's a line in there about pi BLAH-BLAH-BLAH as a sudoer. Duplicate it with gammu BLAH-BLAH-BLAH. Same BLAHs. Save it.
It's something to do with permissions - I'm not an expert here :-)
So my RunOnReceive line is { sudo /home/pi/procSMS.sh $SMS_1_TEXT }
The script didn't seem to know what $SMS_1_TEXT was, so I passed it through as a parameter - inside the script it's treated as $1. It works.
While testing I ran a process in another window - just tail -f /var/log/syslog which lets you watch it all in real time ...
I was getting the same error on Raspberry Pi in combination with Huawei E3131 (Process failed with exit status 1) but I solved it.
make sure you have file permissions set well. Gammu runs deamon under "gammu" user by default. So you can change it (/etc/init.d/gammu-smsd) to user who is already located in your system and has rights for executing the script. Or change script permissions by following: chmod 755 script.sh. It means you give execute rights to other users too.
In fact there is additional option. Run gammu deamon with parameter -U username. Unfortunatelly it did not work for me when I used root user.
PS: I would recommend to not to place the script inside /etc directory. Use /home directory instead.
turn on debuging in /etc/gammu-smsdrc. Use parameters: logformat and debuglevel in section smsd. Default log is located in /var/log/syslog. May be it helps you deeply localize the problem.
And the best at the end... I found that gammu returns the error even if it runs the script well! You have to write exit code inside you bash script. If you do not specify an exit code, gammu represents it as error 1. Add exit 0 in case of success in the end of the script and error message disappears.
with an unprivileged user account, using bash, I could do:
sudo /bin/sleep 6000
and kill it with Ctrl-c. However, sending SIGINT or SIGKILL from another terminal won't work for that purpose.
Anyone knows why is that? I'd like to be able to kill the process sending a signal, for using in a script, for example.
Regards.
You're only allowed to send signals to a process running with the same UID (unless the sending process is running as root). When you use sudo, the new process is running as root, but if you try to kill it you're running as your normal userid. You would have to use sudo kill PID to kill it.
Signals sent from terminal control characters are treated specially: they can be sent to any process running in the same login session as the terminal.
I'm writing a script to start Jboss, load an application, send requests to the application, shutdown jboss and repeat. However I dont know how to shut Jboss down from the script. At the moment I'm using
pkill -9 java
But I dont think this is right, because it kills the process, not shut it down. Is there a way to shut it down similar to pressing CTRL-C?
You want a simple
pkill java
From the man page:
pkill will send the specified signal (by default SIGTERM) to each
process
SIGTERM will send a termination signal to the process. If the process is well-written, it will catch this signal and perform an orderly shutdown. If that fails, that's when you can use SIGKILL (-9) which is a forceable termination with no chance for the process to catch and perform cleanup.
Never use kill -9 <PID> by default. It breaks things up, like file descriptors and such.
Start to run kill <PID> alone, default is -15 signal.
See
man 7 signal
And In what order should I send signals to gracefully shutdown processes?
NOTE
kill or pkill doesn't change things so much, same signals are trigered
What you actually want is:
pkill -f jboss
using pkill java could kill any other processes using java on the box.
If I am working on a remote server (ssh) and I fork a process using bash & operator, will that process be killed if I am booted off the server due to server time-out? I'm pretty sure the answer is yes, but would love to know if there are any juicy details.
It might depend, but generally when you log out with your "connection program" (e.g. ssh in your case although it could have been rlogin or telnet as well), the shell and children (I think?) will receive a SIGHUP signal (hangup) which will make them terminate when you log out. There are two common ways to avoid this, running the program you want to keep running through nohup or screen. If the server have some other time limitation on running processes you will have to look into that.
bash will send a HUP signal to all background jobs. You can stop this from happening by starting the job with nohup (which should have a man page). If it's too late for nohup, you can use disown to stop the shell from sending a HUP to a job. disown is a builtin, so help disown will tell you everything you need to know.