[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#201182: debian-policy: /etc/init.d scripts mask failure

Package: debian-policy
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 scripts should not fail obscurely when the configuration files
     remain but the package has been removed, as configuration files remain

OK, 1."fail" 2."obscurely"
Well, the problem was #2 but the design decision was to instead change
the reporting of #1.  So now indeed the obscureness was not fixed, but
failures are no longer detectable.

What if the same design was carried over to rm(1) cp(1) mv(1). I
intend to do an operation but can't tell by $? if it succeeded and
can't count on stderr for failure notices.

     on the system after the package has been removed.  Only when `dpkg' is
     executed with the `--purge' option will configuration files be
     removed.  In particular, as the `/etc/init.d/<package>' script itself
     is usually a `conffile', it will remain on the system if the package
     is removed but not purged.  Therefore, you should include a `test'
     statement at the top of the script, like this:
          test -f <program-executed-later-in-script> || exit 0

On system A:
/etc/init.d/bla_bla start; echo $?
starts bla_bla.
On system B:
/etc/init.d/bla_bla start; echo $?
doesn't start bla_bla. $? is the same.

Apparently error message "no news is good news" doesn't apply here either.

Yes, this is all intentional and any changes now will probably break
lots of stuff, but would K&R have done it this way?
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux debian 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686
Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5

-- no debconf information

Reply to: