I have a UNIX daemon, which wait of SIGHUP for refresh a data. I try to send a signal from the Perl script (under Apache www-data:www-data on the same server) by Proc::Killall ("killall('HUP', 'mydaemon');"), but I have no properly permissions. suid bit doesn't work too. 'kill -n HUP ' from shell are working.
Does you have any idea to do this?
The usual work-around is to employ a »touch file« to indicate a reload, see Apache2::Reload for a real life example.
Listen to notifications set up with e.g. File::ChangeNotify or AnyEvent::Inotify::Simple, then do your reloading.
Related
I'm using VS Code to write and debug a C++ program binding to libfuse.
Unfortunately, if you kill a libfuse process with SIGKILL, you then have to use sudo umount -f <mountpoint> before you can start the program again. It's a minor nuisance if I have to do this every time I want to stop or restart debugging, especially as I shouldn't have to authenticate to do such a regular task (the sudo is somehow necessary despite the mount occurring as my user).
While I think this is mainly FUSE's fault (it should gracefully recover from a process being ungracefully killed and unmount automatically instead of leaving the directory saying Transport endpoint is not connected), I also think there should be a way to customise VS Code (or any IDE) to run some clean-up when you want to stop debugging.
I've found that entering -exec signal SIGTERM in the Debug Console will gracefully unmount the directory correctly, stop the process and tell VS Code it's no longer debugging (status bar changes back from orange to blue). But I can't seem to find a way to automate this. I've tried using a .gdbinit file, with some inspiration from this question:
handle SIGTERM nostop
# This doesn't work as hook-quit isn't run when quitting via MI mode, which VS Code uses...
define hook-quit
signal SIGTERM
end
But as noted in the linked question, GDB ignores quit hooks when in MI mode, and VS Code uses MI mode.
The ideal solution for me would be if I could put something in a .vscode configuration file telling it to send -exec signal SIGTERM when I click the stop or restart buttons (and then wait for whatever notification it's getting that debugging has stopped, before restarting if applicable) but I imagine there probably isn't an option for that.
Even if the buttons can't be customised, I'd be happy with the ability to have a keybinding that would just send -exec signal SIGTERM to the Debug Console without me having to open said console and enter the command, though the Command Palette doesn't show anything useful here (nothing that looks like it will send a specified Debug Console command), so I don't expect there's a bindable command for that either.
Does anyone have any suggestions? Or would these belong as feature requests over on the VS Code github? Any way to get GDB to respect its quit hook in MI mode, or to get FUSE to gracefully handle its process being killed would be appreciated too.
I am trying to build a perl based server that will accept incoming requests and, based on that request, read/write data to server's STDIN/OUT. So I need to accept data from the client STDIN, write it to the server's STDIN (where it is handled by another process), capture the results of that request from the server's STDOUT and then ship it to the client.
I was hoping to build this off of Net::Server but I cannot, for the life of me, figure out how to direct data specifically to the server's STDIN. In my ideal world I'd have a set of file handles like CLISTDIN, CLISTDOUT, SRVSTDIN, and SRVSTDOUT that I could discretely address and manage. I'm just at a loss of how to go about it in Net::Server.
I don't have to use Net::Server so other suggestions are welcome. Net::Server just has a number of other features I would like to use.
Thanks for any insight.
Have you thought about just using ssh? With ssh your can run commands on a remote computer (server) which redirects your stdin to that command, and the stdout from that command to yours. Simple demo:
$ echo "hello, world" | md5sum
22c3683b094136c3398391ae71b20f04 -
$ echo "hello, world" | ssh myserver.com md5sum
22c3683b094136c3398391ae71b20f04 -
Or
$ echo "hello, world" | ssh user#myserver.com "/path/any/command --with --args x y z"
(You can set up ssh for automatic login with ip check by ssh-keygen and ~/.ssh/authorized_keys wont say more about that here)
Turns out I could do this by overloading post_accept to change how STDIN/STDOUT were being used. I was able to create two distinct filehandles so I could refer to the client IN/OUT without breaking the servers IO. That said, Net::Server kept getting in the way of what IO wanted to do so I abandoned it and just rolled my own forking server. Ended up being easier overall.
I'm using RawCap to capture packets sent from my dev machine (one app) to itself (another app). I can get it to write the captures to a file like so:
RawCap.exe 192.168.125.50 piratedPackets.pcap
...and then open the *.pcap file in Wireshark to examine the details. This worked when I called my REST method from Postman, but when using Fiddler's Composer tab to attempt the same, the *.pcap file ends up being empty. I think this may be because my way of shutting down RawCap was rather raw itself - I simply closed the command prompt. Typing "exit" does nothing while it's busy capturing.
How can I make like a modern-day Mansel Alcantra if I the captured packets sink to the bottom of the ocean before I can plunder the booty? How can I gracefully shut RawCap down so that it (hopefully) saves its contents to the log (*.pcap) file?
RawCap is gracefully closed by hitting Ctrl + C. Doing so will flush all packets from memory to disk.
You can also tell RawCap to only capture a certain number if packets (using -c argument) or end sniffing after a certain number of seconds (using -s argument).
Here's one example using -s to sniff for 60 seconds:
RawCap.exe -s 60 192.168.125.50 piratedPackets.pcap
Finally, if none of the above methods is available for you, then you might wanna use the -f switch. By using -f all captured packets will be flushed to disk immediately. However, this has a performance impact, so you run a greater risk of missing/dropping packets when sniffing with the -f switch.
You can run RawCap.exe --help to show the available command line arguments. They are also documented here:
http://www.netresec.com/?page=RawCap
I am on an embedded platform (mipsel architecture, Linux 2.6 kernel) where I need to monitor IPC between two closed-source processes (router firmware) in order to react to a certain event (dynamic IP change because of DSL reconnect). What I found out so far via strace is that whenever the IP changes, the DSL daemon writes a special message into a UNIX domain socket bound to a specific file name. The message is consumed by another daemon.
Now here is my requirement: I want to monitor the data flow through that specific UNIX domain socket and trigger an event (call a shell script) if a certain message is detected. I tried to monitor the file name with inotify, but it does not work on socket files. I know I could run strace all the time, filtering its output and react to changes in the filtered log file, but that would be too heavy a solution because strace really slows down the system. I also know I could just poll for the IP address change via cron, but I want a watchdog, not a polling solution. And I am interested in finding out whether there is a tool which can specifically monitor UNIX domain sockets and react to specific messages flowing through in a predefined direction. I imagine something similar to inotifywait, i.e. the tool should wait for a certain event, then exit, so I can react to the event and loop back into starting the tool again, waiting for the next event of the same type.
Is there any existing Linux tool capable of doing that? Or is there some simple C code for a stand-alone binary which I could compile on my platform (uClibc, not glibc)? I am not a C expert, but capable of running a makefile. Using a binary from the shell is no problem, I know enough about shell programming.
It has been a while since I was dealing with this topic and did not actually get around to testing what an acquaintance of mine, Denys Vlasenko, maintainer of Busybox, proposed as a solution to me several months ago. Because I just checked my account here on StackOverflow and saw the question again, let me share his insights with you. Maybe it is helpful for somebody:
One relatively easy hack I can propose is to do the following:
I assume that you have a running server app which opened a Unix domain listening socket (say, /tmp/some.socket), and client programs connect to it and talk to the server.
rename /tmp/some.socket -> /tmp/some.socket1
create a new socket /tmp/some.socket
listen on it for new client connections
for every such connection, open another connection to /tmp/some.socket1 to original server process
pump data (client<->server) over resulting pairs of sockets (code to do so is very similar to what telnetd server does) until EOF from either side.
While you are pumping data, it's easy to look at it, to save it, and even to modify it if you need to.
The downside is that this sniffer program needs to be restarted every time the original server program is restarted.
This is similar to what Celada also answered. Thanks to him as well! Denys's answer was a bit more concrete, though.
I asked back:
This sounds hacky, yes, because of the restart necessity, but feasible.
Me not being a C programmer, I keep wondering though if you know a
command line tool which could do the pass-through and protocolling or
event-based triggering work for me. I have one guy from our project in
mind who could hack a little C binary for that, but I am unsure if he
likes to do it. If there is something pre-fab, I would prefer it. Can it
even be done with a (combination of) BusyBox applet(s), maybe?
Denys answered again:
You need to build busybox with CONFIG_FEATURE_UNIX_LOCAL=y.
Run the following as intercepting server:
busybox tcpsvd -vvvE local:/tmp/socket 0 ./script.sh
Where script.sh is a simple passthrough connection
to the "original server":
#!/bin/sh
busybox nc -o /tmp/hexdump.$$ local:/tmp/socket1 0
As an example, I added hex logging to file (-o FILE option).
Test it by running an emulated "original server":
busybox tcpsvd -vvvE local:/tmp/socket1 0 sh -c 'echo PID:$$'
and by connecting to "intercepting server":
echo Hello world | busybox nc local:/tmp/socket 0
You should see "PID:19094" message and have a new /tmp/hexdump.19093 file
with the dumped data. Both tcpsvd processes should print some log too
(they are run with -vvv verbosity).
If you need more complex processing, replace nc invocation in script.sh
with a custom program.
I don't think there is anything that will let you cleanly sniff UNIX socket traffic. Here are some options:
Arrange for the sender process to connect to a different socket where you are listening. Also connect to the original socket as a client. On receipt of data, notice the data you want to notice and also pass everything along to the original socket.
Monitor the system for IP address changes yourself using a netlink socket (RTM_NEWADDR, RTM_NEWLINK, etc...).
Run ip monitor as an external process and take action when it writes messages about added & removed IP addresses on its standard output.
I'm working with an embedded computer that has a Debian on it. I already manage to run a command just before it has booted and play the "bell" to tell that is ready to work, and for example try to connect to a service.
The problem is that I need to play the bell (or run any command/program) when the system is halted so is safe to un-plug the power. Is there any runscript that run just after halt?
If you have a look in /etc/init.d, you'll see a script called halt. I'm pretty certain that when /sbin/halt is called in a runlevel other than 0 or 6, it calls /sbin/shutdown, which runs this script (unless called with an -n flag). So maybe you could add your own hook into that script? Obviously, it would be before the final halt was called, but nothing runs after that, so maybe that's ok.
Another option would be to use the fact that all running processes get sent a SIGTERM followed (a second or so later) by a SIGKILL. So you could write a simple daemon that just sat there until given a SIGTERM, at which point it went "ping" and died.