I want to stop wpa_supplicant on ubuntu 14.04.
I did follow but the wpa_supplicant restarted by someone.
$ ps aux | grep wpa
root 4947 0.0 0.0 30628 4968 ? Ss 09:41 0:00 /sbin/wpa_supplicant -B -P /run/sendsigs.omit.d/wpasupplicant.pid -u -s -O /var/run/wpa_supplicant
$ sudo kill 4947
$ ps aux | grep wpa
root 5458 0.0 0.0 30628 4996 ? Ss 09:55 0:00 /sbin/wpa_supplicant -B -P /run/sendsigs.omit.d/wpasupplicant.pid -u -s -O /var/run/wpa_supplicant
I want to know who restart the supplicant and stop wpa_supplicant abidingly. Because I am trying to test another version wpa_supplicant.
On Ubuntu 20.04
systemctl stop wpa_supplicant
systemctl disable wpa_supplicant
The second command will stop it from automatically starting.
The brute-force way is to break wpa_supplicant by renaming it. Whatever tries to start it won't find it anymore.
$ which wpa_supplicant
/sbin/wpa_supplicant
$ sudo mv /sbin/wpa_supplicant /sbin/wpa_supplicant_org
$ sudo killall wpa_supplicant
And I got a result I wanted that the wpa_supplicant cannot restart anymore.
This method has some caveats:
An update might fix the package again.
You can't manually start wpa_supplicant when you use this method.
sudo pkill wpa_supplicant
usually does the trick for me. Are you looking for something else?
wpa_supplicant provides the WPA security. Any network manager (e.g. Network Manager,netctl etc) that deals with wifi network would use wpa_supplicant. So whenever the network manager starts it would start wpa supplicant.
If you want to permanently disable it (because may be you dont use wifi or secure wifi) then you can mask it.
sudo systemctl mask wpa_supplicant.service
then stop it:
sudo systemctl stop wpa_supplicant.service
NOTE:Masking basically creates a symlink to /dev/null, so even if some service tries to start it it won't start. This would disable it until you manually unmask it again.
sudo systemctl unmask wpa_supplicant.service
In my case, I had a service that was launching it.
I did a grep inside systemd config directory
cd /etc/systemd/system
grep -ri wpa
That showed me the name of the service that is starting this.
Used the following command to stop it
sudo systemctl stop <service-name>
If you would like to permanently disable it, remove the "WantedBy" line in the service file.
The clean way to shut down wpa_supplicant is
wpa_cli terminate
Sometimes you need to specify the interface as in
wpa_cli terminate -i wlan0
Related
I have simple batch script in linux debian - Debian GNU/Linux 6.0 - that stop process then deletes log files and start the process again :
#!/bin/bash
killall -KILL rsyslogd
sleep 5s
rm /var/log/syslog
rm /var/log/messages
rm /var/log/kern.log
sleep 3s
rsyslogd
exit
The process name is rsyslogd. I have to close it before deleting the log files, for linux to empty the space from disk.
I see that killall -KILL closes the process by its name, but what is the opposite - the run command?
Calling it by its name without any command seems to not work. I will be glad for any tips, thank you.
Debian uses systemd to manage processes. You should, therefore, use the systemd's commands to stop and start rsyslogd.
systemctl stop rsyslog
and
systemctl start rsyslog
If you are using really old versions of Debian (so old that you should upgrade), it may be possible that sys V is still used. In that case, there is a file under /etc/init.d which is called rc.rsyslog or something comparable (use ls /etc/init.d to find the exact name). In that case, it would be
sudo /etc/init.d/rc.rsyslog stop
and
sudo /etc/init.d/rc.rsyslog start
Or it may be, that your systemd-package may be broken. In that case, the package can be re-installed:
apt-get --reinstall install systemd
To start rsyslogd:
systemctl start rsyslog
To stop it:
systemctl stop rsyslog
If you want to do both, use
systemctl restart rsyslog
When running autossh without the "-f" option, everything works fine.
Adding the "-f" option indeed sends autossh to the background, but after the ssh tunneling established correctly the autossh itself exit, leaving the ssh connection without monitor.
Here is the command I'm running: autossh -f -M 20000 -N -L 0.0.0.0:5601:10.10.0.8:5601 10.10.0.8
Anyone knows what can cause this problem? alternatively - anyone knows how can I debug autossh when using the "-f"? (is there any log file produce when using AUTOSSH_DEBUG=1)?
(I'm running on Ubuntu 14.04)
Thanks,
Shay
Seeing as no one has a better suggestion... Try running autossh under a watchdog like daemontools. With this method autossh runs as a foreground child of a supervise daemon (so, no -f switch). You can start and stop it with the svc command, and you can log all of its output with multilog.
This method has proven sufficiently reliable for me, on a fleet of production boxes.
On macOS I had a problem where autossh -M 0 -R 1234:localhost:22 worked but adding -f to make autossh run in background would log the following and autossh would die instantly:
2018/04/10 12:00:06 autossh[67839]: ssh exited with status 0; autossh exiting
Adding -N ("Do not execute a remote command.") fixed the issue:
autossh -f -M 0 -N -R 1234:localhost:22
Seeing you already had -N in the command this is probably unrelated but possibly helpful to others.
I am doing a project read GPS values output from a GPS dongle and need to
programmatically start the gpsd daemon.
i.e. I need to automate the following command;
sudo gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock
I was able to read the coordinates through the code after manually starting the daemon as above. But don't know how to start the daemon through he code.
Since gpsd is a daemon, you can just set the daemon up to be run automatically at startup. How to do this depends on which startup system you have. For example, if you have systemd, you have to write a gpsd.service file, something like this
[Unit]
Description=GPSd daemon service file
[Service]
Type=forking
User=root
Group=dialout
TimeoutStartSec=0
ExecStart=/usr/local/sbin/gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock
[Install]
# Grouping mechanism that let systemd start groups of processes up at the same time
WantedBy=multi-user.target
then install it in /lib/systemd/system and finally using the following commands
$ sudo systemctl enable gpsd
$ sudo systemctl start gpsd
the start command is just to run gpsd as systemd daemon without rebooting your system.
for debian its just
dpkg-reconfigure gps
I would like to run node with a low privileges user, is it possible? I need to use the framework Express.js
Yes. There are many solutions available to do this, depending on your exact needs.
If you want to run node on port 80, you can use nginx (doesn't work with WebSockets yet) or haproxy. But perhaps the quickest and dirtiest is to use iptables to redirect port 80 to the port of your choice:
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8003
sudo iptables -t nat -L
When you’re happy, then save the config and make sure iptables comes on at boot
sudo service iptables save
sudo chkconfig iptables on
To automatically start your nodejs service as non-root, and restart it if it fails, you can utilize upstart with a script like this:
#!upstart
description "nodeapp"
author "you"
start on started mountall
stop on shutdown
# Automatically Respawn:
respawn
respawn limit 99 5
script
export HOME="/home/user/"
exec sudo -u user /usr/local/bin/node /home/user/app.js 2>&1 >> /home/user/app.log
end script
If you're on an Amazon EC2 installation, or you get an error that says sudo: sorry, you must have a tty to run sudo, then you can replace your exec command with this:
#!upstart
description "nodeapp"
author "you"
start on started mountall
stop on shutdown
# Automatically Respawn:
respawn
respawn limit 99 5
script
export HOME="/home/user/"
#amazon EC2 doesn’t allow sudo from script! so use su --session-command
exec su --session-command="/usr/local/bin/node /home/user/app.js 2>&1 >> /home/user/app.log" user &
end script
And, you didn't ask this question, but to keep it running forever, check out monit! Here is a useful guide to setting up node.js with upstart and monit.
At my company, some commands are allowed to run with sudo, such as tcpdump. Others not.
I expect run tcpdump for a while, and then stop it.
When I run tcpdump, and I could abort that with Ctrl+C
I wrote a shell script like this -
#!/bin/sh
sudo tcpdump -ieth1 -w ~/dump.bin
sleep 5
kill -2 $!
it doesn't really work. The process of tcpdump is run as root, and current user is a normal account.
My question is: is there any way to do the equivalent of ctrl c in bash script?.
EDIT:
ps:As my company's security policy, I cannot run kill as root.
Try the -Z option to tcpdump. It instructs tcpdump to drop root privileges and run as the user specified in the argument.
sudo tcpdump -Z $USER -ieth1 -w ~/dump.bin
Now try killing that process.
Simply run kill through sudo as well:
sudo kill -2 $!
This way the kill process will have the privilege to send signals to a process that runs as root.
For programs that don't have special switches like -Z and in case you can alter sudoers file, this is a solution:
sudo myprogram &
sleep 5
sudo pkill myprogram
All I have to do is to allow to run pkill myprogram passwordless by using visudo and adding this line:
myuser ALL=(ALL) NOPASSWD:/bin/pkill myprogram
This is less dangerous that lo let sudo kill any program.
The timeout command also terminates a program after so long. sudo timeout 5 tcpdump -ieth1 -w ~/dump.bin should accomplish the same thing as the script.
sudo tcpdump -Z root -w ~/dump.bin -n -i eth0 -G 300 -W 1
G - Timeout Seconds (After timeout period the comman gets killed automatically)
Z - drop root and runs as user privilege
W - Number files to be saved (as a splitted file)
sudo tcpdump -ieth1 -w ~/dump.bin
will block your script, you need to put it into the background:
sudo tcpdump -ieth1 -w ~/dump.bin &
.
This and the answer from Blagovest should do it.