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.
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, ...
# nginx -h ... -s signal : send signal to a master process: stop, quit, reopen, reload ...
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.
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.
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 ...
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 ...
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 ...
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.
You can use env to modify the environment: start-stop-daemon --start --pidfile /var/run/wine-app.pid -m -c myuser -g mygroup -k 002 --exec /usr/bin/env VAR1="Value" /home/myuser/.wine/drive_c/Program\ Files/wine-app.exe
nohup command &
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: * ...
try: su myuser -s /bin/sh -c /home/myuser/script.sh
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 ...
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 ...
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.
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.
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.
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
There are two ways: The first is just to specify a numeric --retry value. Then it will use /signal/timeout/KILL/timeout schedule. I.e. send a terminating signal (specified with --signal option), then wait the specified number of seconds and then send a KILL signal that could not be ignored by a process and therefore it will be forced to exit. The command ...
Debian uses rsyslog and you can check it is running pretty much exactly like checking apache is running /etc/init.d/rsyslog status [ ok ] rsyslogd is running. Or you could use the service command (which does pretty much the same thing) service rsyslog status [ ok ] rsyslogd is running.
Did you make sure to source the /etc/init.d/functions library in your service's init.d script? You'd need this in your init.d script: # Source function library. . /etc/init.d/functions If this is already there, can you please post your daemon's start script?
Only top voted, non community-wiki answers of a minimum length are eligible