Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
Thank you. I will make sure to use a patch in the future.
On Jan 12, 2019 7:41 AM, "Dmitry Bogatov" wrote:
[ Please, next time attach patch, not whole file. Much more convenient
for review ]
[2019-01-10 10:54] Dolphin Oracle
> the buster version of sysvinit initscripts still mounts the with /run/shm
> as the mount point for the tmpfs and /dev/shm as a symlink.
>
> just adding on to the discussion...the situation actually prevents running
> certain flatpak applications.
>
> modifying mount-functions.sh per the attached will reverse the situation,
Works fine to me, I intend to accept it. Dear co-maintainers,
any objections?
> although there is still some migration code in there that strictly
speaking
> isn't necessary.
Further patches are welcome. Just remember, that not only fresh installs
must work fine, but also upgrade from stable must be smooth and painless.
Here is patch for convenience of other developers:
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh
b/debian/src/initscripts/lib/init/mount-functions.sh
index 7511761c..98f53a86 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -436,7 +436,7 @@ post_mountall ()
# directory. The migration logic will then take care of the
# rest. Note that it will take a second boot to fully
# migrate; it should only ever be needed on broken systems.
- RAMSHM_ON_DEV_SHM="no"
+ RAMSHM_ON_DEV_SHM="yes"
if read_fstab_entry "/dev/shm"; then
RAMSHM_ON_DEV_SHM="yes"
fi
@@ -559,8 +559,8 @@ mount_shm ()
{
MNTMODE="$1"
- RAMSHM_ON_DEV_SHM="no"
- SHMDIR="/run/shm"
+ RAMSHM_ON_DEV_SHM="yes"
+ SHMDIR="/dev/shm"
if read_fstab_entry "/dev/shm"; then
if [ "$MNTMODE" = "mount_noupdate" ]; then
log_warning_msg "Warning: fstab entry for /dev/shm;
should probably be for /run/shm unless working around a bug in the Oracle
database"
@@ -706,13 +706,3 @@ is_fastboot_active() {
done
return 1
}
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
[ Please, next time attach patch, not whole file. Much more convenient
for review ]
[2019-01-10 10:54] Dolphin Oracle
> the buster version of sysvinit initscripts still mounts the with /run/shm
> as the mount point for the tmpfs and /dev/shm as a symlink.
>
> just adding on to the discussion...the situation actually prevents running
> certain flatpak applications.
>
> modifying mount-functions.sh per the attached will reverse the situation,
Works fine to me, I intend to accept it. Dear co-maintainers,
any objections?
> although there is still some migration code in there that strictly speaking
> isn't necessary.
Further patches are welcome. Just remember, that not only fresh installs
must work fine, but also upgrade from stable must be smooth and painless.
Here is patch for convenience of other developers:
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh
b/debian/src/initscripts/lib/init/mount-functions.sh
index 7511761c..98f53a86 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -436,7 +436,7 @@ post_mountall ()
# directory. The migration logic will then take care of the
# rest. Note that it will take a second boot to fully
# migrate; it should only ever be needed on broken systems.
- RAMSHM_ON_DEV_SHM="no"
+ RAMSHM_ON_DEV_SHM="yes"
if read_fstab_entry "/dev/shm"; then
RAMSHM_ON_DEV_SHM="yes"
fi
@@ -559,8 +559,8 @@ mount_shm ()
{
MNTMODE="$1"
- RAMSHM_ON_DEV_SHM="no"
- SHMDIR="/run/shm"
+ RAMSHM_ON_DEV_SHM="yes"
+ SHMDIR="/dev/shm"
if read_fstab_entry "/dev/shm"; then
if [ "$MNTMODE" = "mount_noupdate" ]; then
log_warning_msg "Warning: fstab entry for /dev/shm;
should probably be for /run/shm unless working around a bug in the Oracle
database"
@@ -706,13 +706,3 @@ is_fastboot_active() {
done
return 1
}
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
the buster version of sysvinit initscripts still mounts the with /run/shm as the mount point for the tmpfs and /dev/shm as a symlink. just adding on to the discussion...the situation actually prevents running certain flatpak applications. modifying mount-functions.sh per the attached will reverse the situation, although there is still some migration code in there that strictly speaking isn't necessary. mount-functions.sh-testing-antix-rev1.tar.gz Description: GNU Zip compressed data
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
Simon, Henrique, thank you both for clarifying and explaining why! On Sat, Jan 14, 2017 at 11:13:30PM +, Simon McVittie wrote: > No, it should have the ownership and permissions that are the default > for tmpfs filesystems (root:root 01777)… -- cheers, Holger signature.asc Description: Digital signature
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
On Sat, 14 Jan 2017 at 21:50:43 +, Holger Levsen wrote: > On Sat, Jan 14, 2017 at 09:15:42PM +, Simon McVittie wrote: > > Expected result: > > > > * /dev/shm is a tmpfs > > and /dev/shm is owned by root:root and has perms 1755? No, it should have the ownership and permissions that are the default for tmpfs filesystems (root:root 01777), the same as a correctly configured /tmp or /var/tmp. $ ls -ld /dev/shm drwxrwxrwt 2 root root 220 Jan 14 20:44 /dev/shm Regards, S
Bug#851427: [Pkg-sysvinit-devel] Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
On Sat, 14 Jan 2017, Holger Levsen wrote: > On Sat, Jan 14, 2017 at 09:50:43PM +, Holger Levsen wrote: > > and /dev/shm is owned by root:root and has perms 1755? > > actually I have both 1777 and 0755 here, which of the two is correct or > are both fine?? It has to be mode 01777, read+write. Otherwise, it breaks glibc's shm_* and SuS/POSIX compliance, and you get to keep the pieces of everthing that will fail in both subtle, and very non-subtle ways. Such as Google Chrome / chromium. -- Henrique Holschuh
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
On Sat, Jan 14, 2017 at 09:50:43PM +, Holger Levsen wrote: > and /dev/shm is owned by root:root and has perms 1755? actually I have both 1777 and 0755 here, which of the two is correct or are both fine?? -- cheers, Holger signature.asc Description: Digital signature
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
Hi Simon, thanks for this bug report, much appreciated! On Sat, Jan 14, 2017 at 09:15:42PM +, Simon McVittie wrote: > Expected result: > > * /dev/shm is a tmpfs and /dev/shm is owned by root:root and has perms 1755? -- cheers, Holger signature.asc Description: Digital signature
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
Package: initscripts Version: 2.88dsf-59.8 Severity: normal On Sat, 14 Jan 2017 at 11:00:51 -0800, Steve Langasek wrote: > On Fri, Jan 13, 2017 at 03:54:30PM +, Simon McVittie wrote: > > If I'm reading the initscripts code correctly, sysvinit does the reverse > > by default, for some reason (/run/shm is the mount point and /dev/shm the > > symlink). I think the motivation might have been to be able to use the > > same tmpfs for /run and /run/shm, > > I recall this being a misguided attempt to move it out of /dev "because it's > not a device". The migration did not go well, especially in the face of > chroots that need to have it mounted, and since systemd did not handle this > the same way sysvinit had, we effectively now have a mess in the other > direction. > > We should fix it so that everything again treats /dev/shm as the mountpoint. Let's have a bug number for that, then. Please escalate its severity if you think that's correct. Steps to reproduce: * install Debian (I used vmdebootstrap according to autopkgtest-virt-qemu(1)) * apt install sysvinit-core * reboot * mount * ls -al /dev/shm /root/shm Expected result: * /dev/shm is a tmpfs * /run/shm is a symlink with target /dev/shm Actual result: * /dev/shm is a symlink with target /run/shm * /run/shm is a tmpfs This might also be related to #697003, #818442.
