On Thu, 27 Jul 2006, Petter Reinholdtsen wrote:
Also, the 8 character user name limit can be traced to POSIX, where
only 8 characters are guaranteed to work. See _POSIX_LOGIN_NAME_MAX in
URL:http://www.opengroup.org/onlinepubs/007908799/xsh/limits.h.html.
I believe it is smart to limit user
On Fri, 08 Sep 2006, Petter Reinholdtsen wrote:
/dev/.udev. Anything else required before disabling the
/proc/bus/usb/ mounting?
Sure. Nothing in userspace using it. Which is the point I was trying to
make, but apparently failed to do.
libusb is not the only user of usbfs. If the kernel
On Sun, 10 Sep 2006, Marco d'Itri wrote:
On Aug 02, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
Initscripts depends on /sbin/fsck.
I wonder how you came to this conclusion. I purged e2fsprogs and then
configured my system to not use fsck[1] and everything works fine.
[1
On Mon, 11 Sep 2006, Petter Reinholdtsen wrote:
and would prefer it to be available in etch. I plan to switch to
tmpfs for /var/run/ and /var/lock/ after etch, and I guess /var/run/
could be bind-mounted from /lib/run/ when /var/ is mounted, to avoid
having too many tmpfs file systems around.
On Mon, 11 Sep 2006, Petter Reinholdtsen wrote:
[Tim Rühsen]
The mountdevsubfs.sh init script mounts /dev/shm with the noexec
flag. UML (/usr/bin/linux) complains about that and doesn't start.
I suspect this use of /dev/shm/ is really a bug in UML. /dev/shm/ is
Depends on what it is
On Mon, 11 Sep 2006, Petter Reinholdtsen wrote:
I'm not quite sure what your problem is, but I'll try to recap it as I
understand it. You have a system with USB, and an external USB disk
connected all the time which you want to have mounted when you boot.
The only way we can support this
On Mon, 11 Sep 2006, Petter Reinholdtsen wrote:
[Henrique de Moraes Holschuh]
The only way we can support this nowadays is with the full async userspace
model.
Why? For the case of mounting a fixed USB disk, I would expect udev
to find it before its init.d scripts is done
On Tue, 12 Sep 2006, Petter Reinholdtsen wrote:
The current mountall.sh uses this mount command, after the proc file
systems are mounated
mount -a -t noproc,nfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs \
-O no_netdev
This is correct, the first no negates *all* others (see mount
On Wed, 13 Sep 2006, Petter Reinholdtsen wrote:
runlevel 2. The result is that start scripts started with the symlink
in rcS.d/ will also run with the symlink in rc2.d/.
Given that this is allowed behaviour (not rerunning start scripts is an
optimization, but just that), I don't know what to
On Thu, 14 Sep 2006, Petter Reinholdtsen wrote:
[Henrique de Moraes Holschuh]
S has never been the single user runlevel. WTF is init doing with S that
got you worried?
It is storing 'S' in the runlevel variable, and passing it as
RUNLEVEL=S when you do 'telinit s', and 'telinit 1
On Thu, 14 Sep 2006, Petter Reinholdtsen wrote:
Right. I intended to use those if /usr/ was part of the root
partition, and have changed the PATH to include /usr/bin/ for those
scripts.
I'd suggest we also start working to get on_ac_power in its proper place:
/bin. Reimplementing it to only
On Sat, 16 Sep 2006, Petter Reinholdtsen wrote:
to handle coldplug events. Because of this, I integrated the patches
from ubuntu to mount /var/run and /var/lock/ as tmpfs file systems in
mountkernfs.sh, the very first thing to happen during boot.
I am quite fine with this, as long as a later
On Sat, 16 Sep 2006, Petter Reinholdtsen wrote:
Not sure how to handle those packages where we do not know when the
fix will be uploaded. A simple conflict without a version seem a bit
harsh for a essential package to do. Any opinions on this?
None, AFAIK. I think we will have to add an
On Sat, 16 Sep 2006, Henrique de Moraes Holschuh wrote:
On Sat, 16 Sep 2006, Petter Reinholdtsen wrote:
to handle coldplug events. Because of this, I integrated the patches
from ubuntu to mount /var/run and /var/lock/ as tmpfs file systems in
mountkernfs.sh, the very first thing to happen
On Sat, 16 Sep 2006, Petter Reinholdtsen wrote:
[Henrique de Moraes Holschuh]
I just remembered something: how are you going to make sure there is
a /var/run and /var/lock mountpoint to use on the root filesystem?
They are created when initscripts is installed, by remounting / to
avoid
On Sat, 16 Sep 2006, Henrique de Moraes Holschuh wrote:
Well, I think we will need to ask a TC rulling for this one, given that
people could not decide on a name for it.
And the thread in -devel shows I am quite right, again. I am in no mood to
wait for it to settle, as past experience says
On Sun, 17 Sep 2006, Mario 'BitKoenig' Holbe wrote:
cons, and issues and difficulties... would it probably make sense to
split the discussion about /var/x being able to be tmpfs'ed out and just
choose another location for the intended place-to-store-things-while-
nothing-else-is-mounted-rw?
On Fri, 22 Sep 2006, Tim Phipps wrote:
Hmm, tough choices to make. Though I don't think it's a good idea to have nfs
mounts in /etc/fstab marked as auto if they depend on hotplug network
interfaces. I think in that case you should have a hotplug script that mounts
We ought to keep fstab as
On Sat, 23 Sep 2006, Petter Reinholdtsen wrote:
[Henrique de Moraes Holschuh]
None, as /lib/init/rw will not be an optional thing.
Initial testing show that this do not work. If /etc/mtab is a
symlink, mount refuses to update it. If it is a bind mount, mount is
unable to create /etc/mtab
On Fri, 29 Sep 2006, Debian Bug Tracking System wrote:
Version: 2.86.ds1-20
This is in Etch.
Version: 2.86.ds1-23
And this is not and will not be in Etch.
Right. I hadn't considered that. This problem was fixed in version
2.86.ds1-23, when I changed checkroot.sh to use /lib/init/rw/
On Fri, 29 Sep 2006, Jeff Dike wrote:
On Fri, Sep 29, 2006 at 07:46:01PM +0200, Mattia Dongili wrote:
Thinking of a Debian only fix for the above, does simply playing with
default_tmpdir in arch/um/os-Linux/mem.c (probably in which_tmpdir())
suffice to use /lib/init/rw/.ramfs as default?
On Sun, 22 Oct 2006, Wolfgang Pfeiffer wrote:
So I'd suggest an option to force the usual fsck no matter whether the
machine is running on AC or battery -- perhaps via some setting in
/etc/default/.
Is anything wrong with the /forcefsck file?
--
One disk to rule them all, One disk to find
On Mon, 11 Dec 2006, Jurij Smakov wrote:
I maintain a daemon, which may be started in two different ways: on
loading of a kernel module (via a modprobe hook) and in a usual way by
init script (during boot). The problem is that when udev triggers the
loading of the module early in the boot
On Mon, 01 Jan 2007, Jason Lunz wrote:
I'm unable to find any convincing reason why the /lib/init/rw tmpfs
remains mounted after boot. Another late-boot initscript could be added
to unmount it in the name of general mtab cleanliness.
And what are you going to do with the data which is in
On Sat, 13 Jan 2007, Paolo wrote:
config, is a secondary point, main one is that RAMRUN - ie /var/run on
tmpfs - and perhaps others, doesn't look like an acceptable option in Etch
current, as too many pkgs don't expect volatile dirs under /var/run hence
fail on (re)boot.
Respective
On Sun, 14 Jan 2007, Paolo wrote:
On Sun, Jan 14, 2007 at 12:13:34PM -0200, Henrique de Moraes Holschuh wrote:
their init.d/ scripts. Case in point was clamav-daemon, which didn't start
on boot, expecting /var/run/clamav/ to be already there. Same for virus-DB
updater freshclam
On Sun, 14 Jan 2007, [EMAIL PROTECTED] wrote:
problem. If ifdown isn't being called, I wonder if also sync is not
called?
It would explain file system corruption bugs etch / debian folk have written
of across reboots.
Actually, the lack of a shutdown bus operation on ide, scsi and
On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote:
File systems ought to know to flush their caches and otherwise handle
shutdown/restart/sleep/resume.
They do. The storage [disk] devices don't.
Block device drivers should be smart enough to sync on their own when idle
for more than a
Just so you guys know:
1. Kernels 2.6.18+ are guaranteed to properly sync SCSI and libata SATA
disks on reboot and shutdown. halt(8) doesn't need to do it at all. I will
check 2.6.16 too, since Adrian Bunk is taking care of that and it is likely
to be around for a while.
2.
reassign 403863 chkrootkit
severity 403863 wishlist
retitle 403863 chkrootkit: please remove known false positives
thanks
On Sun, 25 Mar 2007, Binzberger Viktor wrote:
The following suspicious files and directories were found:
/lib/init/rw/.mdadm
/lib/init/rw/.ramfs
Now this means that your
unmerge 403863
reassign 403863 initscripts
retitle 403863 initscripts: Stray file /lib/init/rw/.ramfs not in package list
thanks
Drat, I didn't notice 403863 and 406493 were merged. I am undoing the
changes to 403863...
On Mon, 26 Mar 2007, Debian Bug Tracking System wrote:
reassign 403863
On Wed, 11 Apr 2007, Joerg Platte wrote:
I hope this has not been discussed before. I installed Debian in a chroot and
copy this image to several boxes using rsync. Package upgrades are started
within the chroot environment.
These packages should have bugs filled asking them to switch to
On Sun, 22 Apr 2007, [EMAIL PROTECTED] wrote:
Package: initscripts
Version: 2.86.ds1-1
The bug was fixed in 2.86.ds1-2 in 2005.
Please upgrade to Debian Etch (the latest Debian stable) if you want the
bugfix.
--
One disk to rule them all, One disk to find them. One disk to bring
them all
On Mon, 14 May 2007, Francesco Pretto wrote:
Ubuntu [1] ang Gentoo [2] bugs opened. Sent a mail to Miquel van
Smoorenburg, dev of sysvinit.
For all Debian sysvinit issues, please send email to
pkg-sysvinit-devel@lists.alioth.debian.org (added to CC).
For the Debian sysvinit crew: Guys, have a
tags 157355 wontfix
severity 157355 wishlist
thanks
The hard truth about this bug is that the only way to really fix it is in
the kernel, and that means adding an UPS shutdown handler to the kernel and
calling it just before the ACPI/APM poweroff call, now that the kernel is
learning to sync and
Well,
I have done all I have the time to do right now on this issue. Please test
the changes in the libata-fixes branch, if they are good, we should merge
them into trunk and upload. Also, at least R1054 needs to go to Debian
stable.
--
One disk to rule them all, One disk to find them. One
tags 426224 upstream help confirmed
thanks
The proper fix to this bug requires:
1. That sysvinit hddown.c be fixed (and fixes sent upstream) so that:
a) it uses sysfs and not /proc to locate disks, and that it locates
all IDE and SCSI/libata disks, or maybe do both /proc and
On Mon, 03 Sep 2007, Michael Holzt wrote:
I intent to package apparmor for debian. Apparmor depends on securityfs be
mounted. Securityfs is included in the linux kernel for quite a while and
seems to be used by the kernel tpm driver as well.
2.6.21 tpm driver doesn't seem to provide securityfs
On Tue, 04 Sep 2007, Michael Holzt wrote:
2.6.21 tpm driver doesn't seem to provide securityfs in a non-SE-Linux box.
Does it depend on anything else than just loading tpm?
I can't tell. I just observed that the code in drivers/char/tpm/tpm_bios.c
attempts to create some securityfs files
On Thu, 06 Sep 2007, Henrique de Moraes Holschuh wrote:
On Tue, 04 Sep 2007, Michael Holzt wrote:
2.6.21 tpm driver doesn't seem to provide securityfs in a non-SE-Linux
box.
Does it depend on anything else than just loading tpm?
I can't tell. I just observed that the code
On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote:
problem here, but some folks on a forum did it for me in a better way than I
could, so please refer to
http://forum.slicehost.com/comments.php?DiscussionID=183
to see all the problem...
It boils down to something breaking /dev/initctl and
On Sun, 18 Nov 2007, Petter Reinholdtsen wrote:
I have a few design issues. Should I place the API files in the
sysv-rc, the initscripts or the sysvinit-utils package? The users are
sysv-rc and initscripts, and I am not sure we want initscripts to
depend on sysv-rc. On the other hand, do we
On Sun, 09 Dec 2007, Marc Haber wrote:
during a discussion on the LKML, it was suggested to do dmesg
/dev/random in the startups scrips of a distribution. Please
consider doing this in Debian.
Debian already seeds /dev/random with data from the last shutdown. And
there is little entropy in
On Wed, 12 Dec 2007, Marc Haber wrote:
On Wed, Dec 12, 2007 at 05:45:55PM -0200, Henrique de Moraes Holschuh wrote:
On Sun, 09 Dec 2007, Marc Haber wrote:
during a discussion on the LKML, it was suggested to do dmesg
dev/random in the startups scrips of a distribution. Please
On Sat, 15 Dec 2007, Petter Reinholdtsen wrote:
The patch seem sane enough, but one thing make we wonder. Are init.d
scripts supposed to have names with + or * in them? Especially the *
might confuse other parts of the boot system (for example
/etc/init.d/rc), and I am thus unsure if this is
On Sat, 15 Dec 2007, Petter Reinholdtsen wrote:
Hi. Who on this list is active with sysvinit package work these days?
I am active in email matters, only :(
Did anyone check the halt / disk shutdown patches? I have not spent
time so far investigating the issue, so I hope someone else on the
On Sat, 16 Feb 2008, [EMAIL PROTECTED] wrote:
Sitting real close to my Thinkpad in a very quiet room, I noticed
# reboot
spins down the disk momentarily! How wasteful.
Seen with current sid stock kernel, etc.
Try this patch:
--- halt.dpkg-dist 2008-01-02 22:09:22.0 -0200
+++
On Sat, 16 Feb 2008, [EMAIL PROTECTED] wrote:
HdMH # Don't shut down drives if we're using RAID.
But I don't use raid.
Forget the comment, after the patch, it will not stop drives ever.
I won't be on a machine where I can put my ear next to the disk until
a few days from now, and it
On Fri, 04 Apr 2008, Hubert Verstraete wrote:
This is probably because this Flush Cache command is not supported by my
hard disk model; another IDE hard disk I tried did not have this issue.
We can't affort to add a blacklist to this, I think. It will not be
effectively maintained. But the
Usually, alternative initscript systems supply their own update-rc.d and
invoke-rc.d. That can be a bit more robust, although it IS a lot of code
duplication.
What exactly do you intend to do with these changes to sysv-rc's
update-rc.d?
--
One disk to rule them all, One disk to find them.
On Tue, 15 Jul 2008, Kel Modderman wrote:
On Tuesday 15 July 2008 00:07:13 Henrique de Moraes Holschuh wrote:
Usually, alternative initscript systems supply their own update-rc.d and
invoke-rc.d. That can be a bit more robust, although it IS a lot of code
duplication.
What exactly do
On Tue, 15 Jul 2008, Kel Modderman wrote:
When I first learned what a patch is and how to share it, my reference was
akpm's The perfect patch.
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
In the document he suggests not to use the 0/N introductory email. Since I
submit patches
On Mon, 25 Aug 2008, Petter Reinholdtsen wrote:
At the moment, it is not very easy for KDE and Gnome (or any other
user application for that matter), to know that a shutdown is in
progress, and act accordingly.
A shutdown *REQUEST* is outstanding you mean. Shutdown in progress means we
are
On Tue, 14 Oct 2008, Paolo Miotto wrote:
I think that actions like reload or force-reload must work like start
and restarting, doing nothing if the service is disabled in current
runlevel.
Maybe for force-reload. As for reload, if that is suceeding on a service
that is not started (i.e.
On Wed, 15 Oct 2008, Paolo Miotto wrote:
Well, it is OK that a script called with reload fails if the service is
not running, but the point is: why ask a reload to a service that is not
running (because disabled), maybe failing even a pre/post install script?
Because reload (and force-reload,
On Wed, 15 Oct 2008, Paolo Miotto wrote:
Quoting Henrique de Moraes Holschuh [EMAIL PROTECTED]:
On Tue, 14 Oct 2008, Paolo Miotto wrote:
I think that actions like reload or force-reload must work like start
and restarting, doing nothing if the service is disabled in current
runlevel.
Maybe
On Tue, 28 Oct 2008, Josh Triplett wrote:
urandom should have some kind of flag to disable the saving and
restoring of entropy. How about using POOLSIZE=0 as that flag?
Maybe you should give us a *strong* usercase for doing that, first?
--
One disk to rule them all, One disk to find them.
On Tue, 28 Oct 2008, Josh Triplett wrote:
The init scripts should automatically mount a tmpfs on /tmp if / gets
mounted read-only, since many other things will fail if they cannot
write to /tmp.
Provided that we check /etc/fstab first and refrain from doing anything if
/tmp is mentioned there,
On Tue, 04 Nov 2008, Josh Triplett wrote:
urandom should have some kind of flag to disable the saving and
restoring of entropy. How about using POOLSIZE=0 as that flag?
Maybe you should give us a *strong* usercase for doing that, first?
Making Debian work with a read-only root
On Tue, 30 Dec 2008, Petter Reinholdtsen wrote:
Hi. I suggest adding Kel Modderman as a new sysvinit alioth team
member. He is one of the few active with sysvinit development, and I
believe he would be a great contributor to maintaining the sysvinit
system in Debian.
IMHO, go ahead.
Any
On Thu, 01 Jan 2009, Petter Reinholdtsen wrote:
Right. So you have been hit by the introduction of asynchronous
behaviour of the Linux kernel. I have no good idea how to solve it.
I do, but it is a lot of work, and dangerous too.
1. Have a rw in-mem store available before udev coldplug. We
A recent thread in debian-user by someone that had massive data loss on an
EeePC and was blaming the initscripts for it caught my attention, and I did
a quick check.
I found the following problems that I feel we really should address. Please
correct me if I am wrong:
1. We do not honour
On Tue, 20 Jan 2009, t...@mediaforest.net wrote:
And what are you going to do with the data which is in /lib/init/rw ? Move
it around causing all sort of nasty races with running daemons that might be
using it?
The problem is that there isn't anything except dot files of zero size
On Tue, 20 Jan 2009, t...@mediaforest.net wrote:
I can't find any information about the way tmpfs_size is calculated, but on
two boxes, it is the half of system memory.
The problem is that on one I get /lib/init/rw and /dev/shm sized to 1.8
Gbytes and the other sized to 500 Mbytes, which
On Tue, 20 Jan 2009, Petter Reinholdtsen wrote:
[Henrique de Moraes Holschuh]
Limiting /lib/init/rw to 10MB or so would be a damn good hint to
anything using it that we don't want any abuse there... I don't see
why we wouldn't want to do it.
The reason I did not put a limit
On Fri, 30 Jan 2009, Petter Reinholdtsen wrote:
[Henrique de Moraes Holschuh]
Err, how can it NOT be safe to write there?
If something try to write there before /etc/rcS.d/S02mountkernfs.sh
has executed, it will not be possible to write to /lib/init/rw/.
There shouldn't EXIST a non
On Mon, 16 Feb 2009, Petter Reinholdtsen wrote:
[Martin F Krafft]
/sbin/runlevel is obviously confused, while /sbin/init seems to know
precisely what the runlevel is:
I believe runlevel uses /var/run/*tmp, and guess its content is bogus.
Any idea what could mess up the utmp/wtmp files?
On Fri, 13 Feb 2009, Russ Allbery wrote:
I went to write the patch for this, but I paused when I saw that the other
part of this sentence (explicitly running such scripts with sh at other
run levels) is implemented. The current /etc/init.d/rc runs the script
directly if it doesn't end in .sh
On Sat, 21 Feb 2009, Rieker Flaik wrote:
I just hate it to see that /dev/shm and /lib/init/rw use hundrets of
Megabyte of my RAM!!!
They don't. That's the maximum ammount of virtual memory they're allowed to
use, just that.
Unless, of course, something is filling those filesystems with junk?
On Sat, 21 Feb 2009, Rieker Flaik wrote:
Am Samstag, den 21.02.2009, 00:04 -0300 schrieb Henrique de Moraes
Holschuh:
On Sat, 21 Feb 2009, Rieker Flaik wrote:
I just hate it to see that /dev/shm and /lib/init/rw use hundrets of
Megabyte of my RAM!!!
They don't. That's the maximum
Are there other parts of Squeeze that would malfunction with Linux kernels
older than 2.6.26 ?
The version check is pretty much a good idea for safety reasons, I think it
would be better to just leave it in, and we can get rid of it for Squeeze+1.
--
One disk to rule them all, One disk to
On Wed, 18 Mar 2009, Roger Leigh wrote:
On Wed, Mar 18, 2009 at 05:38:38PM -0300, Henrique de Moraes Holschuh wrote:
Are there other parts of Squeeze that would malfunction with Linux kernels
older than 2.6.26 ?
The version check is pretty much a good idea for safety reasons, I think
On Thu, 19 Mar 2009, Roger Leigh wrote:
True, and I did consider this. However, it was pointed out that since
squeeze would not run with kernels 2.6.26, and Lenny uses 2.6.26, so
I'd still like to know WHAT in squeeze will break with kernels 2.6.26. I
have already asked that, but got no
On Thu, 19 Mar 2009, Roger Leigh wrote:
BTW, if you don't agree with the rationale in my previous mail, let
me know and I'll redo the patch to do the version check in mtab.sh.
The overall concensus on #debian-devel was to just kill it, though.
I just need to know WHAT is supposedly to make
On Fri, 20 Mar 2009, Marco d'Itri wrote:
On Mar 19, Roger Leigh rle...@codelibre.net wrote:
With respect to #494001, I would like to determine the minimum
version of the linux kernel we will
For the new udev package[1] I am trying *very* hard to keep it working
even with 2.6.18 kernels long
On Sun, 12 Apr 2009, martin f krafft wrote:
also sprach Petter Reinholdtsen p...@hungry.com [2009.04.12.2116 +0200]:
Why is it not enough to just add entries to /etc/fstab for these extra
mount points?
Because they get mounted too late, e.g. fsck wants to save logs to
/var/log, and I
On Fri, 01 May 2009, peter green wrote:
Would a compromise be possible? Something along the lines of doing
[...]
urgent stuff (journal replays, checks of unclean unjournaled
filesystems) but skipping the n days/mounts since last check- check
forced checks when on battery? Does fsck
On Tue, 26 May 2009, martin f krafft wrote:
I think the problem is lack of awareness. We ought to somehow make
sure that everyone knows that /tmp is very volatile.
Let's have it be a tmpfs by default, then. Sun got this right 10 years
ago...
--
One disk to rule them all, One disk to find
On Sat, 30 May 2009, Dmitry Maksyoma wrote:
Just to let you know: when /etc/mtab is a symlink to /proc/mounts, loop
devices aren't freed by umount and the system may run out of loop devices
(which makes things worse than they were with old-style mtab). Apparently,
it's not a bug, as it's
On Mon, 15 Jun 2009, martin f krafft wrote:
1. laptops that suspend/resume
What kind of junk moves time backwards on suspend/resume?
And if the operator did it on purpose, well, one should not shoot
himself in the head if one doesn't want to die. I don't know if there
is anything we could do
On Tue, 16 Jun 2009, martin f krafft wrote:
also sprach Henrique de Moraes Holschuh h...@debian.org [2009.06.16.0430
+0200]:
1. laptops that suspend/resume
What kind of junk moves time backwards on suspend/resume?
An inaccurate hardware clock.
Ehh, if the kernel is letting a RTC
On Thu, 18 Jun 2009, martin f krafft wrote:
also sprach Henrique de Moraes Holschuh h...@debian.org [2009.06.18.0528
+0200]:
If it is userspace that is doing it, it can be fixed by applying the
proper adjustment to the RTC, hwclock can do it through /etc/adjtime.
See also package
On Thu, 18 Jun 2009, Henrique de Moraes Holschuh wrote:
You mean those approaches would not cause dovecot to die?
Sort of.
Just to make sure we're in the same wavelength, dovecot's initscript
MUST depend on $time. It really needs to start only after the clock is
adjusted in the boot
On Sun, 19 Jul 2009, Martin Ziegler wrote:
You are right: I upgraded sysvinit from unstable, but
initscripts, sysv-rc, sysvinit-utils only from tested.
Sorry for the noise.
initscripts, sysv-rc, sysvinit-utils are dependencies of sysvinit.
Perhaps recent sysvinit should require at least
On Fri, 24 Jul 2009, Petter Reinholdtsen wrote:
I guess we could extend init/runlevel to track this information.
Would have to extend /dev/initctl protocol and make runlevel suid
root, I guess. Do init know about the previous runlevel? If not, it
would have to be extended to have this
On Fri, 24 Jul 2009, Petter Reinholdtsen wrote:
The system clock is set from the hardware clock by the kernel without
timezone information, and later in the boot by the hwclock*.sh scripts
You know, given that the only reason to have hwclock around nowadays is to
apply timezone information to
On Sun, 26 Jul 2009, Petter Reinholdtsen wrote:
An idea occured to me the other day, to make sure single user boots
actually execute the rc1.d/ scripts. We could add code like this in a
script at the end of rcS.d/:
for word in $(cat /proc/cmdline); do
case $word in
On Sat, 01 Aug 2009, Josh Triplett wrote:
On Fri, Jul 31, 2009 at 11:33:28PM +0200, Petter Reinholdtsen wrote:
[Josh Triplett]
Please consider automatically mounting debugfs on /sys/kernel/debug
when available.
Why should this be done in the init.d scripts installed on each Debian
On Fri, 21 Aug 2009, Petter Reinholdtsen wrote:
I have disabled several services using insserv -r, e.g.
Eh, that is not the supported way to disable services. The start
symlinks should be changed to stop symlinks to disable a service the
supported way. Try something like this instead (or
On Sun, 23 Aug 2009, Harald Dunkel wrote:
Petter Reinholdtsen wrote:
[Harald Dunkel]
From init's point of view a service can be in one of 3 states in
each runlevel: enabled, disabled or ignored. insserv -r
service moves a service to the ignored state for all run
levels. For a Linux-HA
On Sun, 23 Aug 2009, Petter Reinholdtsen wrote:
[Petter Reinholdtsen 2009-08-01]
I moved the text to
URL:
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot/Update200908 ,
to make it easier to have a common text with edits to work on.
The draft have been through several edits,
On Thu, 27 Aug 2009, Harald Dunkel wrote:
I would suggest to take a look at the LSB-style headers of
the run level scripts in /etc/init.d . Many do not define
symlinks for all run levels. udev (just as an example) only
defines a symlink for S. This is surely not a user error.
It also mean we
On Sun, 06 Sep 2009, Petter Reinholdtsen wrote:
It mean that the migration is blocked by package foo, which is removed
but not purged and thus have left behind a script in /etc/init.d. :)
Well, the message says package FOO removed *by* not purged instead of
package FOO is removed *but* not
On Mon, 07 Sep 2009, Patrick Schoenfeld wrote:
On Mon, Sep 07, 2009 at 11:26:38AM +0200, Petter Reinholdtsen wrote:
[Patrick Schoenfeld]
recently I stumbled across some behaviour in invoke-rc.d which I
consider somehow broken. When trying to start a service with
invoke-rc.d it
On Sun, 13 Sep 2009, Raphael Geissert wrote:
And although update-rc.d(8) says that it is a common administration error to
delete a start symlink instead of renaming it to make it a stop symlink, the
default behaviour of invoke-rc.d in that case is not sensitive, and leads to
the init script
On Sun, 13 Sep 2009, Raphael Geissert wrote:
On Sunday 13 September 2009 17:25:25 Henrique de Moraes Holschuh wrote:
On Sun, 13 Sep 2009, Raphael Geissert wrote:
Package foo ships an init script called foo and starts on the default
runlevels; but the administrator wants to manually start
On Thu, 17 Sep 2009, Petter Reinholdtsen wrote:
URL: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sysv-rc got
several bugs related to invoke-rc.d and policy-rc.d, and I must admit
that I do not know those part of sysv-rc well enough to have any idea
how to handle these bugs.
Any of you
On Fri, 18 Sep 2009, Petter Reinholdtsen wrote:
1) Leave it as it is, update the release notes for Squeeze do
document the change.
2) Revert the change temporarely, and decide on a deadline when the
feature is going away for good.
3) Revert the change, and rewrite the rc.boot(5)
Well, I have found the bug. The way it is written, invoke-rc.d would
never get exit status 1 from runlevel. This bug has been in there since
invoke-rc.d was deployed, and I won't pretend I recall why I screwed
that up more than 8 years ago.
Now, fixing it is not difficult. However, it is a
forcemerge 361717 496960
þhanks
Unfortunately, policy-rc.d does need to know the runlevel if that
information is available, so it is not a question of priority.
Howerver, /sbin/runlevel DOES tell us it is horked, but the script is
buggy and doesn't use that information to go on with an unkown
1 - 100 of 210 matches
Mail list logo
