Your message dated Sun, 03 Aug 2003 12:16:33 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#190749: debian-policy: /etc/init.d scripts example 'test
-f program-executed-later-in-script' should be 'test -x'
has caused the attached Bug report to be marked
Your message dated Mon, 14 Jul 2003 01:58:45 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#201182: debian-policy: /etc/init.d scripts mask failure
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If t
Package: debian-policy
Version: 3.5.8.0
Severity: minor
I don't think you are going to fix it at this late date, but next time
please try to follow Unix traditions about $? and emitting error
messages upon failure.
10.3.2. Writing the scripts
---
These scrip
Pierre THIERRY <[EMAIL PROTECTED]> wrote:
> [-- text/plain, encoding quoted-printable, 35 lines --]
>
> Package: debian-policy
> Version: 3.5.6.1
> Severity: minor
> Tags: patch
>
> In the 10.3.2 section, a example line to test if the program to execute
> does exist is given, but it only tests if
Package: debian-policy
Version: 3.5.6.1
Severity: minor
Tags: patch
In the 10.3.2 section, a example line to test if the program to execute
does exist is given, but it only tests if the file exists, not if it is
executable.
--- policy.sgml 2003-04-19 12:33:14.0 +0200
+++ policy.sgml.corre
On 21-Jun-00, 13:17 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote:
> Brock Rozen suggested that init.d scripts should have explicit
> PATH=... settings. No-one commented on the idea.
As I recall, there was a lot of discussion...although maybe it occurred
in -devel before Brock formally proposed
On Wed, 21 Jun 2000 at 18:41, Alexander Koch wrote about "Re: Bug#36151:...":
> I do not think this is how it is meant to be, given that
> /sbin/ is probably not in the typical user PATH setting for
> a reason. And it is not the default anyway.
You're right. But the typical user doesn't run scrip
> problem is not exclusive to /etc/init.d scripts.
>
> So should we close this bug and put this requirement/suggestion into
> the coding guidelines (which may, one day, be written)?
>
>Julian
>
>
--
Brock Rozen [EMAIL PROTECTED]
On Wed, 21 June 2000 19:17:21 +0100, Julian Gilbey wrote:
> Brock Rozen suggested that init.d scripts should have explicit
> PATH=... settings. No-one commented on the idea.
I had the problem when once I wrote a script that was
calling /etc/init.d/sysklogd which called start-stop-daemon.
Now /sbi
Brock Rozen suggested that init.d scripts should have explicit
PATH=... settings. No-one commented on the idea.
In general, all programs which make assumptions about PATH containing
more that /bin and /usr/bin should probably explicitly set PATH; this
problem is not exclusive to /etc/init.d
On 20-Apr-99, 01:05 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Apr 1999, Steve Greenland wrote:
> > And appending doesn't really help. If you assume that you can't trust
> > root's path, then you have to override it, or else you just trade one
> > set of problems ("can't find route
> > > > Consider su -c /etc/init.d/blah
Brock Rozen <[EMAIL PROTECTED]> wrote:
> What am I missing?
We have new sysadmins coming into being every hour. Learning is
heuristic. Right now, su -c ... is likely to fail for sbin/
commands.
If you change the system so that su -c is practically guaran
On Mon, 19 Apr 1999, Raul Miller wrote:
> > > Consider su -c /etc/init.d/blah
>
> > And if the PATH wasn't appended, how would su -c /etc/init.d/blah be any
> > different, except that it may not run?
>
> So? It's not as if su -c is the only issue involved. And, not running
> is only relevant
On Mon, 19 Apr 1999, Steve Greenland wrote:
> directories". My point is that if for some reason a bunch of the
> standard programs move to some other directory, then that new directory
> will need to be added to all the scripts. The scripts don't *know* what
> paths they need, except by convention
On Sun, 18 Apr 1999, Raul Miller wrote:
> > Consider su -c /etc/init.d/blah
Brock Rozen <[EMAIL PROTECTED]> wrote:
> And if the PATH wasn't appended, how would su -c /etc/init.d/blah be any
> different, except that it may not run?
So? It's not as if su -c is the only issue involved. And, not r
On 19-Apr-99, 02:26 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> Yes, it does require a lot of people to make modifications to a lot of
> scripts -- but it certainly doesn't require modifications again if the
> root path ever changes. Why? Because these script are appending what THEY
> need, ev
On Sun, 18 Apr 1999, Raul Miller wrote:
> I think that the append mechanism is bad because there are a number of
> contexts where this isn't the best solution.
>
> > The parents PATH would be inherited anyhow, wouldn't it? So we're
> > doing what to it that reduces security?
>
> Consider su -c /
On Sun, 18 Apr 1999, Steve Greenland wrote:
> > Does it hurt anything? I've yet to see anybody point out to me that it
> > does.
>
> Again: it requires that a lot of people make modifications to a lot
> scripts. It then puts us in a position that if the standard root path
> ever changes, all thos
On 18-Apr-99, 07:54 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> Does it hurt anything? I've yet to see anybody point out to me that it
> does.
Again: it requires that a lot of people make modifications to a lot
scripts. It then puts us in a position that if the standard root path
ever change
On Sun, 18 Apr 1999, Raul Miller wrote:
> > In general it's safer to fully specify root's $PATH rather than trust
> > what was inherited from the parent.
Brock Rozen <[EMAIL PROTECTED]> wrote:
> And this policy changes what?
There's several policies I've seen proposed: one specifying that root's
On Sun, 18 Apr 1999, Raul Miller wrote:
> It seems like running inetd via env would be a good idea, for the above
> bug reports (though this wouldn't directly solve Brock's problem).
>
> Then again, I think Brock should also consider using env.
My particular problem was solved by using a ~/.ssh/
On Sun, 18 Apr 1999, Anthony Towns wrote:
> Alternately, something along the lines of ``Scripts must not assume
> the environment is at all sensible, and should do something like the
> following to ensure it is...'' would be fine, with the ellipses filled
> in. Just changing the PATH isn't particu
On Sun, 18 Apr 1999, Raul Miller wrote:
> In general it's safer to fully specify root's $PATH rather than trust
> what was inherited from the parent.
And this policy changes what? The parents PATH would be inherited anyhow,
wouldn't it? So we're doing what to it that reduces security?
> If we co
Anthony Towns wrote:
> Consider bugs #10813 and #32579 [0].
..
> I'm of course happy to leave everything exactly as it is for the moment
> -- I'm not that averse to the ``It hurts if I do this'' ``Then don't
> do that.'' philosophy -- but I think that just declaring that changing
> root's PATH, TZ
Brock Rozen <[EMAIL PROTECTED]> wrote:
> Essentially, my proposal is trying to solve one problem, and one problem
> only -- the inability to reach a certain program because the PATH has been
> changed/deleted/whatever. The solution to that is adding a simple PATH
> line that appends whatever PATH t
On Sun, Apr 18, 1999 at 03:54:07PM +0300, Brock Rozen wrote:
> I have to agree, and as such, I'll bounce the ball back into your court
> and ask you to improve my proposal (or make a separate one) that will
> solve the different TZ settings or whatever other problems you mentioned.
Sure.
``Script
On Sun, 18 Apr 1999, Anthony Towns wrote:
> Note: dpkg -i fails with the following warning:
> ] dpkg: `ldconfig' not found on PATH.
> ] dpkg: `start-stop-daemon' not found on PATH.
> ] dpkg: `install-info' not found on PATH.
> ] dpkg: `update-rc.d' not found on PATH.
>
> These are in /sbin, /sbin
On Sun, Apr 18, 1999 at 01:34:57PM +0300, Brock Rozen wrote:
> So we DO have to deal with an existing issue, because scripts are being
> written however the maintainer wants them to be written.
(Forgive me if I don't see this as a huge problem)
> I think the time
> for a policy has come, and tha
An additional note that somebody else posted to debian-devel (I believe)
-- this shows that there ARE scripts in /etc/init.d that set the PATH
line, and to the best of knowledge, do not even append, but just
overwrite.
So we DO have to deal with an existing issue, because scripts are being
written
On Sat, 17 Apr 1999, Steve Greenland wrote:
> > Unless, of course, the default system $PATH has been changed, for whatever
> > reason.
>
> But if it was changed for a reason, then the scripts shouldn't override
> it.
What if they append to it? If they don't, we risk the situation
that they are n
On Sat, Apr 17, 1999 at 04:57:47PM -0500, Steve Greenland wrote:
> The real point is that there are two conflicting desires:
>
> 1. That the sysadmin be able to make stupid changes to the environment,
> and that everything still work.
>
> 2. That the sysadmin be able to make clever changes to the
On 17-Apr-99, 12:20 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
>
> Unless, of course, the default system $PATH has been changed, for whatever
> reason.
But if it was changed for a reason, then the scripts shouldn't override
it.
> What if I change the path? These scripts should work even if I
On 17 Apr 1999, Jean Charles Delepine wrote:
> > Assume I'm running as root and have made the changes to let it happen w/o
> > a password. I'm going to get an error here that it can't find
> > "start-stop-daemon". Alternatively, if I change the "daemon" script to
> > point to /sbin/start-stop-daem
On 16 Apr 1999, Roderick Schertler wrote:
> > All scripts must have one of the following two contained in them:
> >
> > 1) A PATH environment setting that lists all the directories where any
> > programs invoked by the script may be found.
>
> I don't think this is a good idea. Why should the sa
Brock Rozen <[EMAIL PROTECTED]> writes:
> One solution I've come up with is to use something of the sort:
>
> ssh remotehost /etc/init.d/daemon reload
>
> Assume I'm running as root and have made the changes to let it happen w/o
> a password. I'm going to get an error here that it can't find
> "s
On Fri, 16 Apr 1999 10:41:21 +0300 (IDT), Brock Rozen <[EMAIL PROTECTED]> said:
>
> All scripts must have one of the following two contained in them:
>
> 1) A PATH environment setting that lists all the directories where any
> programs invoked by the script may be found.
I don't think this is a go
[After discussion on other lists, I've reached the conclusion that this is
a policy issue regarding section 4.4 of Debian policy -- SCRIPTS]
Hi,
I'm working on some scripts that will allow various daemons to be
start/stopped/reloaded from other machines, automatically.
One solution I've come up
e the /etc/rcn.d/* symbolic links in dpkg's conffiles
list! This will cause problems! Do, however, include the /etc/init.d
scripts in conffiles.
A rationale for the last sentence could be added.
After asking in debian-policy, it seems that there are several reasons
for this:
* The
quot;
This means _all_ scripts have to provide all 5 options. If any options
fails, an appropriate error message should be displayed on stderr and a
non-zero error level has to be returned.
-cut-here-
I just want to get sure we are all talking about the same proposal. If
n
> -force reload?
I think we need to choose a single word for this, to minimise the script
changes. A single word would allow a simple chang to the case statement in
most cases:
- reload )
+ reload | rewibble )
Possibilities for ``rewibble'':
force-reload
revisit
or from the Oxf
On 08-Dec-1997 20:44:17, Guy Maor <[EMAIL PROTECTED]> wrote:
> The command which reloads or fails should continue to be called
> reload. The one which does or a reload or restart can be called
> something else, though I'm also at a loss for a suggestion.
forcereload?
reload force?
-force reload
Ian Jackson <[EMAIL PROTECTED]> writes:
> Klee points out:
> > Scripts that want to be clever about restarting systems should use
> > '/etc/init.d/
Klee points out:
> I definitely agree regarding 'start|stop|restart'. However, I believe
> that 'reload' should take action only if properly supported by the
> system in question. When I use the 'reload' argument, it's for the
> specific purpose of making the system reload it's configuration file
Ian Jackson <[EMAIL PROTECTED]> writes:
> Bdale:
> > I would like to propose that all scripts placed in /etc/init.d should
> > be required to support at least the four arguments
> > 'start|stop|reload|restart'. In cases where there is currently no
> > 'restart', it could easily be formed as the s
Bdale:
> I would like to propose that all scripts placed in /etc/init.d should
> be required to support at least the four arguments
> 'start|stop|reload|restart'. In cases where there is currently no
> 'restart', it could easily be formed as the sequence of actions to
> perform a stop followed by
I would like to propose that all scripts placed in /etc/init.d should be
required to support at least the four arguments 'start|stop|reload|restart'.
In cases where there is currently no 'restart', it could easily be formed as
the sequence of actions to perform a stop followed by a start. In cases
46 matches
Mail list logo
