There's a note in the launchctl man pages stating that:
launchctl no longer has an interactive mode, nor does it accept
commands from stdin. The /etc/launchd.conf file is no longer consulted
for subcommands to run during early boot time; this functionality was
removed for security considerations.
Is there another way to persist launchctl limit configuration? E.g., launchctl limit maxproc 1024 and launchctl limit maxfiles 4096
Related
I want to use Homebrew's version of Apache on my Mac so I can start/stop it as I please, so I've been trying all afternoon to stop and unload several httpd processes that are run by user _www on macOS 10.13.3 High Sierra without any luck.
See the screenshot attached, there are 6 httpd processes run by _www and the single process run under root (Homebrew service)
I've tried
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
which gives me an error:
/System/Library/LaunchDaemons/org.apache.httpd.plist: Could not find specified service
I've also tried tracking the process starting them down, switching user to _www (a no no) so I can see where it's being started and so far I'm having no luck.
I want to kill them all, and have them stay dead as right now they're conflicting with the server I'm actually trying to run. Anyone cleverer than me out there that knows how to kill this literal http demon?
https://stackoverflow.com/a/20439859/996338
Try this:
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
This will stop a running instance of Apache, and record that it should not be restarted. It records your preference in /private/var/db/launchd.db/com.apple.launchd/overrides.plist.
For a single session (meaning, between reboots), you can use sudo apachectl stop.
I have configured system configurations to create process core dumps.
Below are my configurations.
/etc/sysctl.conf
kernel.core_uses_pid = 1
kernel.core_pattern = /var/core/core.%e.%p.%h.%t
fs.suid_dumpable = 2
/etc/security/limits.conf
* soft core unlimited
root soft core unlimited
Here are the steps which I am following to generate process coredumps.
1) I have restarted mysql service and executed command "kill -s SEGV <mysql_pid>" then I got the core dump file in /var/core location.
2) Then I have started my service mysql say "/etc/init.d/mysql start" or "service mysql start". Now if I give "kill -s SEGV <mysql_pid>" then core dump file is not getting created.
3) To get crash file again I have to restart the mysql service then only if I give "kill -s SEGV <mysql_pid>" i'm getting core dump file.
Can anyone please help me how to resolve this?
First of all, you can verify that core dumps are disabled for the MySQL process by running:
# cat /proc/`pidof -s mysqld`/limits|egrep '(Limit|core)'
Limit Soft Limit Hard Limit Units
Max core file size 0 unlimited bytes
The "soft" limit is the one to look for, zero in this case means core dumps are disabled.
Limits set in /etc/security/limits.conf by default only apply to programs started interactively. You may have to include 'ulimit -c unlimited' in the mysqld startup script to enable coredumps permanently.
If you're lucky, then you can enable coredumps for your current shell and restart the daemon using its init.d script:
# ulimit -c unlimited
# /etc/init.d/mysql restart
* Stopping MySQL database server mysqld [ OK ]
* Starting MySQL database server mysqld [ OK ]
* Checking for tables which need an upgrade, are corrupt
or were not closed cleanly.
# cat /proc/`pidof -s mysqld`/limits|egrep '(Limit|core)'
Limit Soft Limit Hard Limit Units
Max core file size unlimited unlimited bytes
As you can see, this works for MySQL on my system.
Please note that this won't work for applications like Apache, which call ulimit internally to disable core dumps, not for init.d script that use upstart.
I am running an Ubuntu 12.04-based box inside of Vagrant using VirtualBox. So far, everything is fine - except for one thing:
Let's assume that the VM is running. Then, the host goes to standby-mode. After waking it up again, the VM is still running, but its internal clock continues where it stopped when the host went down. So this basically means: Put the host to sleep for 15 minutes, wake it up again, then the VM's internal clock is 15 minutes late.
How can I fix this (setting the time manually is not an option for obvious reasons ;-))? Is there a way to run a script inside of a Vagrant VM whenever the host system changes its state?
I've read in the documentation that by default the VirtualBox Guest Additions sync the time with the host every 10 seconds. Apparently this is not happening, but I can not find any place where it is disabled. So any ideas?
PS: The Guest Additions are installed and match the version of VirtualBox being used.
The documentation lacks some details here.
What VirtualBox does every 10 seconds is just slight adjustement (something like 0.005 seconds). Only when the time difference reaches a threshold (20 minutes by default) a "real" resync is done.
You can reduce the thresold (i.e. to 10 seconds) with the following command:
VBoxManage guestproperty set <vm-name> "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold" 10000
Summarizing answers of #zilupe and #Slobodan Kovacevic, solution is to add following to Vagrantfile:
config.vm.provider 'virtualbox' do |vb|
vb.customize [ "guestproperty", "set", :id, "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold", 1000 ]
end
This will synchronize clocks each time when desync becomes > 1s (1000ms)
I give an other solution to sync time between guest & host without installing Virtualbox guest addition:
install ntp on your guest, and de-comment these lines in /etc/ntp.conf:
disable auth
broadcastclient
Then, restart ntp with service ntp restart
Active broadcast on your host:
For Linux users, edit your /etc/ntp.conf file and configure broadcast (you must adapt IP):
broadcast 192.168.123.255
For Windows users, activate the "Windows Time" service. You can then read this page to configure it to broadcast time
Then, restart time service on host.
For me to get timesync working I had to do this:
vboxmanage setextradata «machine-name» "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 0
It turns the timesync on. It was, for some reason, off.
I found a solution:
install ntpdate
add "s" permission for ntpdate, this allows non-root users to run ntpdate as root: sudo chmod u+s /usr/sbin/ntpdate
add one line in ~/.bashrc: ntpdate -u ntp.ubuntu.com
After that, each time you login to the linux system, the time will be sync once.
you can install the VirtualBox Guest Additions in the VM to sync the time automatically by VB.
I am using redis for session support in nodejs app. I have installed redis server and it works when I run redis-server, but when I close terminal redis stops and does not work. How do I keep redis server running after closing the terminal?
And, if you'd like a quick option, run: redis-server --daemonize yes.
The easiest way to launch Redis as a daemon is to edit the configuration file and change the following line:
# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes
Be sure to provide the configuration file on the redis-server command line when you launch it.
An example of configuration file is provided in the Redis distribution.
As mentioned by #DidierSpezia in his answer,
Set daemonize yes in Redis conf file.
Set daemonize yes in Redis conf file at /path/to/redis.conf Generally
it should be there at /etc/.
And :
Then trigger redis-server with the conf file as an argument:
./redis-server /etc/redis.conf
UPDATE
You may directly run the redis with demonize flag as well
redis-server --daemonize yes
The accepted answer is mostly outdated.
While the question is old, Google still ranks this highly, so allow me to correct this.
The OP did not provide any detail about his setup, but you can assume it is a linux, and he doesn't mention containers, so you can also assume he is running redis without them.
There is three detail that make the accepted answer a thing to forget
Most (popular) distros come with systemd by default
Most (popular) distros have redis in their official repos
that official redis package installs systemd service for redis
So
It will have supervised systemd in its default config
To start: the redis daemon with sudo systemctl start redis#instanceName where you substitue "instanceName". Also sudo systemctl enable redis#instanceName for auto-starting on boot. (BTW, forget about service start, and init scripts already! These are less portable nowdays than calling directly systemctl).
do NOT set to daemonize: yes, that will interfere with the systemd supervisioning redis!
Systemd will supervise, restart your redis, and you can set service depenedencies and service preconditions to/for it, even for a custom executable it is not that hard, search for systemd unit files (you'll need a ~10 lines config file). Chances are, you'd want it.
If the three detail (making systemd the correct answer) are not met/relevant, you are most likely running redis containerized. For docker/podman/etc., it is another question altogether... (no systemd in the inner linux, but you'd have to (or already do) supervise(d) the container-daemon itself)
Is there a way to run sshd such that it can (at least for a limited number of log-ins) successfully return a prompt (likely busybox) even while fork is unavailable (e.g. out of PIDs)?
It seems to me this should be possible by, for example, the sshd pre-forking and keeping a pool of gettys to use to service log in requests.
SSHD can be launched with the -D or -d option.
-D:
When this option is specified, sshd will not detach and does not become a daemon.
This allows easy monitoring of sshd.
-d:
Debug mode.
The server sends verbose debug output to standard error, and does not put itself in the background.
The server also will not fork and will only process one connection. This option is only intended for debugging for the server.Multiple -d options increase the debugging level. Maximum is 3.
I guess your best choice is to run a separate SSHD process, listening on another port, with the -d option.
So when the «normal» SSHD fails, you will still be able to switch to the other one, using the alternate port.