'locate' command not working [SOLVED] - Arch Linux

[oio11]

'locate' command not working [SOLVED] / Newbie Corner / Arch Linux ...

.. updating .. the database. "updatedb" as root ..

Forum Rules There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !

http://bbs.archlinux.org/viewtopic.php?id=80365

Comments

[oio11]

No such file or directory error when trying to execute startup script in Debian
..
sudo chmod 755 /etc/init.d/testsam
sudo update-rc.d testsam defaults

sudo /etc/init.d/testsam start ..

.. /etc/init.d/testsam: No such file or directory ..

You probably have a carriage return (^M) at the end of your #! line. The format of the #! line is very strict, and carriage return is not allowed there, unless your interpreter is actually called /bin/bash^M There will never be carriage returns in a file created with a proper unix editor, unless you go out of your way to add them. When editing an existing file that already uses CRLF line endings, the carriage returns might be hidden from you. For example, vim does that. But it also says [dos] in the status line to warn you that the file is in DOS format. You can then say :set fileformat=unix and save the file to convert it. ..

.. To verify whether this is in fact the problem, do cat -v /etc/inti.d/testsam. If you have an erroneous carriage return, it will show up as ^M ..

.. Another way to fix the issue: sed -i -e 's/\r//g' /path/file ..

http://serverfault.com/questions/592702/no-such-file-or-directory-error-when-trying-to-execute-startup-script-in-debian

[oio11]

start-stop-daemon: --exec vs --startasstart-stop-daemon: --exec vs --startas
By Chris Lamb

start-stop-daemon is the classic tool on Debian and derived distributions to manage system background processes. A typical invokation from an initscript is as follows:

start-stop-daemon \ --quiet \ --oknodo \ --start \ --pidfile /var/run/daemon.pid \ --exec /usr/sbin/daemon \ -- -c /etc/daemon.cfg -p /var/run/daemon.pid

The basic operation is that it will first check whether /usr/sbin/daemon is not running and, if not, execute /usr/sbin/daemon -c /etc/daemon.cfg -p /var/run/daemon.pid. This process then has the responsibility to daemonise itself and write the resulting process ID to /var/run/daemon.pid.

start-stop-daemon then waits until /var/run/daemon.pid has been created as the test of whether the service has actually started, raising an error if that doesn't happen.

(In practice, the locations of all these files are parameterised to prevent DRY ( Don't repeat yourself - Wikipedia ) violations.)

Idempotency

By idempotence we are mostly concerned with repeated calls to /etc/init.d/daemon start not starting multiple versions of our daemon. This might not seem to be particularly big issue at first but the increased adoption of stateless configuration management tools such as Ansible (which should be completely free to call start to ensure a started state) mean that one should be particularly careful of this apparent corner case. In its usual operation, start-stop-daemon ensures only one instance of the daemon is running with the --exec parameter: if the specified pidfile exists and the PID it refers to is an "instance" of that executable, then it is assumed that the daemon is already running and another copy is not started. This is handled in the pid_is_exec method (source) - the /proc/$PID/exe symlink is resolved and checked against the value of --exec.

Interpreted scripts

However, one case where this doesn't work is interpreted scripts. Lets look at what happens if /usr/sbin/daemon is such a script, eg. a file that starts:

#!/usr/bin/env python # [..]

The problem this introduces is that /proc/$PID/exe now points to the interpreter instead, often with an essentially non-deterministic version suffix:

$ ls -l /proc/14494/exe lrwxrwxrwx 1 www-data www-data 0 Jul 25 15:18 /proc/14494/exe -> /usr/bin/python2.7

When this process is examined using the --exec mechanism outlined above it will be rejected as an instance of /usr/sbin/daemon and therefore another instance of that daemon will be incorrectly started.

--startas

The solution is to use the --startas parameter instead. This omits the /proc/$PID/exe check and merely tests whether a PID with that number is running:

start-stop-daemon \ --quiet \ --oknodo \ --start \ --pidfile /var/run/daemon.pid \ --startas /usr/sbin/daemon \ -- -c /etc/daemon.cfg -p /var/run/daemon.pid

Whilst it is therefore less reliable (in that the PID found in the pidfile could actually be an entirely different process altogether) it's probably an acceptable trade-off against the case of running multiple instances of that daemon.

This danger can be ameliorated by using some of start-stop-daemon's other matching tests, such as --user or even --name

Monday 28th July 2014
http://chris-lamb.co.uk/posts/start-stop-daemon-exec-vs-startas