Hot answers tagged daemon
Yes, SELinux is likely the cause. The .ssh dir is probably mislabeled. Look at /var/log/audit/audit.log. It should be labeled ssh_home_t. Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.
Add the --make-pidfile option to your call of start-stop-daemon. --pidfile only tells start-stop-daemon where to look for the pidfile, without --make-pidfile it is assume that this pidfile is created by the program to be launched, and not by start-stop-daemon. Be sure to read the manpage of start-stop-daemon(8) for more details.
ConsoleKit manages console logins in graphical mode (i.e. with gdm or equivalent); if your server doesn't have those, you don't need it, but then it won't be started anyway. Also, you may be interested in this question. But you don't really have 60 instances taking 20% of RAM each. The ConsoleKit daemon is multithreaded, and htop shows a separate line for ...
You only need to set the time zone once: tzselect or dpkg-reconfigure tzdata NTP does not handle time zones. All time data handled by NTP is in UTC; your local time zone setting determines the offset from there.
I created an upstart script for ubuntu 9.10 For example I installed supervisor into a virtual environment, then start and control supervisor from upstart. create a text file /etc/init/supervisord.conf the contents are: description "supervisord" start on runlevel  stop on runlevel [!345] expect fork respawn exec ...
# nginx -h ... -s signal : send signal to a master process: stop, quit, reopen, reload ...
This is what I use on RHEL 5.4 and CentOS 5.5 I'm not sure wether it's depending on some configuration settings in my supervisord.conf. But it seems to work OK. You need to run the following command after installing it chkconfig --add supervisord [/etc/rc.d/init.d/supervisord] #!/bin/sh # # /etc/rc.d/init.d/supervisord # # Supervisor is a client/server ...
apt-get install sysv-rc-conf As others have pointed out, here is also update-rc.d for the cmd line. Run update-rc.d apache2 disable to disable apache2 from all run levels.
The "stop" term does not prevent the daemon from starting but rather shuts it down while entering the specified runlevel. If you just want to remove a service/daemon from a single runlevel, update-rc.d as pointed out bei freiheit or simply remove the symlink from /etc/rcX.d/, where X is your runlevel. If you don't want the service to start automatically, ...
You can create your daemon manually following the /etc/init.d/skeleton file on Debian. You can use /usr/bin/service to launch $ sudo service yourdaemon start and sstop $ sudo service yourdaemon stop your daemon. As long as you do not link your script to any of the /etc/rc?.d directories, it won't get started on startup. On the other hand, you may want to ...
Seems like the wrong solution, somehow. If you're on Ubuntu, use Upstart. If you're on Centos/RHEL/Other, take a look at using start-stop-daemon and the LSB init standard to properly daemonize a process, and then that'll enable you to use chkconfig to start/stop it automatically.
daemons and services are one in the same. However, neither have to be bound to a port. HALd is a daemon, that monitors plugged in hardware and mounts it properly. crond is a daemon that keeps the trains on time.
nohup command &
In my opinion, I would go with cron. Largely, because it's far less complicated and easier to implement. The other option requires you putting effort into daemonizing the process, and creating a startup script for it. There's plenty that can go wrong there. And there's a solid chance that a bug or errant kill might cause the daemon to die. (are you ...
You can find that on GNU's Savannah. For example here's coreutils.
If your process is started via a script, you can place the call to ulimit in the script just prior to executing the daemon. If you wish to increase the ulimit for your user, or for all users, you can set limits that are applied via pam_limits on login. These are set in /etc/security/limits.conf. In your case, you could do something like: * ...
Several options here. Just skip to the last paragraph if you want one recommendation instead of reading about the others too! Just restarting on reboot is easy: add it to /etc/rc.local which Debian based distros (and many others) run after everything in the other startup scripts by default. If god doesn't drop into the background itself you might need to ...
There is also a "total max" of open files set in the kernel, you can check the current setting with: cat /proc/sys/fs/file-max And set a new value with: echo "104854" > /proc/sys/fs/file-max If you want to keep the config between reboots add sys.fs.file-max=104854 to /etc/sysctl.conf To check current max file usage: [root@srv-4 proc]# cat ...
monit is great in this case - it runs on localhost, so you don't need a network connection to restart your daemon (in case it fails, or daemon is responsible for networking). It also has small footprint on the system, and you can use it to monitor your other daemons/disk space/etc. as well. Create a start/stop script (similar to those in /etc/init.d/ and ...
you could start it in a screen
xbindkeys needs a running X server to work which isn't available at that stage of starting your system. You should add xbindkeys to your .xinitrc (see man page xinit(1)) or .Xsession (see man page Xsession(5)) instead.
You should be creating an init service. Ubuntu uses upstart. http://upstart.ubuntu.com/
Depending on exactly what you want to do, screen may work out for you. You can run the command with screen, screen command then detach that screen and terminate your ssh session. Whatever is running in that screen session will still run, and you can re-attach to that session later, from another terminal.
try: su myuser -s /bin/sh -c /home/myuser/script.sh
It's a kernel thread performing things that typically take a lot of time. For more information, see slow-work.txt.
In your script: nohup command > logfile.txt & echo $! > /var/run/command.pid
On Ubuntu 9.04/9.10: sudo service --status-all For everything that responds to 'status' you'll get a +/- flag, and ? if they don't. edit You can also install 'chkconfig' to see what is set to start in the various run levels.
There is a Debian/Ubuntu script in official Supervisor GitHub repo: https://github.com/Supervisor/initscripts/blob/master/debian-norrgard
It actually needs a running X to draw the widgets: unless the application has an option to be ran as a daemon or something, there's no straight way. But let's think: if we can redirect its display socket via SSH, maybe, we can accept all X requests and just do nothing? YES! Here's the receipt: First, you'll need to ssh -X user@server opera from a remote ...
Only top voted, non community-wiki answers of a minimum length are eligible