3181 2012-09-26 15:15:00 +0000 runtime directory /run not properly created 2013-03-25 16:43:38 +0000 1 1 11 Runtime General Runtime General Runtime 1.4 x86 Multiple VERIFIED NOTABUG Medium enhancement 1.4 M4 3179 1 alexandru.damian Qi.Chen jessica.zhang liezhi.yang mihai.lindner Qi.Chen richard.purdie ross.burton sgw zhenfeng.zhao --- --- --- oldest_to_newest 25790 0 alexandru.damian 2012-09-26 15:15:00 +0000 The /run directory is currently created after the first boot as a symlink to /var/volatile/run. Debian implements /run as a tmpfs, and symlinks /var/run/ and similar runtime directories back to /run. Anyway, /run needs to be available in the rootfs at first boot, and not created post-install. 26870 1 sgw 2012-10-24 23:11:50 +0000 I would suggest that we correctly create the symlink for /run to /var/run since this is targeted for embedded systems, having multiple tmpfs may not be the best. 26882 2 Qi.Chen 2012-10-25 05:53:50 +0000 Here's an article on this issue. http://article.gmane.org/gmane.linux.redhat.fedora.devel/146976 As this article suggests, I suggest a directory hierarchy like this. tmpfs on /run /var/run -> /run /var/run/lock -> /run/lock /var/run/log -> /run/log .... This approach has already adopted by major distribution in their new releases. 26883 3 Qi.Chen 2012-10-25 06:12:46 +0000 Also, if we make /run the standard directory for volatile runtime data, /var/volatile would not be necessary any more. 26944 4 Qi.Chen 2012-10-26 05:56:04 +0000 %solution% 1) change base-file package, make /run a standard directory /run /run/tmp /run/lock ... 2) improve populate-volatile.sh, change the way it deals with links In current system, if we change /etc/default/volatile/<config file>, and then run command '/etc/init.d/populate_volatile.sh update', it is very likely the result is not what we expect. For example, changing 'l root root 0755 /var/run /var/volatile/run' to 'l root root 0755 /var/run /run' in the config file does not have any real effect. This is caused by the way populate_volatile.sh deals with 'l'-type config items. It first examines if the <target> (in this example /var/run) exists, and if so, it does nothing. I don't think this is appropriate. The script should do things as the configuration file tells it. So I suggest the following way to deal with links in populate_volatile.sh. (similar to Ubuntu's way to deal with mounted-var. See attachment for more detail.) <type> <user> <group> <mode> <target> <link_source> if <target> exists as a dir: cp -rf <target> <link_source>; rm -rf <target>; if <target> exists as a link or a file: rm -f <target> ln -sf <link_source> <target> 3) change /etc/fstab make /run a mount point for tmpfs /var/volatile is no more a mount point for tmpfs 4) change /etc/default/volatiles/<default config>, make the following directory hierarchy /var/run -> /run /var/cache -> /run/cache /var/lock -> /run/lock ... /var/volatile/run -> /run /var/volatile/cache -> /run/cache ... I still keep /var/volatile in system for backward compatibility reason. Because I'm not sure whether some packages in yocto will need it. But no tmpfs mounted at /var/volatile. (Any suggestion would be welcome.) 26976 5 sgw 2012-10-26 18:30:26 +0000 Please look at the base_files recipe also since it lays down some of the original layout so we do not need to do the cp or rm, also continue to implement a prototype this so we can confirm it's operation. 26982 6 richard.purdie 2012-10-26 22:11:55 +0000 We've added code which links /run to /var/run in the recent udev upgrade. Whilst I appreciate the desire to match "standards", is there a strong reason to change these defaults and break backwards compatibility with existing systems? I have a suspicion this is going to be a very disruptive change for users and I'm not sure we have a good reason for it? 26996 7 Qi.Chen 2012-10-29 08:13:23 +0000 Thank you for your advices. Here's a few thoughts of mine, please feel free to give me your opinions and suggestions. 1) Backward compatibility Backward compatibility is the first thing that came into my mind when I first looked at this issue. That's why I still keep /var/volatile directory in my design. After applying changes as stated above, I built a sato image and tested it on beagleboard. The weekly test cases all passed. 2) populate_volatile.sh Three major files (of course there're others) in yocto that change the directory hierarchy are 'fs-perms.txt', which is used by package.bbclass, 'base_files_xxx.bb' and 'initscripts' (volatiles and populate_volatile.sh). Syntax in volatiles: <type> <user> <group> <mode> <target> <link_source> In current system, if <target> has been created in fs-perms.txt or base_file_xxx.bb (or other recipes), populate_volatile.sh has no real effect on that <target>. In other words, it has the lowest 'priority' (forgive me if I used the wrong word). However, /etc/default/volatiles/<config> and populate_volatile.sh are files that the end user actually see. They don't see fs-perms.txt or base_files_xxx.bb. If that script doesn't behave as expected, the user may be confused. So I suggest improve the script. Also, as Saul suggested, implementing a prototype for user confirmation is necessary. 3) problem with linking /run to /var/run I think linking /run to /var/run in current system is OK. It's simple and seems to work so far. However, there may be two potential problems. *) what if some application needs /run/lock or /run/cache, as udev needs /run *) symlink /run to /var/run is specified in /etc/default/volatiles/<config>, if /run or /run/xxx is created by some recipes in yocto, the symlink will not be correctly created by the current populate_volatile.sh script. Actually, we have 'meta/recipes-core/initrdscripts/files/init-live.sh: mkdir -p /run' and 'meta/recipes-core/initrdscripts/initramfs-framework/udev: mkdir -p /run '. I'm not sure wehther other recipes may use /run. With these two problems considered, I prefer making /run dir a mount point for tmpfs. We can symlink /var/run to it, and also, symlink /var/volatile/run to /run for backward compatibility. 4) summary There're two things we have to decide. *) whether we should improve the populate_volatile.sh script *) whether we should make /run dir a mount point for tmpfs or just symlink link it to /var/run 29900 8 Qi.Chen 2013-02-18 06:02:08 +0000 For now, everything seems OK to symlink /run to /var/run. There seems no compelling reason to do this, so I'll mark this bug as RESOLVED/NOTABUG. 31136 9 mihai.lindner 2013-03-25 16:43:38 +0000 Setting to VERIFIED. /run and /var/run/ symlink to /var/volatile/run, which is working fine now.