Bug#693960: [Pkg-sysvinit-devel] Bug#693960: sysvinit: Undocumented, obscure limit for process field in inittab entries

2012-11-23 Thread Johannes Truschnigg
On Thu, Nov 22, 2012 at 05:30:31PM -0200, Henrique de Moraes Holschuh wrote:
 Eh, should we also increase that limit to something larger [if it is
 feasible to do so] ?

Whilst I do not like that kind of arbitrary limit, I don't think it's
critically important (let alone good) to have absurdly long lines in inittab.
If you need to do something that doesn't fit in 127 bytes on its command line,
you might just as well write a wrapper, and call that fron inittab. Helps
keeping things tidy - but that's personal preference of course.

-- 
with best regards:
- Johannes Truschnigg ( johan...@truschnigg.info )

www:   http://johannes.truschnigg.info/
phone: +43 650 2 17
xmpp:  johan...@truschnigg.info

Please do not bother me with HTML-email or attachments. Thank you.


signature.asc
Description: Digital signature


Bug#693960: sysvinit: Undocumented, obscure limit for process field in inittab entries

2012-11-22 Thread Johannes Truschnigg
Package: sysvinit
Version: 2.88dsf-13.1+squeeze1
Severity: minor
Tags: patch


I added a new entry to inittab on a busy host which did not seem to start upon
invoking `telinit q`. Syslog received the following message:

Nov 22 10:16:29 r7 init: /etc/inittab[93]: process field too long

This limit (127 characters) is not documented in man 5 inittab, nor anywhere
else I looked. In init's source file, there are error messages the explicitely
state length limits for other fields in inittab (which a user is much less
likely to overflow, I think), which seems kind of weird.

The attached patch adds the length limit information to init's error message
and to the appropriate man page.


-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sysvinit depends on:
ii  initscripts2.88dsf-13.1+squeeze1 scripts for initializing and shutt
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libselinux12.0.96-1  SELinux runtime shared libraries
ii  libsepol1  2.0.41-1  SELinux library for manipulating b
ii  sysv-rc2.88dsf-13.1+squeeze1 System-V-like runlevel change mech
ii  sysvinit-utils 2.88dsf-13.1+squeeze1 System-V-like utilities

sysvinit recommends no packages.

sysvinit suggests no packages.

-- no debconf information
diff -u -r a/sysvinit-2.88dsf/man/inittab.5 b/sysvinit-2.88dsf/man/inittab.5
--- a/sysvinit-2.88dsf/man/inittab.5	2009-09-10 10:28:49.0 +0200
+++ b/sysvinit-2.88dsf/man/inittab.5	2012-11-22 10:32:17.554426005 +0100
@@ -66,7 +66,7 @@
 .B init 
 will not do utmp and wtmp accounting for that process.  This is needed for 
 gettys that insist on doing their own utmp/wtmp housekeeping.  This is also 
-a historic bug.
+a historic bug. The length of this fiels is limited to 127 characters.
 .\}}}
 .PP
 The \fIrunlevels\fP field may contain multiple characters for different
diff -u -r a/sysvinit-2.88dsf/src/init.c b/sysvinit-2.88dsf/src/init.c
--- a/sysvinit-2.88dsf/src/init.c	2010-04-13 11:48:54.0 +0200
+++ b/sysvinit-2.88dsf/src/init.c	2012-11-22 10:28:54.653475075 +0100
@@ -1314,7 +1314,7 @@
 	if (rlevel  strlen(rlevel)  11)
 		strcpy(err, rlevel field too long (max 11 characters));
 	if (process  strlen(process)  127)
-		strcpy(err, process field too long);
+		strcpy(err, process field too long (max 127 characters));
 	if (action  strlen(action)  32)
 		strcpy(err, action field too long);
 	if (err[0] != 0) {


Bug#693960: [Pkg-sysvinit-devel] Bug#693960: sysvinit: Undocumented, obscure limit for process field in inittab entries

2012-11-22 Thread Henrique de Moraes Holschuh
On Thu, 22 Nov 2012, Johannes Truschnigg wrote:
 Package: sysvinit
 Version: 2.88dsf-13.1+squeeze1
 Severity: minor
 Tags: patch
 
 
 I added a new entry to inittab on a busy host which did not seem to start upon
 invoking `telinit q`. Syslog received the following message:
 
 Nov 22 10:16:29 r7 init: /etc/inittab[93]: process field too long
 
 This limit (127 characters) is not documented in man 5 inittab, nor anywhere
 else I looked. In init's source file, there are error messages the explicitely
 state length limits for other fields in inittab (which a user is much less
 likely to overflow, I think), which seems kind of weird.

Eh, should we also increase that limit to something larger [if it is
feasible to do so] ?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#693960: [Pkg-sysvinit-devel] Bug#693960: sysvinit: Undocumented, obscure limit for process field in inittab entries

2012-11-22 Thread Roger Leigh
On Thu, Nov 22, 2012 at 05:30:31PM -0200, Henrique de Moraes Holschuh wrote:
 On Thu, 22 Nov 2012, Johannes Truschnigg wrote:
  Package: sysvinit
  Version: 2.88dsf-13.1+squeeze1
  Severity: minor
  Tags: patch
  
  
  I added a new entry to inittab on a busy host which did not seem to start 
  upon
  invoking `telinit q`. Syslog received the following message:
  
  Nov 22 10:16:29 r7 init: /etc/inittab[93]: process field too long
  
  This limit (127 characters) is not documented in man 5 inittab, nor anywhere
  else I looked. In init's source file, there are error messages the 
  explicitely
  state length limits for other fields in inittab (which a user is much less
  likely to overflow, I think), which seems kind of weird.
 
 Eh, should we also increase that limit to something larger [if it is
 feasible to do so] ?

Looks like it's just the process field in struct _child_
(src/init.h); but there's also a static line buffer.  We
could potentially make this dynamically allocated with
imalloc; or just make it longer and also increase the
line buffer size accordingly.

(It's kind of horrible that they hard coded the size
when checking, rather than using sizeof())


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org