First of all this is not a duplicate. Overall my question is:
I have another application currently running on macOS and I want to cut (sever or close or stop) it tcp connection from terminal. The problem is I don't want to kill process 'cause this is a solution what I found in another answers. + I have an access to sudo and I know the PID.
What I did and it doesn't work:
lsof -i TCP:X | awk '/LISTEN/ {print $2}' | xargs kill -9
I tried to change X to particular value which I got from this command
sudo lsof -i -n -P | grep TCP
The second thing placed here https://www.scm.keele.ac.uk/staff/stan/2016/05/16/closing-sockets-without-killing-processes/
But from that line lldb -p $PID I got an error like this:
error: attach failed: attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries when the attached failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)
Maybe I missed something or maybe I should find a special program for my purpose? The Windows I see have one -> https://www.nirsoft.net/utils/cports.html
I'm really curious about it 'cause all answers which I found suggests users to kill all process. But I don't want it.
Ok.. just try to learn code from here -> https://github.com/doug-leith/appFirewall
Thanks dude for providing minus feedback for me. But my answer is the only one on internet which lead to working firewall!
I have an embedded device which manages its various services using systemd. Our status reporting application is one of these services. It is always on and it automatically restarts on failure (crashes, exceptions, OOM conditions, whatever).
We report an event to our cloud services on device restart (technically application restart) but I'd like to distinguish first start (after reboot) from restart. Is there a mechanism built into systemd which can provide the service restart count, or do I need to roll my own method?
Do you have the journal ? If you do, then you can get the count like this:
journalctl -b -u myservicename.service |grep -c Started
The -b option limits logs to the current boot; -u limits to the service in argument.
Then you grep for the "Started" line, and tell grep to only give you the number of matches.
you can use following command:
systemctl show foo.service -p NRestarts
It will return a value if the service is in a restart loop, otherwise, will return nothing.
I'm trying to get LLDB (running in Xcode 4.3.2 with an OS X application) to not stop on certain signals. If I enter
process handle SIGUSR2 -n true -p true -s false
on the debugging console it works fine and LLDB no longer stops on SIGUSR2.
However, if I put
command process handle SIGUSR2 -n true -p true -s false
into ~/.lldbinit it seems to be ignored. Other commands in this file (e.g. alias) work fine.
How can I make LLDB never stop on certain signals?
In case anyone else ever has this question, I finally solved it by adding a breakpoint in NSApplicationMain() (for plain C programs, main() would of course work as well).
I set the breakpoint action to process handle SIGUSR2 -n true -p true -s false, and enabled the "Automatically continue after evaluating" option.
If anyone has a more elegant solution, I'd be happy to hear.
I have a LaunchDaemon. When it runs, it checks if SIMBL is installed. If SIMBL is not installed, it uses NSTask to run /usr/sbin/installer on the SIMBL.pkg.
SIMBL's postflight script then tries to run a launchctl load command to start SIMBL's LaunchAgent immediately:
sudo -u "$USER" -- /bin/launchctl load -F -S Aqua -D user "${LAUNCHD_PLIST}"
This fails, because my LaunchDaemon's NSTask environment doesn't have $USER set.
If I have my daemon detect the current user with the System Configuration framework and pass it to NSTask with setEnvironment, launchctl bugs out on me:
Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1
I realize a daemon, by definition, should not operate in a user session. By the same token, Apple seems to recommend LaunchAgents as helper objects for LaunchDaemons, to do that user session work. Is there any way to get such an agent up and running immediately?
I have all the .plists in the right places (they start running after a reboot, the next time launchctl does its regular loading) so my first thought was to just tell launchctl to reload. But all the code to do that is commented out in launchctl.c:
// { "reload", reload_cmd, "Reload configuration files and/or directories" },
...
* In later versions of launchd, I hope to load everything in the first pass,
* then do the Bonjour magic on the jobs that need it, and reload them, but for now,
* I haven't thought through the various complexities of reloading jobs, and therefore
* launchd doesn't have reload support right now.
Oh how launchd drives me crazy....
To cut to the chase, after much study and experimentation, this is how I do it on 10.5+:
# If possible, tell launchd to start the LaunchAgent. This will fail on 10.4.
# $F[0] is the pid
# $F[1] is the username
# $F[2] is the first word of the command
ps -ww -A -opid,user,command | \
perl -nae 'if($F[2] =~ /\bloginwindow\b/) { system(
qq(launchctl bsexec $F[0] su $F[1] -c "launchctl load -w <your_plist>"))
}'
I have found no way to achieve this directly on 10.4. I cheat on 10.4 and just run the thing the LaunchAgent would have run, even though it has a GUI and you're not supposed to be able to do that (you can anyway in 10.4-10.6; you can't in 10.7). On 10.4, the LaunchAgent works correct after the next reboot.
The above code looks for loginwindow processes and uses bsexec to run commands in those contexts. Keep in mind that with Fast User Switching, there can be multiple contexts.
Some useful links:
Daemons and Services Programming Guide. You have to read it, but it won't actually answer any of the hard questions. But it will at least give you hints at where everything is located.
TN2083. This is a maddening document that raises as many questions as it answers, but is gospel and mandatory reading for anyone entering the abyss of launchd.
Starting/stopping a launchd agent for all users with GUI sessions. This has several other useful links and explanation.
IMO, launchd is one of the worst "great ideas" Apple has ever deployed. The idea is very useful, but the API is horrible.
I'm looking for a decent, non-lame way to inhibit xscreensaver, kscreensaver, or gnome-screensaver, whichever might be running, preferably in a screensaver-agnostic manner, and it absolutely positively must execute fast.
I've read the xscreensaver FAQ.
I have a gtk based game program that's cranking out 30 frames/second while mixing several channels of audio, and since it's controlled by a joystick, sometimes "the" screensaver will kick in. I put "the" in quotes, because there are at least three different popular screensavers, xscreensaver, gnome-screensaver, and kscreensaver, each with their own unique and clunky methods by which an application might inhibit them.
Has anybody encapsulated the code to inhibit all of these into a fast chunk of code? Oh, and it has to be GPL compatible.
Currently my code simply whines piteously about the uncooperative screensaver developers if any screensaver is detected and the joystick is in use, and doesn't actually try to do anything other than advise the user to manually disable the screensaver, as the only other thing I can think to do is so incredibly ugly that I simply refuse to do it.
Just wondering if anybody else has run into this, and what they've done, and if they did anything, if it was as ugly as it seems to me it would have to be, or if there's some elegant solution out there... Seems like maybe synthesizing X events somehow to fool the screensaver into thinking there's some activity might do the trick in a universal way, but I'm really not sure how to do that (and hoping you wouldn't need to be root to do it.)
Any ideas?
Hmm, unfortunately, at least on Fedora core 8, this does not appear to work.
The xdg-screensaver script is there, and seems to be intended to work, it just doesn't actually work.
Once you do "xdg-screensaver suspend window-id", where window id is gotten from within the program via
xwindow_id = GDK_WINDOW_XWINDOW (GTK_WIDGET (widget)->window);
Or whether the window id is gotten via xprop, and xdg-screensaver run manually, two processes are created:
[scameron#zuul wordwarvi]$ ps -efa | grep xdg
scameron 4218 1 0 20:12 pts/2 00:00:00 /bin/sh /usr/bin/xdg-screensaver suspend 0x3a00004
scameron 4223 1 0 20:12 pts/2 00:00:00 /bin/sh /usr/bin/xdg-screensaver suspend 0x3a00004
scameron 4313 3151 0 20:15 pts/1 00:00:00 grep xdg
[scameron#zuul wordwarvi]$
And they never die, even after the program they are supposedly waiting for dies, and the screensaver is never re-enabled.
[scameron#zuul wordwarvi]$ xdg-screensaver status
disabled
[scameron#zuul wordwarvi]$ ls -ltr /tmp | grep xdg
-rw------- 1 scameron scameron 15 2009-01-20 20:12 xdg-screensaver-scameron--0.0
[scameron#zuul wordwarvi]$
Running xdg-screensaver resume window-id does not resume the screensaver.
To re-enable the screensaver, I have to manually kill them, and manually remove the files it leaves around in /tmp:
[scameron#zuul wordwarvi]$ kill 4218 4223
[scameron#zuul wordwarvi]$ rm /tmp/xdg-screensaver-scameron--0.0
[scameron#zuul wordwarvi]$ xdg-screensaver status
enabled
[scameron#zuul wordwarvi]$
So, good intentions, but doesn't seem to actually work.
No, of course not expecting to run it every frame, but don't want it causing hiccups when it does run, is all. With my thought of synthesizing X events, I was imagining it would be just often enough to make the screen saver think there was activity.
Looking at xdg-screensaver (which seems to be a shell script that ultimately just does a "wait" for my process -- cool) it seems to be made to do just what I want. I knew I couldn't be the only or first one to face this problem.
No, but yes...
There's no nice clean way to do this. In my opinion there should be a mechanism administrated by the X server, which both screensavers and interested applications can voluntarily use to negotiate suppression of any screensaver during the runtime of one or more programs. But no such mechanism yet exists to my knowledge. GNOME and KDE look to be implementing a DBUS approach to this problem, but in my opinion even if it becomes widespread (it isn't yet widespread enough to rely on it in 3rd party code) it's not the right approach.
However, xdg-screensaver is a FreeDesktop standardised shell script which you can run as a sub-process to control the screensaver. It controls most popular screensavers, and the OS vendor would be responsible for updating it/ maintaining it to work with newer screensavers or better ways of doing this in the future. Unlike many other kludges it will automatically re-enable the screensaver if your application crashes or exits via some route that forgets to call the re-enable code. See the manual page for details in how to use it.
As a GTK+ user probably the trickiest aspects of this for you would be creating the sub-process to run the shell script (if you haven't done this before you will want to find a tutorial about using fork + exec) and getting the XWindow ID of your application's main window to give to xdg-screensaver.
You ask that the code should be "fast". This makes me wonder if you're expecting to run it every frame - don't. The xdg-screensaver solution allows you to disable or renable the screensaver explicitly, rather than trying to suppress it once per frame or anything like that.
Try this: xdg-screensaver suspend [window id]
(see: http://portland.freedesktop.org/xdg-utils-1.0/xdg-screensaver.html)
a Bash script solution:
activ_win_id=`DISPLAY=:0.${display} xprop -root _NET_ACTIVE_WINDOW`
activ_win_id=${activ_win_id:40:9}
xdg-screensaver suspend $activ_win_id
It works for gnome-screensaver.
And there's the more complicated DBus "inhibit" method: https://people.gnome.org/~mccann/gnome-screensaver/docs/gnome-screensaver.html#gs-method-Inhibit
dbus-send --session \
--dest=org.gnome.ScreenSaver \
--type=method_call \
--print-reply \
--reply-timeout=20000 \
/org/gnome/ScreenSaver \
org.gnome.ScreenSaver.Inhibit \
[application name e.g. ""] \
[reason e.g."playing a game"] \
[non-zero-random-integer e.g. 123]
Edit 2019/12/04:
I went back to this and found out that dbus-send doesn't work properly now. The Inhibit method is released as soon as the D-Bus connection is released (which happens when dbus-send exits).
A good method (working with Gnome 3.34) is the following python script:
#!/usr/bin/python
# coding=utf-8
# Usage: gnome-inhibit <command-line>
# Example: gnome-inhibit mpv video.mp4
import subprocess
import dbus
import sys
import os
bus = dbus.SessionBus()
proxy = bus.get_object('org.freedesktop.ScreenSaver','/org/freedesktop/ScreenSaver')
iface = dbus.Interface(proxy, 'org.freedesktop.ScreenSaver')
cookie = iface.Inhibit(sys.argv[1], "gnome-inhibit")
print("Inhibiting screensaver (pid: %d)" % os.getpid())
print("Executing: %s" % subprocess.list2cmdline(sys.argv[1:]))
subprocess.check_call(sys.argv[1:])
Old answer that doesn't work anymore:
The current way (under Gnome 3.22 and possibly others such as KDE) seems to be this, which returns an uninhibition cookie as an uint32 :
dbus-send --session \
--dest=org.freedesktop.ScreenSaver \
--type=method_call \
--print-reply \
--reply-timeout=20000 \
/org/freedesktop/ScreenSaver \
org.freedesktop.ScreenSaver.Inhibit \
string:program string:reason
Then, to disable the inhibition :
dbus-send --session \
--dest=org.freedesktop.ScreenSaver \
--type=method_call \
--print-reply \
--reply-timeout=20000 \
/org/freedesktop/ScreenSaver \
org.freedesktop.ScreenSaver.UnInhibit \
uint32:<inhibit-cookie>
Here is a small script that disables the screensaver for a given program, then later restores it on exit.
(D-Feet has been especially helpful for introspecting the ever-changing D-Bus method names)
Movie-players typically disable screensavers. You could poke around the mplayer-code to see how they do it.
For regular X, they use XScreenSaverSuspend where supported.
It is not an entirely desktop-agnostic solution, but if core Gnome libraries are installed (many GTK-based apps require them) it could work on other desktop environments too:
Disable screensaver:
gsettings set org.gnome.desktop.screensaver idle-activation-enabled false
(Re)enable screensaver:
gsettings set org.gnome.desktop.screensaver idle-activation-enabled true
This 'dirty solution' works for me on Debian 10 + LXDE:
[ "$(cat ~/.xsessionrc | grep 'xset -dpms')" ] || echo 'xset -dpms' >> ~/.xsessionrc # disables DPMS (Energy Star) features
sed -i '/^timeout:/c timeout:\t3:00:00' ~/.xscreensaver # 3 hours should be enough to see a film without interruptions
# DOESN'T WORK: xset s off # turns the screen saver functions off
Install caffine-ng. Tray app. Totally customizable activate and ignore lists. Audio detection. Screensaver / Locker never goes off again when you don't want it to. EASY.