Bug#426877: dpkg: Option --oknodo should be the default behaviour for start-stop-daemon (LSB specs)
On Thu, Jul 03, 2008 at 10:40:53PM +0200, Raphael Hertzog wrote: The option --oknodo changes the behaviour to the LSB recomendations but many services in Debian don't use this option and return 1 in the case I've quotted. This is very problematic for me when I try to use a Debian service init script with HeartBeat that expects to receive a 0. I'm reluctant to change the default behaviour of start-stop-daemon at this point. What do other people think of making --oknodo the default behaviour and adding a new option to force the current default behaviour (exit with failure if nothing had to be done)? I think this sounds like there's no real transition plan between the two states; anything that actually relies on the current behavior of s-s-d without --oknodo will suddenly be broken. Changing the semantics of core tools in this way is a bad idea. The right answer is that we should be fixing the wrong init scripts, not trying to coerce all the init scripts with a change in s-s-d semantics. An init script may have a legitimate reason to want to check for the difference between exit statuses 0 and 1, without necessarily using this information a way that breaks the init script's own exit status, and changing s-s-d behavior will break these legitimate use cases. The alternative is to change policy and/or lintian to ensure that packages are using --oknodo unless they have a good reason not to. This was already discussed on debian-devel in March of this year. http://lists.debian.org/debian-devel/2008/03/msg00772.html Feel free to propose an amendment to policy that clarifies that sensible behavior is equivalent to --oknodo (without implying that init scripts are required to use s-s-d!), and I will happily second it; as I already commented in that thread, I think this is a mere clarification of what the policy has always been, not a change to policy at all. [1] LSB specifications about init script actions: http://www.linux-foundation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html That one's starting to get up there right next to our priorities are our users and free software on my list of Facile Arguments That Demonstrate The Poster Has No Clue. :P -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed (with 2 errors): Clarify what sensible behaviour is for init scripts
Processing commands for [EMAIL PROTECTED]: Reply-To: Unknown command or malformed arguments to command. In-Reply-To: [EMAIL PROTECTED] Unknown command or malformed arguments to command. reassign 426877 debian-policy 3.8.0.1 Bug#426877: dpkg: Option --oknodo should be the default behaviour for start-stop-daemon (LSB specs) Bug reassigned from package `dpkg' to `debian-policy'. retitle 426877 Clarify what sensible behaviour is for init scripts Bug#426877: dpkg: Option --oknodo should be the default behaviour for start-stop-daemon (LSB specs) Changed Bug title to `Clarify what sensible behaviour is for init scripts' from `dpkg: Option --oknodo should be the default behaviour for start-stop-daemon (LSB specs)'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426877: Clarify what sensible behaviour is for init scripts
Reply-To: In-Reply-To: [EMAIL PROTECTED] reassign 426877 debian-policy 3.8.0.1 retitle 426877 Clarify what sensible behaviour is for init scripts thanks Ok, this confirms my initial feeling. Changing this in dpkg would require a wide-scale testing and much effort for little gains since the policy already require packages to behave sensibly. Iñaki, if you ever encounter bad init scripts, please report bugs against the offending packages. On Fri, 04 Jul 2008, Steve Langasek wrote: Feel free to propose an amendment to policy that clarifies that sensible behavior is equivalent to --oknodo (without implying that init scripts are required to use s-s-d!), and I will happily second it; as I already commented in that thread, I think this is a mere clarification of what the policy has always been, not a change to policy at all. Here's a try (against current master branch): diff --git a/policy.sgml b/policy.sgml index c9bd84f..772afce 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5946,9 +5946,11 @@ rmdir /usr/local/share/emacs 2/dev/null || true The fileinit.d/file scripts must ensure that they will behave sensibly if invoked with ttstart/tt when the service is already running, or with ttstop/tt when it - isn't, and that they don't kill unfortunately-named user + isn't (in particular, they should not exit with a non-zero +error code), and that they don't kill unfortunately-named user processes. The best way to achieve this is usually to use - prgnstart-stop-daemon/prgn. + prgnstart-stop-daemon/prgn and its tt--oknodo/tt +option. /p p Russ, feel free to clone against lintian if you think that it makes sense that it warns usage of start-stop-daemon without this option. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 489238 to dpkg-dev
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.33 reassign 489238 dpkg-dev 1.14.20 Bug#489238: Cryptic message when using | in Conflicts Bug reassigned from package `dpkg' to `dpkg-dev'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489238: Cryptic message when using | in Conflicts
Package: dpkg Version: 1.14.20 Severity: wishlist Hi, I accidentally used a | in conflicts (instead of depends) in a build and this resulter in: dpkg-gencontrol: internal error: The method merge_union() is only valid for Dpkg::Deps::Simple As discussed on IRC with Raphaël, this is a bit cryptic; perhaps the error message could be improved to point out undefined usage of | in conflicts. Thanks -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 6.10-6 The GNU core utilities ii libc6 2.7-12 GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: setting package to dselect dpkg-dev dpkg, tagging 488903, tagging 143307
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # dpkg (1.14.21) UNRELEASED; urgency=low # # * Apply patch from Ian Jackson to correctly handle packages in status #triggers-awaited while trying to sort out a proper order for configuring #packages. Closes: #143307 # * Slovak (Ivan Masár). Closes: #488903 # package dselect dpkg-dev dpkg Ignoring bugs not assigned to: dpkg-dev dselect dpkg tags 488903 + pending Bug#488903: dpkg: [INTL:sk] Slovak translation There were no tags set. Tags added: pending tags 143307 + pending Bug#143307: [ASSERT] main/packages.c:191: process_queue: Assertion `dependtry = 4' failed Tags were: patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#21659: setting package to dselect dpkg-dev dpkg, tagging 21659
# Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # dpkg (1.15.0) UNRELEASED; urgency=low # # * Use description of installed package as fallback in dselect. #Based on a patch from Bruce Sass [EMAIL PROTECTED]. Closes: #21659 # package dselect dpkg-dev dpkg tags 21659 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: setting package to dselect dpkg-dev dpkg, tagging 21659
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # dpkg (1.15.0) UNRELEASED; urgency=low # # * Use description of installed package as fallback in dselect. #Based on a patch from Bruce Sass [EMAIL PROTECTED]. Closes: #21659 # package dselect dpkg-dev dpkg Ignoring bugs not assigned to: dpkg-dev dselect dpkg tags 21659 + pending Bug#21659: dselect doesn't show descriptions for obsolete packages Tags were: patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291320: patch submission
On Tue, 25 Jan 2005, Sergei Ivanov wrote: Could you drop me a note on whether the feature is worth considering for inclusion to dpkg, at some point in the future? (I don't know, maybe I'm the only one who finds fakeroot inconvenient.) At first sight, it looks reasonable. I updated your patch so that it applies correctly against the master branch and I pushed it in my private repo: Branch: http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug291320-dpkg-deb-force-root-owner Patch: http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;h=5fe1d467797a1cf8f03d1f4e4b656ac2a4a70a58 I tested the patch and it works as expected. Guillem, any opinon? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302079: dpkg: [PATCH] setting ulimit from start-stop-daemon
Hi Carlo,
sorry for the delay in getting back to you but dpkg has many open bugs...
On Wed, 30 Mar 2005, Carlo Contavalli wrote:
I'm a DD too, and if there is any chance for it to be included
in the ``upstream'' dpkg, I'd be willing to work on writing
documentation, verify it works under kfreebsd and hurd, update
it for your current development tree and generally verify its
correct behavior.
I like the idea of this patch and it makes much sense to me. So if you're
still interested in updating it and getting it merged, feel free to jump
in! :)
dpkg is now managed with git, see
http://wiki.debian.org/Teams/Dpkg/GitUsage
I don't like the resulting code pretty much,
Why didn't you try to understand what you didn't like and fix it? :)
I would also love to have a start-stop-daemon with reload
and some lightweight monitoring features, either in the main
dpkg package, or as an enhanced-start-stop-daemon package.
One thing at a time... :) and it might be that start-stop-daemon will
be mainly useless if we switch to upstart one day (which has such
respawn/restart features).
Anyway, here are a few comments but take them with a grain of salt as I'm
not very used to the dpkg codebase yet.
+AC_CHECK_HEADERS(sys/time.h sys/resource.h unistd.h)
Do we really need to check for those headers? AFAIK, they are mandated by
POSIX.
+#if defined(HAVE_SYS_TIME_H) defined(HAVE_SYS_RESOURCE_H) \
+defined(HAVE_UNISTD_H) defined(HAVE_SETRLIMIT)
defined(HAVE_GETRLIMIT)
+
+# define SSD_SETRLIMIT 1
+
+# include sys/time.h
+# include sys/resource.h
+#endif
If you keep the header checks, just protect each include by its HAVE_*
variable. And use directly the checks HAVE_(S|G)ETRLIMIT in the code
instead of using the intermediary SSD_SETRLIMIT.
+#ifdef SSD_SETRLIMIT
+static int
+do_getlimit(FILE * f, char ch, int * resource, const char ** rname) {
See below my remark about the parsing. This should be a simple
function to convert limit name (as) into the corresponding limit
identifier (RLIMIT_AS) and nothing more complicated.
[ Skip the rest of this function ]
+static void
+do_loadlimits(void)
+{
+ char * look=execname;
You should use startas here. It what's is really used
and should be always set with --start. If it's not set, you
shouldn't do anything anyway.
+ if(!look) {
+if(!startas)
+ return;
+
+look=startas;
+ }
No need for a fallback with startas, direct stop if not set.
+/* Calculate name of configuration file */
+ name=strrchr(look, '/');
+ if(name)
+name=name+1;
+ else
+name=look;
A simple name = name ? name+1 : look would be nicer.
+/* Calculate name of the file to be read */
+ path=xmalloc(sizeof(SSD_SETRLIMIT_PATH)+strlen(name)+1);
+ sprintf(path, SSD_SETRLIMIT_PATH /%s, name);
Wouldn't a fixed-size static buffer be simpler (with snprintf)?
FILENAME_MAX / PATH_MAX?
It's not like we'll ever reach any limit with length of daemon names.
+/* name of file/path to open */
+ f=fopen(path, r);
+ if(!f) {
+if(errno == ENOENT) {
+ if(quietmode 0)
+printf(%s: not loading limits -- missing file '%s'\n, name, path);
+ free(path);
+ return;
+}
+
+if(quietmode = 0)
+ printf(%s: couldn't open limits file -- %s\n, name,
strerror(errno));
+free(path);
+return;
+ }
Shouldn't we raise an error with fatal instead of silently continuing if
there's another problem (say a permission problem) ?
(I'm not sure of what's best)
+
+/* Ok, file has been opened, read limits */
+ while(1) {
+
+ /* Skip blanks */
+while((ch=fgetc(f)) != EOF (ch == '\t' || ch == ' ' || ch == '\n')) {
+ if(ch == '\n')
+ line++;
+}
Much of that parsing seems fragile/ugly to me. May I suggest to use
fgets() to read a line and then sscanf() to analyze it (with strcmp() to
verify if each field correspond to a valid value)?
And if the first field start with # then skip the line.
Same goes if sscanf has not been able to extract the 3 fields.
[ Skipping the rest of the function ]
The parsing should happen first and then the change of limits. Both
shouldn't be too tightly mixed as they are now.
+ /* Verify SOFT limit is = of the HARD limit */
+ *lvalue=(rlim_t)value;
+ if(lvalue == limit.rlim_max limit.rlim_cur limit.rlim_max) {
+ if(quietmode 0)
+ printf(%s: SOFT LIMIT was than HARD LIMIT -- decreased to HARD
LIMIT value on %s:%d (%s)\n,
+name, path, line, lname);
+
+ limit.rlim_cur=limit.rlim_max;
+ }
If the hard/soft limits are not set together, you might have troubles
due to incompatibilites between the current values and the new values...
in particular if the soft/hard limit setting happens with two calls to
setrlimit, no?
So maybe it's best to parse the whole file before doing the setrlimit
calls.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour
Bug#476899: dpkg: Leaves new conffiles as file.dpkg-new if the conffile is diverted
On Fri, 04 Jul 2008, Timothy G Abbott wrote: On Tue, 1 Jul 2008, Raphael Hertzog wrote: On Tue, 01 Jul 2008, Guillem Jover wrote: While I realize that using dpkg-divert on conffiles is an uncommon practice, the current behavior is clearly wrong. I've attached a simple git patch against current head that fixes this. Thanks for the patch! There's a problem with it though, namenodetouse has as a side effect to activate a file trigger. I'll probably be moving the side effect outside that function before applying this patch. We still have to activate the file trigger if we're effectively modifying the configuration file (i.e. in all cases except if the user decides to keep the old file IMO). So it could be argued that it's right to activate the trigger. After all, even if the user choose to keep the old configuration file, he might have merged some of the changes by hand (using the spawned shell). Do I miss something here? I think the point is that namenodetouse is already being called when unpacking the archive, and thus triggers have already been activated on the new filename. But the content of the conffile gets real only after configuration and any trigger recorded during unpack might have already been processed (at the end of a dpkg --unpack run started by apt) while the content of the file didn't get replaced yet (we only have the .dpkg-new file for now). In fact, it might simply be wrong to record activation of a file-based trigger during unpack when we're speaking of a configuration file! Ccing Ian to get his input. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
