Hi all, It seems to be a borderline case between /usr/bin and /usr/sbin but here goes anyway.
It's been pointed that the FHS recommends that if an ordinary user needs to run the command, then it should be placed in /usr/bin. So the answer then depends on what is an ordinary user. To me, a user that starts up the queueing facilities of whatever application is not an ordinary one (regardless of what account is actually used, that user has either a sysadmin, a dev or a devop role). On Wed, Nov 25, 2009 at 05:24:33PM +0100, Andreas Bolka wrote: > On Wed Nov 25 01:28:05 +0100 2009, Keith Rarick wrote: > > What is the right thing to do? > > +1 for /usr/bin. > > Unless beanstalkd ever gains multi-user facilities, putting it in > /usr/sbin is basically wrong, as it simply is no system binary and is > _not_ intended to be used as system-wide service daemon. The upstream tarball comes with a sysv init script that assumes that there is a single instance per host (it uses a lock file). Sure, one may want to run several instances in a single host but that doesn't make the program less of a service. The fact that I can run several httpds as an ordinary user in unprivileged ports doesn't make the httpd an end user program. Whether a beanstalkd instance is used system-wide is a matter of choice. > Two other programs with similar characteristics that come to mind are nc > and stunnel, both in /usr/bin, both allowing users to set up ad-hoc > network services (amongst other things). They're not comparable: nc and stunell operate at the transport level (ie. are application-unaware) whereas beanstalkd requires clients to talk its protocol Cheers, Serafeim -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en.
