Bug#422257: initscripts: RAMRUN=yes is unusable with some packages
Hello, The sudo package has the same problem, do I need to send a bug report to it ? Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422257: initscripts: RAMRUN=yes is unusable with some packages
Hello, I'm sorry, this is not the sudo package but the screen package. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422257: [Pkg-sysvinit-devel] Bug#422257: initscripts: RAMRUN=yes is unusable with some packages
[Daniel Dehennin] The sudo package has the same problem, do I need to send a bug report to it ? Every package unable to handle /var/run/ and /var/lock/ as a tmpfs need to be fixed to handle it. It is a very common and useful configuration, and has been supposed to work in Debian for years. The packages failing in such configuration need to be fixed. Until all packages are fixed, each sysadmin need to check if his system will work before enabling those options. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422257: initscripts: RAMRUN=yes is unusable with some packages
Package: initscripts Version: 2.86.ds1-38 Severity: normal Hi, some packages create subdirectories in /var/run , then expect them to remain after next reboot. bootclean script does not remove these directories from real FS. But with RAMRUN, we get an empty directory without any structure in it. Startup scripts of some packages could dislike this situation. My testcase : 1. set RAMRUN=yes in /etc/default/tmpfs 2. Reboot the system 3. install courier-imap 4. Reboot the system 5. See courier-imap not starting, unable to create its .pid-file in /var/run/courier/ . To fix the problem, we have either recreate necessary directories in /var/run on each startup, or turn off RAMRUN at all before installing and using such packages. I think this should be either fixed by whoever, or documented as undesirable side-effect of using RAMRUN. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initscripts depends on: ii debianut 2.18Miscellaneous utilities specific t ii e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-2 ext2 file system utilities and lib ii libc62.5-5 GNU C Library: Shared libraries ii lsb-base 3.1-23.1Linux Standard Base 3.1 init scrip ii mount2.12r-19Tools for mounting and manipulatin ii sysvinit 2.86.ds1-38 System-V-like utilities Versions of packages initscripts recommends: ii psmisc22.5-1 Utilities that use the proc filesy -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422257: [Pkg-sysvinit-devel] Bug#422257: initscripts: RAMRUN=yes is unusable with some packages
[Wladimir Mutel] some packages create subdirectories in /var/run , then expect them to remain after next reboot. These packages are broken, as having /var/run/ as a tmpfs has been a supported configuration for a long time. The RAMRUN option was introduced to make it easier to enable, as well as making it easier to set up stateless machines, but did not introduce the support for this feature. To fix the problem, we have either recreate necessary directories in /var/run on each startup, Fix the package to create the stuff it need under /var/run/ (and /var/lock, if needed). I think this should be either fixed by whoever, or documented as undesirable side-effect of using RAMRUN. I agree that it should be documented. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
